mySCADA myPRO Manager Fixes Two Authentication Gaps, One Rated Critical

mySCADA myPRO Manager now faces two disclosed security flaws, including one rated 9.8, because sensitive interfaces accepted requests without authentication. Versions 2.1 and earlier are affected. Version 2.2 contains the vendor’s fixes.

The more serious vulnerability exposes privileged management functions through the product’s command API. The second exposes an HTTP endpoint that can send arbitrary text messages through a connected GSM modem. Neither path requires an authenticated account before accepting the relevant request.

That creates a sharp conflict between convenient industrial management and basic access control. myPRO Manager helps operators configure connected environments, but the vulnerable interfaces failed to verify who was issuing sensitive commands. The issue reaches beyond an ordinary web application because mySCADA products appear in operational technology environments worldwide.

The immediate response is clear. Operators need to find affected installations, update them, and verify which networks can reach their management interfaces. The harder work begins afterward, especially for isolated systems, unmanaged installations, and environments where downtime complicates upgrades.

What Changed in mySCADA myPRO Manager

The disclosure identifies two separate authorization failures, but the command API vulnerability carries the greater operational risk.

On September 15, 2026, CISA published an industrial advisory covering mySCADA myPRO Manager. It identifies CVE-2026-73807 and CVE-2026-82567 in versions 2.1 and earlier.

Version 2.2 is listed as unaffected. mySCADA Technologies says that release addresses both issues and recommends updating to the latest available version.

CVE-2026-73807 concerns the command API, meaning the interface used by software components to issue management requests. According to the official record, the API does not properly enforce authentication for privileged functions.

An attacker does not need an existing account. The attacker needs network access to the affected interface, then can attempt to invoke functions normally reserved for an authorized administrator.

The CVE record assigns the flaw a CVSS 3.1 score of 9.8, which falls within the critical range. Its vector describes a network-reachable vulnerability with low attack complexity, no required privileges, and no required user interaction.

The record also assigns a CVSS 4.0 score of 9.3. Both assessments indicate high potential impact on confidentiality, integrity, and availability within the vulnerable system.

That scoring does not establish that every installation is equally exposed. CVSS measures technical severity under standardized assumptions. It does not know whether a particular command API sits behind several firewalls or is reachable from an untrusted network.

CVE-2026-82567 affects the notification gateway, which connects myPRO Manager with SMS delivery through a GSM modem. The vulnerable HTTP endpoint accepts a phone number and message, then instructs the modem to send that text.

The endpoint does not first require authentication. An attacker with suitable network access can therefore submit arbitrary recipients and messages through the connected modem.

This second vulnerability carries a CVSS 3.1 score of 6.3, classified as medium. Its vector uses an adjacent-network attack path rather than the broader network path assigned to CVE-2026-73807.

That distinction matters. The SMS flaw generally requires the attacker to reach the relevant local or adjacent network. The critical command API flaw has a wider network attack classification.

Both problems share the same underlying weakness, however. A sensitive operation accepts input before establishing whether the requester has permission to perform it.

CISA attributes the findings to SECNORA researchers Rajivarnan R. and Shirshak. The vulnerabilities were externally discovered and coordinated through the agency’s industrial control systems disclosure process.

The advisory places affected deployments across critical manufacturing, energy, food and agriculture, transportation, and water and wastewater. It describes deployment as worldwide and lists the vendor’s headquarters in Czechia.

Those sector labels do not prove that every affected instance directly controls a physical process. They do show why an authentication gap in this product deserves close attention from operational technology teams.

Why Missing Authentication Matters More in Industrial Networks

A request that reaches an industrial management interface can carry consequences far beyond the software process receiving it.

Authentication answers a basic question: who is making this request? Authorization answers the next question: what is that identity allowed to do?

CVE-2026-73807 breaks that boundary around privileged management functions. The official description does not enumerate every exposed function, so defenders should not assume a specific outcome beyond the documented access.

Still, “privileged management functions” signals a meaningful trust failure. An interface designed for administration accepted network requests without enforcing the control that should separate administrators from other systems.

