DEV Community: jeffrey

mySCADA myPRO Manager: Two Missing-Authorization Flaws in an ICS Management Platform

jeffrey — Wed, 16 Sep 2026 09:25:14 +0000

mySCADA myPRO Manager: Two Missing-Authorization Flaws in an ICS Management Platform

Vulnerability overview

CISA published an advisory covering two authorization weaknesses in mySCADA myPRO Manager, an HMI/SCADA management component from mySCADA Technologies. The more serious issue, CVE-2026-73807, carries a CVSS v3 score of 9.8. The second, CVE-2026-82567, is rated 6.3.
Both are described as missing-authorization defects. Neither requires the attacker to hold credentials, and neither has been linked to confirmed exploitation at the time of disclosure. Patches are available in version 2.2.

Mechanism and exploitation conditions

CVE-2026-73807 sits in the myPRO Manager command API. The advisory states that this API "does not properly enforce authentication for privileged functions." In practice, an endpoint that should reject unauthenticated callers accepts them, and the caller reaches management operations that are meant to be restricted.
CVE-2026-82567 affects the notification gateway. That component exposes an HTTP endpoint used to dispatch SMS messages through an attached GSM modem, and the endpoint does not verify who is calling it. A network request carrying a message payload is enough to trigger a send.
Exploitation requires network reachability to the affected interface. An attacker who can route packets to the command API or the notification gateway does not need a session, a token, or a valid account.

Impact

Reaching the command API gives an attacker access to privileged management functions. On an industrial control deployment, that can mean altering configuration, disrupting process visibility, or interfering with the operator's ability to control equipment.
The notification gateway adds a second, less obvious consequence. Because the SMS path runs through a physical GSM modem, an attacker can use the appliance to send messages that appear to originate from the operator's own infrastructure. That is useful for social engineering against staff who trust messages from the plant's monitoring system, and it can generate carrier charges on the operator's account.

Affected products and scope

mySCADA myPRO Manager version 2.1 and earlier is affected. mySCADA Technologies resolved both defects in version 2.2. The advisory does not describe a configuration that avoids the flaws; the affected code paths are part of the product's normal management and alerting functions.

Exposure context

A ZoomEye query for title="mySCADA" returned 651 matching assets on 2026-09-16. That figure counts systems whose page title matches the product string. It does not establish that any of them run a vulnerable version or expose the affected endpoints to the internet, so it should be read as an indicator of how widely the product is deployed on reachable networks rather than a count of confirmed vulnerable hosts.

Remediation and mitigations

Upgrade myPRO Manager to version 2.2. That is the only action that removes the flaws.
Where the upgrade cannot be applied immediately, restrict who can reach the command API and the notification gateway. Place both behind a firewall or an access-controlled segment, and do not expose them to untrusted networks. If the SMS gateway is not needed, disable it. Review logs for unauthenticated calls to management endpoints and for outbound SMS activity that no operator initiated.
After upgrading, confirm the running version in the product interface rather than relying on the installer having completed.

References

SecurityOnline, "Critical mySCADA myPRO Manager Vulnerabilities Patched": https://securityonline.info/myscada-mypro-manager-vulnerabilities/
CISA ICS advisories: https://www.cisa.gov/news-events/ics-advisories
ZoomEye query title="mySCADA", executed 2026-09-16: https://www.zoomeye.ai/searchResult?q=dGl0bGU9Im15U0NBREEi

MikroTik RouterOS CVE-2026-67277: A Defender's Detection and Response Playbook

jeffrey — Wed, 16 Sep 2026 08:25:46 +0000

MikroTik RouterOS CVE-2026-67277: A Defender's Detection and Response Playbook

By the time a vendor advisory reaches your inbox, the exploitation window may already be open. CERT Polska observed attacks against MikroTik RouterOS beginning 2026-09-02, three days before it published its warning on 2026-09-05. For defenders running RouterOS at the network edge, the useful question is not whether the flaw is serious. It is what to look for, in what order, and what to do when you find it.

What you are defending against

CVE-2026-67277 is a CWE-306 missing-authentication flaw in RouterOS, reachable through the SSH management service. It is exploited as the opening move of a chain called MikroTrick, completed by CVE-2026-86060, a CWE-88 argument-delimiter neutralization flaw. Together they grant an unauthenticated attacker full administrator control of an internet-exposed device. CISA added CVE-2026-67277 to the Known Exploited Vulnerabilities catalog on 2026-09-10, which makes it a remediation priority for federal agencies and a sensible one for everyone else.

The reason this matters more than a typical edge-device bug is position. A RouterOS box is frequently the boundary between a private network and the internet. Compromise of that box is compromise of the boundary: routing, DNS, firewall policy, and the traffic itself all pass through it.

