Security1 distinct publisher2 min readPublished
Rockwell found and reported both CVEs itself, and the only fix is firmware v2.002 on hardware wired into running machines. That puts this on a maintenance calendar rather than an incident bridge, with the web server outage the part that bites during a fault chase.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
Stored XSS on an embedded web server needs two conditions, and both are ordinary on a plant floor. Someone who can reach the device over HTTP writes input the interface stores without sanitizing it [3]. Then another user opens that page and the script runs in their browser [3][5]. The second condition is why this belongs on a patch cycle and not a call-out: the payload sits until an engineer or a maintenance tech looks at the starter.
The other entry is a single request class. A crafted HTTP PUT to the embedded web server is handled badly enough to cost the web server its availability, filed under CWE-770, allocation of resources without limits or throttling [4]. The blast radius is narrow: CISA scopes the outcome to loss of web server availability [5][15]. That covers the starter's configuration and diagnostic interface, separate from the starter itself. It is a nuisance during commissioning and a real problem during a fault chase, which is exactly when someone will be trying to load the page.
The advisory hands out two CVE IDs, CVE-2026-19471 and CVE-2026-19472, against everything at or below v2.001 [2], then describes the defects in two blocks, one CWE-79 and one CWE-770, without saying which ID belongs to which [11]. The published text also carries no CVSS metrics [10]. So the ranking work falls to the asset owner, and a change ticket that cites only a CVE number will not tell the reviewer whether the reviewer is approving a script fix or an outage fix. Cite the advisory and the firmware version instead.
Both blocks name the same remediation, firmware version v2.002 [6], so a single flash resolves both CVE IDs at once [14]. In the interim, the reach reduction is CISA's standing list: keep control system devices off the internet, behind firewalls, isolated from business networks, with remote access through a maintained VPN [13].
Rockwell reported these to CISA itself [8], and the advisory records no exploitation and no proof of concept [12]. For a product line installed worldwide in critical manufacturing [9], that ordering matters: the fix exists before anyone has published the input string that triggers it. The head start lasts only as long as v2.001 stays on the wall.
Ranked by verification strength, evidence, and original report placement.
CISA published an ICS advisory, ICSA-26-246-04, on Rockwell Automation ArmorStart LT.
The advisory lists Rockwell Automation ArmorStart LT versions v2.001 and earlier as affected, tied to CVE-2026-19471 and CVE-2026-19472.
Multiple stored cross-site scripting issues exist within ArmorStart LT; stored XSS occurs when user input is not properly sanitized and is stored on the server, allowing an attacker to inject scripts that execute when other users access the affected page. Relevant CWE: CWE-79.
A denial-of-service issue in ArmorStart LT stems from improper handling of a crafted HTTP PUT request sent to the embedded web server, which can result in loss of web server availability. Relevant CWE: CWE-770, Allocation of Resources Without Limits or Throttling.
CISA states that successful exploitation could result in a loss of webserver availability or allow an attacker to inject malicious scripts that will be executed when other users access the affected page.
Rockwell Automation has corrected the issues in firmware version v2.002 and encourages all users to update to the newest version.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · September 3, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
security
Rockwell folds four RSLinx Classic CIP crash flaws into a single 4.60 upgrade1 distinct publisher
security
CISA finally counts the water intrusions: 100-plus exposed systems behind cellular modems2 distinct publishers
security
One malformed CIP message faults a Logix controller until someone power-cycles it1 distinct publisher
security
Rockwell's redundancy config tool loads a standard user's DLL as SYSTEM1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Primary document, single link in the chain
Every fact here is lifted from CISA's own advisory page, which is about as close to the record as a vulnerability report gets — and CISA got it from Rockwell. The chain has one link, and the checks a reader would normally apply are the ones the document withholds: the Metrics headings are blank, so there is no score or vector, and neither CVE ID is bound to a specific flaw.
Fielded scale unmeasured
CISA calls ArmorStart LT deployment 'worldwide' in critical manufacturing, and that word is the entire scale disclosure. Nothing in this reporting counts installed starters, web interfaces reachable from a plant network, or plants already carrying v2.002 — and for a firmware fix, that last number is the only one that would mean anything.
Underspecified rather than oversold
Nobody is inflating this. CISA stops at loss of webserver availability plus script execution for whoever next loads the page, and never reaches for motor control or process loss. If the framing errs, it errs quiet: shipping without severity numbers or a CVE-to-flaw map leaves the reader assembling risk out of two CWE labels.
The finder is also the fixer
Rockwell reported these bugs to CISA itself, and the acknowledgments credit nobody else — so the party deciding how bad this sounds is the party shipping v2.002. The prose reads restrained rather than spun, but with both Metrics blocks empty and 'more information' pointing back to Rockwell's own trust-center page, severity framing never leaves the vendor's hands.
Firm on the actionable, thin on urgency
What a maintenance planner needs is stated plainly and by the issuer: affected range, one firmware step that closes both findings, and the fallback if a unit cannot be touched. Confidence stops well short of high because there is no second reading of the same firmware, no score, and no map from identifier to defect — so any ranking of these two flaws against each other is our inference, not the record's.