The CVSS vector reflects this concern. It assumes no privileges, no user interaction, low complexity, and potential high impact across confidentiality, integrity, and availability.

For an enterprise website, an access-control failure can expose data or application settings. In an operational technology environment, management software may sit near systems that monitor equipment, collect process data, distribute alarms, or support operator decisions.

The exact consequence depends on each deployment. Network design, connected equipment, product configuration, and the exposed functions all shape the real risk.

That variability makes asset context essential. A disconnected lab installation does not present the same exposure as a production manager reachable from a shared corporate segment.

An internet-facing installation represents a still more urgent case. Although the advisory does not publish a count of exposed systems, any direct untrusted access removes a major defensive barrier.

The SMS weakness presents a narrower impact but illustrates the same architectural problem. Notification gateways often carry operational alerts that users are expected to trust.

An attacker who sends arbitrary messages through a known modem could create confusion, impersonate routine notifications, or consume messaging capacity. The official record does not claim that attackers can read existing messages or reconfigure the modem.

Defenders should preserve that distinction. The disclosed capability is unauthorized SMS transmission, not proven control of every notification function.

Even so, arbitrary messages can matter during an incident. Operators may depend on text alerts when they are away from a control room or when another communication channel fails.

A fraudulent message could be mistaken for a legitimate system alert. A burst of unwanted messages could also make real notifications harder to recognize.

Those scenarios are reasonable risk considerations, not documented exploitation reports. The advisory establishes the unauthorized sending path, while each organization must assess its operational consequences.

The industrial setting also changes how quickly teams can patch. Production environments may require planned outages, compatibility testing, vendor coordination, or safety review before changing management software.

These controls reduce accidental disruption, but they can extend the period during which vulnerable code remains installed. Network restrictions therefore matter before, during, and after the update process.

Convenience Collided With Access Control

The central problem is not an advanced exploit chain, but sensitive functionality exposed without an effective identity checkpoint.

Management APIs exist because manual administration does not scale. They allow software components, consoles, and services to exchange commands through defined requests.

Notification gateways offer similar convenience. They connect industrial events with communication channels, allowing software to deliver alerts through a GSM modem.

Both designs can be useful. Their safety depends on treating every incoming request as untrusted until the requester proves an accepted identity and receives explicit permission.

The disclosed flaws show what happens when that sequence breaks. In the command API, a requester can reach privileged functionality without the expected authentication enforcement.

In the notification gateway, the HTTP endpoint accepts destination and message data before verifying an authorized user. It then passes the requested message to the connected modem.

No social engineering is required in either documented path. No administrator needs to open a malicious file or approve a prompt.

That does not make exploitation automatic. The attacker must still obtain the required network reachability, identify the interface, and submit a request the service accepts.

Those prerequisites explain why network architecture remains important. A vulnerable service isolated within a tightly controlled management zone offers fewer attack paths than one exposed across broad internal networks.

However, segmentation is a compensating control, not a correction for missing authentication. Networks change, firewall rules accumulate, remote-access paths expand, and compromised internal devices can bypass assumptions about trusted locations.

The safer design combines layers. The application authenticates every sensitive request, authorization limits available actions, and the network restricts which systems can reach the interface.

Logging should then record accepted and rejected activity. Monitoring should identify unusual commands, unexpected source addresses, and irregular SMS destinations.

CVE-2026-73807 and CVE-2026-82567 matter because they weaken the application layer of that model. Version 2.2 restores the vendor-supported software fix, while network controls reduce exposure around it.

The contrast also explains the difference in severity. The command API issue is scored for potentially high effects across the vulnerable system’s three central security properties.

The SMS endpoint receives lower impact ratings and an adjacent-network classification. Its documented outcome is limited to sending arbitrary messages through an attached modem.

Treating both findings as identical would obscure remediation priorities. Ignoring the lower-scored issue would miss a practical abuse path through a trusted notification channel.

Teams should therefore prioritize the critical command API exposure while addressing both vulnerabilities through the same upgrade. A single version boundary simplifies the software decision, even if deployment work remains complicated.

The vendor says connected devices notify users within mySCADA Pro Manager when a new version is available. Offline environments require operators to obtain the update separately from the manager download page.