Detection: the indicators that matter

CERT Polska and follow-on reporting identify specific artifacts of exploitation. Treat these as leads, not proof, and correlate them against your own logs.

SSH logins as the username -2. A username of -2 is not a normal account. SSH log entries showing that name are a reported indicator of the MikroTrick chain. Search authentication logs for it directly.
An unexpected privileged account named ops. Investigators have reported an account by that name created during intrusions. Enumerate RouterOS users and compare against your known inventory.
Scheduled scripts and configuration you did not author. Attackers use router scripting to persist. Review /system script and /system scheduler entries for anything unfamiliar.
Outbound connections to reported infrastructure. Source addresses 82.192.72.4 and 103.102.31.18 have been associated with the activity. They are historical indicators, not a complete blocklist.
The Flagged self-check. Recent RouterOS builds run a startup integrity check and mark a device as Flagged when they find known tampering. A Flagged device should be treated as compromised.

Response: patching is step one, not the whole job

The fixed builds are RouterOS 6.49.21, 7.23.4, and 7.24.2. Upgrade to the build that matches your branch: 6.x long-term to 6.49.21 or later, 7.x long-term to 7.23.4 or later, and stable to 7.24.2 or later. Firmware is available from MikroTik's download page.

On a device that shows any of the indicators above, upgrading alone is not a clean bill of health. An attacker who held administrator rights could have left accounts, scripts, or configuration changes that survive a firmware update. The defensible sequence is:

Preserve evidence. Capture configuration, logs, and a support file before changing anything, so the incident can be scoped.
Isolate. Move the device off the untrusted path or restrict its management access while you work.
Rebuild. For a confirmed compromise, factory reset or reinstall and apply a known-good configuration rather than editing the live one.
Rotate everything the device could have seen. Credentials, VPN keys, and any secrets stored in or passing through the router should be considered exposed.
Re-audit after rebuild. Confirm no unknown accounts or scripts remain before returning the device to service.

Reducing the attack surface going forward

The single most effective structural control is not exposing SSH management to the internet. Where remote administration is genuinely required, restrict it to trusted source addresses, place it on a dedicated management network, and prefer a VPN or jump host over a publicly reachable listener.

Two habits follow from this incident. First, keep edge devices on a patch cadence; a router that is never updated is a router that is never fixed. Second, monitor the management plane. Authentication logs, account inventories, and scheduled-task listings are cheap to collect and are exactly where this class of intrusion shows up.

Exposure context

A ZoomEye search for app="RouterOS" returned 2,854,024 matching assets on 2026-09-16. This is the population of fingerprint-matching devices, not a count of confirmed-vulnerable or internet-exposed ones, but it shows how much surface an opportunistic scanner can reach. A CVE-specific query, vul.cve="CVE-2026-67277", returned zero indexed assets at the same time, which is typical for a fresh disclosure.

References

CISA, CISA Adds Two Known Exploited Vulnerabilities to Catalog, 2026-09-10: https://www.cisa.gov/news-events/alerts/2026/09/10/cisa-adds-two-known-exploited-vulnerabilities-catalog
CERT Polska, Vulnerabilities in MikroTik RouterOS actively exploited: https://cert.pl/en/posts/2026/09/vulnerabilities-in-mikrotik-routeros-actively-exploited/
MikroTik RouterOS downloads: https://mikrotik.com/download
NVD record for CVE-2026-67277: https://nvd.nist.gov/vuln/detail/CVE-2026-67277

Finding the Workflow Orchestrators: ZoomEye Exposure Data for Kestra After CVE-2026-49869

jeffrey — Wed, 16 Sep 2026 07:48:39 +0000

Finding the Workflow Orchestrators: ZoomEye Exposure Data for Kestra After CVE-2026-49869

CVE-2026-49869 is an authentication bypass in Kestra OSS that escalates to unauthenticated remote code execution, rated Critical at CVSS 3.1 10.0 and added to CISA's Known Exploited Vulnerabilities catalog on 2026-09-02. The flaw is a path-suffix check in the AuthenticationFilter: any request path ending in /configs skipped Basic Authentication, and because configs can appear as a caller-controlled resource identifier in other API routes, protected endpoints could be reached without credentials. Kestra ships script execution plugins by default, so an anonymous caller who can create and trigger a workflow can run commands inside the worker.
For defenders, the practical question is where these orchestrators live and how many are reachable. That is a measurement question, and it comes with an important caveat about how search engines fingerprint this product.

What was measured

Two ZoomEye queries were run on 2026-09-16 with scope all:

app="Kestra" returned 119 matching assets.
title="Kestra" returned 231 matching assets.
app="Kestra OSS" returned 0, which indicates that this string is not a valid product fingerprint in the index rather than that no assets exist.
vul.cve="CVE-2026-49869" returned 0, which reflects CVE indexing lag and is not evidence of patching. The two positive queries measure the same product through different signals. An app fingerprint matches the application as identified by the scanner; a title match looks at the HTML title of the page. The title count is higher here, which is common for products whose login or landing pages carry a recognizable title while the application fingerprint is narrower. Neither number should be treated as the definitive population of exposed Kestra instances, and neither should be summed with the other — they overlap. ## Reading the numbers honestly These counts describe assets that ZoomEye can identify as Kestra from the public internet. They do not tell you:
which version each instance runs;
whether the instance is reachable beyond the scanned port;
whether the instance sits behind an additional authentication layer that would stop the bypass before it reaches the application filter;
whether any instance has already been accessed. The affected versions are Kestra OSS up to and including 1.3.20, with CVE data also expressed as < 1.0.45 and >= 1.1.0, < 1.3.21. Fixed releases are 1.0.45 and 1.3.21. A public fingerprint tells you the product is there; only the owner can tell you the version and the configuration. ## Why this product class is worth measuring A workflow orchestrator is not a passive web application. Kestra's documented role is to define and schedule workflows, run shell, Python, and Node.js tasks, connect to databases, cloud services, message systems, and internal APIs, and store flow configuration, variables, and run logs. That is the point of the product, and it is also why an authentication bypass here is more than an information-disclosure issue. The exploitation chain is short. An anonymous caller creates a workflow through a route that satisfies the suffix check, triggers it, and the platform executes the script task. No separate command-injection vulnerability is needed; the orchestrator's legitimate execution capability becomes the attacker's primitive. The vendor's fix normalizes the path and matches the public configuration endpoint exactly as /api/v1/configs, and adds regression tests confirming that other paths ending in /configs return 401 Unauthorized. ## From count to action For an organization running Kestra, the useful sequence is:
Cross-check the public fingerprint counts against your own inventory. Orchestrators are often deployed by platform or data teams and may not be in the central asset register.
Determine which instances are reachable from untrusted networks. Even an instance that is not directly internet-facing can be exploited by an attacker who has already reached the office, development, or cluster network, so internal exposure counts too.
Upgrade to 1.0.45, 1.3.21, or a later supported release.
Until the upgrade lands, restrict the Kestra API at the network layer to trusted administrative entry points and enforce authentication at the upstream proxy rather than relying on the application filter.
Investigate rather than only scan. Look for unexpected flows, unfamiliar executions, key-value changes, deleted logs, and script tasks from unknown sources. If the worker could reach cloud metadata endpoints, database credentials, or internal APIs, include credential rotation in the response.
Be careful about the blast radius claim. Root inside the worker container is not automatically root on the host; escaping the container depends on mounts, capabilities, exposed sockets, service accounts, and runtime configuration. CISA confirming exploitation does not mean every internet-facing instance was compromised. ## What the measurement establishes The headline for Kestra is not a large number. Roughly one to two hundred publicly fingerprinted instances is a small population compared with consumer-facing products, and that is itself a useful finding: this is a component that tends to be deployed on internal networks and behind access controls, which is where it belongs. The value of the exposure query is the check against your own records — confirming whether any instance you own has a public fingerprint at all, and whether the network controls you assume are in place actually are. Where a platform can execute code and reach credentials, the exposure count is a prompt to verify configuration, not a substitute for it. ## References
ZoomEye exposure query app="Kestra", scope all, count 119, collected 2026-09-16.
ZoomEye exposure query title="Kestra", scope all, count 231, collected 2026-09-16.
ZoomEye query vul.cve="CVE-2026-49869", count 0, collected 2026-09-16.
Kestra GitHub Security Advisory GHSA-5vc5-wxxq-3fjx (CVE-2026-49869), including fix commit 2475839.
CISA, "CISA Adds Seven Known Exploited Vulnerabilities to Catalog," 2026-09-02.
CVE-2026-49869 record, CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

Why I Started Writing

jeffrey — Wed, 16 Sep 2026 06:48:52 +0000

Why I Started Writing as a Developer

For a long time, I thought writing about code was just for "experts." I'd solve a tricky bug, celebrate quietly, and move on — until I realized how much I was forgetting.

The turning point

A few months ago, I ran into the exact same bug I had fixed six months earlier. I had no notes, no record of the solution, and no choice but to debug it all over again. That's when I decided to start writing things down.

What I hope to do here

Document the problems I solve, big and small
Share the tools and patterns that actually save me time
Learn from the comments and feedback of other developers

Writing isn't about being perfect. It's about leaving a trail of breadcrumbs — for future me, and hopefully for someone else too.

Looking forward to the journey. Feel free to say hi!