Security1 distinct publisher2 min readPublished
CVE-2026-12663 covers every ControlFLASH build through V15.07, where any local account on an engineering workstation could stage code that runs with the privileges of the next engineer to open the firmware updater.
The Watch · Security desk

Compiled by The WatchSomething wrong?How this is made
Write permission on a program directory is an execution primitive. Windows loads executables and libraries out of that directory when the tool starts, so whoever can write there gets to choose what the tool loads. The Everyone group includes the least trusted local account on the machine [2]. Put a file into C:\Program Files (x86)\ControlFLASH\0001, wait for a controls engineer to launch the firmware updater, and the code runs with that engineer's token [6][3]. The account trusted to push firmware into controllers is, by construction, a well provisioned account.
That is also the ceiling. CISA says there is no remote vector and no reported exploitation [7]. The precondition is a second, lower privileged local account on the same workstation as the ControlFLASH user [13]. On a single admin engineering laptop that nobody else logs into, there is nothing to escalate from and this is housekeeping. On a shared control room workstation with contractor logins and an operator account, it converts a foothold into the engineer's rights.
The labelling is worth a minute. The advisory files the relevant weakness as CWE-306, Missing Authentication for Critical Function [10], while the text in the same document describes an installer granting write permissions to Everyone [2]. Those are not the same defect, and the Metrics section carries no CVSS score at all [11]. Anyone who triages OT advisories by severity band, or who pivots on weakness class to find related exposure across a vendor's toolchain, will sort CVE-2026-12663 into the wrong pile.
Rockwell reported the bug to CISA itself and fixed it one release past the last affected build, 15.07 to 15.08 [8][5][14]. The interim workaround is four steps in one folder's Properties dialog and touches only the install directory on the workstation, so no controller gets re-flashed to apply it [12]. That asymmetry is the useful part of this advisory: the remediation cost sits entirely on the Windows side, where change control is cheaper than it is on anything holding a process.
ControlFLASH is deployed worldwide, and CISA lists critical manufacturing, energy, and water and wastewater as the sectors that run it [9]. That figure sets how many workstations need an ACL check, not how fast. The advisory went out 2026-09-03 [1]. The pattern to keep in view is not this one directory, but firmware update tooling being the softest thing on a hardened plant floor, because it is the software everyone assumes is already trusted.
Ranked by verification strength, evidence, and original report placement.
Rockwell Automation corrected the issue in software version 15.08 and encourages all users to update to the newest version.
Users who cannot upgrade are told to right-click the C:\Program Files (x86)\ControlFLASH\0001 folder, open Properties, select the Security tab, choose Edit, select Everyone under Group or user names, select Remove, then select OK.
CISA published advisory ICSA-26-246-03 covering Rockwell Automation ControlFLASH, with an initial release date of 2026-09-03.
A security issue exists in ControlFLASH where the installer grants write permissions to the "Everyone" group on a product installation directory.
CISA states successful exploitation could allow arbitrary code execution, giving an attacker the ability to run any commands or code of their choice on the target machine at the logged-in user's permission level.
The affected versions are Rockwell Automation ControlFLASH V15.07 and earlier, tracked as CVE-2026-12663.
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's redundancy config tool loads a standard user's DLL as SYSTEM1 distinct publisher
security
CISA's Ebyte advisory carries no fixed version, because the vendor stopped answering1 distinct publisher
security
Rockwell answers a 1756-ENBT crash bug with a hardware swap instead of firmware1 distinct publisher
security
Xiiaozet's LK100W lets an unauthenticated caller switch on its admin services1 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.
One primary document, written by the vendor that found the bug
The affected build, the corrected build, the folder path and the four clicks all trace to a single CISA advisory that relays Rockwell's own account of a defect Rockwell itself reported. That is named, dated and primary, which puts it far above rumour. It is also uncorroborated outside the vendor, carries no CVSS vector, and files the finding under CWE-306 — missing authentication — for behaviour the same page describes as an over-permissive install directory. Reliable on specifics, unaudited on judgement.
A fix exists; nothing says who has taken it
We can see that 15.08 is available and that a workaround is documented. We cannot see how many engineering workstations still run V15.07, how quickly 15.08 is landing, or whether any site has applied the folder change. CISA's 'deployed worldwide' across three sectors is advisory boilerplate, not an install count, and we are not going to convert it into an adoption number.
Understated by its own paperwork
Nothing here is oversold. If anything the document mutes itself: an empty Metrics block and a mismatched weakness label make it easy to skim past a defect in the very tool engineers use to push firmware to controllers, one that leaves a directory on that machine writable by Everyone. Our headline is blunter than CISA's prose, and the advisory's own text supports the bluntness.
Self-disclosure with the patch already in hand
Rockwell found this, told CISA, and had 15.08 ready when the advisory went out — about as clean an incentive profile as a vulnerability story gets, since the disclosure sells a free update rather than a product. What tilt remains points toward calm: no severity score, a weakness class milder than the behaviour, and a mitigation presented as four clicks. CISA supplies distribution and its standing recommended-practices text, not adversarial review.
Sure what it says, unsure what it means in the field
Version boundaries, the CVE identifier, the folder path and the remediation steps are unambiguous. Exposure is not: there is no severity metric, no exploitation signal beyond 'none reported to CISA,' and a single publisher behind the whole story. Rockwell's own advisory page, or any survey of workstations still running the affected build, would move this figure quickly in either direction.