Offline systems deserve particular attention. Their isolation can reduce exposure, but it also removes automatic update notifications and can hide outdated software from centralized inventory tools.

An air gap should never substitute for version awareness. Portable media, temporary maintenance connections, laptops, and misconfigured routing can create paths that were absent during the original design.

The Patch Is Clear, but Deployment Risk Remains

Version 2.2 closes the documented software gap, yet organizations still need evidence that every affected installation reached the fixed state.

The vendor’s remediation is straightforward: update mySCADA myPRO Manager to version 2.2 or later. The affected range ends at version 2.1.

That clarity removes one common source of confusion. Teams do not need to compare several patches against different branches for these two CVEs.

The operational challenge is inventory. Organizations must identify where the product runs, which version each installation uses, and which interfaces are reachable from each network zone.

That task can expose gaps unrelated to the new advisory. Industrial software may sit on engineering workstations, dedicated manager systems, temporary commissioning devices, or machines maintained outside normal enterprise processes.

A reliable inventory should include the application version, host identity, network location, system owner, operational function, and permitted communication paths. It should also record whether a GSM modem is connected.

The modem detail determines whether the documented SMS path exists in a given deployment. An installation without that component does not present the same practical CVE-2026-82567 scenario.

The command API requires separate analysis. Teams should identify every source allowed to reach it and verify whether any path originates from user networks, wireless segments, vendor access systems, or the public internet.

A firewall rule alone does not prove isolation. Packet-flow testing and configuration review provide stronger evidence that only intended management systems can connect.

Before upgrading, operators should confirm backup and recovery procedures. They should also understand dependencies that could fail if the manager changes behavior after the update.

Testing should focus on normal management operations, alarm delivery, SMS notifications, authentication, and connectivity with managed systems. The purpose is to find compatibility issues before production deployment.

Teams should then record the installed version after the change. An update notification or downloaded installer does not prove that every host successfully completed the upgrade.

Where immediate patching is impossible, exposure reduction becomes urgent. Access to management interfaces should be limited to explicitly authorized systems through firewalls and segmented network zones.

Remote administration should use controlled access paths rather than exposing the application directly. CISA’s established industrial guidance recommends minimizing exposure, separating control networks from business networks, and using secure remote-access methods.

Its defense-in-depth guidance treats network architecture, access control, monitoring, and incident response as complementary safeguards. None should be viewed as a permanent replacement for the fixed software.

Temporary controls should have owners and expiration dates. Otherwise, an emergency firewall restriction can quietly become the long-term response while the vulnerable version remains installed.

Monitoring also needs deployment-specific signals. Teams can review connections to the command API, rejected authentication events after upgrading, and unusual requests to notification endpoints.

For SMS-enabled systems, operators should compare modem activity with expected alerts. Unrecognized destination numbers, unusual message content, and abnormal sending frequency deserve investigation.

Historical logs can help determine whether suspicious activity occurred before remediation. However, the absence of a log entry cannot establish that no attempt happened if the vulnerable endpoint lacked adequate logging.

Incident responders should preserve relevant network, host, application, and modem records. If activity appears suspicious, they should follow established escalation and reporting procedures.

The advisory does not provide a public exploitation narrative. That limits what defenders can conclude about attacker behavior, tooling, or observed victims.

It does not reduce the technical severity of an unauthenticated management path. Exposure and mission impact should determine the speed of each organization’s response.

mySCADA Has Faced Earlier High-Severity Findings

The new flaws belong to a broader pattern in which management features become security boundaries attackers can test directly.

CISA has published previous advisories involving mySCADA products. These earlier cases do not prove a shared technical cause, but they provide useful context for defenders.

In 2022, CISA described a command-injection vulnerability in mySCADA myPRO versions 8.26.0 and earlier. An authenticated user could modify parameters and run operating-system commands.

That earlier myPRO issue carried a CVSS 3 score of 9.9. The vendor recommended updating to version 8.27.0 or later.

The 2026 command API flaw differs in a crucial way. Its published vector requires no privileges, while the 2022 issue required an authenticated user.

The products and version schemes also differ in the records, so operators should not infer a direct upgrade path between those advisories. Each affected installation must be matched against the specific product and version information.

A separate 2025 advisory covered multiple myPRO Manager vulnerabilities, including operating-system command injection. That history reinforces the need to treat management components as high-value assets.

The lesson is not that one vendor is uniquely vulnerable. Administrative interfaces across industrial products regularly concentrate capabilities that attackers value.

They expose configuration, communications, credentials, updates, or connections to controlled environments. A single missing control can therefore undermine several downstream safeguards.

This is why vulnerability management should track products by function, not only by CVE count. A management server deserves priority because its role can amplify the impact of compromise.

The same reasoning applies to remote-access appliances, engineering workstations, data historians, and notification gateways. Their proximity to operations gives ordinary software weaknesses greater context-dependent significance.

Organizations should also avoid relying entirely on headline scores. CVE-2026-82567 has a medium score, but its abuse could still disrupt a site’s trusted alerting process.

Conversely, a 9.8 score does not prove that an isolated instance can be attacked from the internet. It signals severe technical characteristics once an attacker reaches the vulnerable service.

Effective prioritization combines severity, exposure, exploitability, operational function, and recovery difficulty. It also considers whether a system has a readily available fixed version.

Here, the fixed version exists. That makes prolonged use of version 2.1 or earlier increasingly difficult to justify unless an operational constraint blocks deployment.

If such a constraint exists, management should document it. The record should name the owner, explain the dependency, list temporary controls, and define the next review date.

This turns patch delay into a managed risk decision. Without that process, delay becomes an invisible default.

What Operators Should Watch Next

The next useful signals are verified upgrade coverage, evidence of exploitation, and confirmation that sensitive interfaces are no longer broadly reachable.

First, organizations should measure adoption of version 2.2 or later. The most important internal metric is not whether a patch was downloaded, but whether every affected asset now reports a fixed version.

That measurement should include systems outside normal enterprise tooling. Offline installations, contractor-managed devices, and test environments can preserve vulnerable versions long after production updates finish.

A complete result strengthens the case that the immediate software risk has been contained. Unidentified or unreachable assets weaken that conclusion.

Second, defenders should watch authoritative sources for changes in exploitation status. New proof-of-concept code, confirmed attacks, or inclusion in a government exploitation catalog would change response urgency.

At publication, the available advisory material describes the vulnerabilities and fixes without establishing an active exploitation campaign. Readers should distinguish that absence from evidence that exploitation is impossible.

Threat information can change quickly after disclosure. Attackers gain a clear product name, affected version range, weakness category, and description of exposed functionality.

Third, operators should validate the surrounding architecture. Updating the application should not end the review of management-interface exposure.

A scan from appropriate network zones can confirm whether the command API and notification gateway accept connections only from approved sources. Firewall review should produce the same answer.

If a broad segment can still reach these services, the environment remains unnecessarily exposed to future defects. A patch closes known vulnerabilities, while segmentation limits the blast radius of the next unknown one.

Teams should also verify application behavior after the update. Sensitive commands must require authenticated, authorized access, and the SMS endpoint must reject unauthenticated requests.

Those tests should use approved procedures in a controlled environment. Production probing without coordination can create operational risk.

The findings also warrant a review of account and access design. Organizations should identify who administers the manager, which service accounts interact with it, and how credentials are protected.

Least privilege remains important after authentication is restored. A valid account should receive only the functions required for its role.

Logging deserves a final check. Security teams need enough detail to connect a request with a source, identity, action, result, and time.

For modem-backed notifications, records should connect each message with the event or user that initiated it. This helps distinguish legitimate automation from unauthorized use.

The practical response to mySCADA myPRO Manager is therefore broader than installing one release. Patch first, then verify reachability, access enforcement, logging, and asset coverage.

If your organization runs myPRO Manager, can it prove that every installation is on version 2.2 or later? Can it also show that untrusted systems cannot reach privileged interfaces?

Those two answers define the near-term outcome. A confirmed update closes the documented flaws. Restricted network access and tested authentication reduce the chance that the next overlooked interface becomes an operational incident.