The U.S. Cybersecurity and Infrastructure Security Agency has published an advisory for CVE-2026-6807, an XML external entity (XXE) vulnerability in the NSA’s GRASSMARLIN network mapping tool. With the project archived since 2017 and no patch coming, Windows-based OT analysts face a medium-severity but persistent risk of sensitive data exposure.
A Last-Minute CVE for an Abandoned Tool
On April 28, 2026, CISA released ICS Advisory ICSA-26-118-01, detailing a newly assigned CVE for a tool that hasn’t seen a code update in nearly a decade. GRASSMARLIN, an open-source passive network mapper developed by the NSA for industrial control systems, is flagged with CVE-2026-6807. The flaw sits in how the application parses XML input—specifically, it fails to properly restrict XML External Entity references, a classic CWE-611 weakness.
The CVSS v3.1 score is 5.5 (Medium), with a vector string of AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. That local attack vector and low privilege requirement mean an attacker would need some access to the system, but no user interaction is needed once a malicious file is crafted. The impact is purely confidentiality: an attacker could disclose sensitive information from the machine running GRASSMARLIN.
The twist? The NSA declared GRASSMARLIN end-of-life in 2017. The GitHub repository is archived and read-only. There will be no official fix. Not now, not ever.
The Vulnerability: XML Parsing Gone Wrong
The advisory’s description is succinct: "A vulnerability in GRASSMARLIN v3.2.1 allows crafted session data to trigger improper handling of XML input, which may result in unintended exposure of sensitive information." The problem originates from XML parsers that accept untrusted data and permit dangerous features like external entities and DTD processing. In an XXE attack, a malicious XML file can coerce the application to read local files, make outbound network requests, or perform server-side request forgery—all from the context of the parsing process.
Grady DeRosa, who reported the issue to CISA, demonstrated that GRASSMARLIN’s XML handling wasn’t hardened against these attacks. The advisory isn’t specific about which files could be exfiltrated, but the CVSS vector’s high confidentiality impact suggests the risk is more than theoretical. Because GRASSMARLIN processes session files—which often contain network maps, host metadata, and packet-derived information—the blast radius could include deep visibility into an organization’s OT landscape.
Crucially, exploitation requires an attacker to craft a malicious session file and lure a user into opening it. That lowers the urgency compared to a remote unauthenticated flaw, but for OT environments where engineers and analysts routinely exchange project files, the threat is tangible. Even a shared network drive with write access could become the infection vector.
Why It Matters for Windows OT Workstations
GRASSMARLIN is a Java-based tool, and while it can run on multiple platforms, field experience shows it most often lands on Windows analyst laptops or jump boxes. OT security practitioners frequently use GRASSMARLIN to passively visualize ICS network topology without active scanning—a must when poking legacy PLCs or fragile SCADA devices. The tool ingests PCAP files or network captures and quietly builds a snapshot of devices, protocols, and communication paths.
That use case puts it squarely on Windows systems that also store sensitive data: packet captures containing unencrypted ICS protocol traffic, device inventory spreadsheets, configuration files, VPN profiles, and sometimes even credential-like artifacts. If a tainted session file reaches one of these machines, the XXE vulnerability could allow an attacker to read any file the Java process has access to.
For a home user or casual tester, the risk is low. But for an engineer at a power utility, a water treatment plant, or a manufacturing floor, the consequences could be severe. An attacker who gains detailed network maps, IP schemes, and device metadata gains a massive head start for lateral movement or targeted disruption.
And because the tool is unsupported, every installation is a permanent risk. No Windows Update, no Microsoft patch, no Intune policy will close this hole.
A Tool Frozen in Time
GRASSMARLIN was born from a need within the NSA’s own defensive teams. Industrial control systems—those that run critical infrastructure—often can’t tolerate active scanning. So the agency built a passive mapper that listens, learns, and graphs. It was released to the public in 2013 and quickly became a staple in OT security toolkits. The last official release, version 3.2.1, landed on June 27, 2017. After that, silence.
Unlike commercial tools that offer long-term support or extended security maintenance, open-source projects from government labs sometimes fade when the original team moves on. With no active maintainers and no corporate sponsor, GRASSMARLIN joined the ranks of legacy tools that linger on analyst workstations simply because “it still works.”
The CVE assignment in 2026 is a wake-up call for every organization that hasn’t performed a tool inventory in a while. It isn’t an overstatement to say that some OT teams may have forgotten GRASSMARLIN is even installed.
Immediate Actions for Windows Admins
There is no patch. There will be no patch. The only remediation is to stop using GRASSMARLIN and remove it from every system you control. But that’s easier said than done—many organizations have years of session files, archives, and embedded workflows. Here’s a phased approach for Windows administrators and OT security leads:
- Find it: Search workstations, engineering VMs, and jump boxes for GRASSMARLIN binaries (Java JAR files often named
grassmarlin-*.jar), installation directories, and any saved session files with extensions like.gmlor.gms. Use Windows search or endpoint management tools to locate them. - Isolate it: If absolute necessity forces you to keep using GRASSMARLIN for historical analysis, run it only inside an air-gapped, non-persistent Windows sandbox. A virtual machine with networking disabled, no sensitive local files, and a non-privileged account is the minimum bar.
- Sanitize inputs: Assume any GRASSMARLIN session file is malicious unless you generated it yourself on a trusted system. Do not open files received from third parties, contractors, or even internal colleagues without first inspecting the XML for external entity declarations—or simply refusing them.
- Lock down file exchanges: Prohibit emailing of session files. Use a controlled, read-only repository with malware scanning. Block execution from removable media. If you must share, use a tool that can strip XML entities before ingestion.
- Review what’s exposed: On any machine where GRASSMARLIN has ever been run, assess what sensitive data resides nearby. Packet captures, network diagrams, device lists, and engineering documents should be moved to secured, access-controlled locations. Assume the worst: that an attacker could have read those files if they managed to open a booby-trapped session.
- Find a replacement: Several modern passive network discovery tools now serve the OT space, many with native support for ICS protocols and secure import/export functions. Look for solutions with active maintenance, regular security updates, and role-based access controls. CISA’s own list of free ICS cybersecurity resources is a good starting point.
- Apply general ICS hardening: The advisory reminds defenders to minimize network exposure for control system devices, isolate OT from business networks, and use VPNs securely. While not GRASSMARLIN-specific, these practices shrink the attack surface that a disclosed network map would help an adversary navigate.
Detection and Monitoring
If you can’t retire the tool immediately, at least monitor systems where it runs. Enable Windows Defender ATP or your chosen EDR solution to watch for the Java process accessing unexpected files or making outbound network connections. Log any DNS, HTTP, SMB, or LDAP traffic initiated from a GRASSMARLIN workstation after opening a session file. These could be signs of XXE-based data exfiltration.
Microsoft’s own guidance for hardening Windows against such attacks includes enabling Attack Surface Reduction rules, enforcing AppLocker to limit what can execute, and ensuring that legacy Java versions are removed. While these steps won’t fix GRASSMARLIN, they’ll make exploitation harder and detection more likely.
The Bigger Picture
This advisory isn’t really about CVE-2026-6807. It’s about dependency on abandonware in critical infrastructure. GRASSMARLIN is just one example. Countless OT environments still run unsupported Windows XP systems, ancient versions of Java, and custom tools written a decade ago by a vendor that no longer exists. Each is a time bomb—and now GRASSMARLIN has a CVE to prove it.
For Windows admins, the lesson is clear: regularly inventory the tools your OT teams rely on, track their support status, and have an exit plan before the emergency. The next end-of-life tool to get a vulnerability might be one with a much higher severity—and still no patch.
No known public exploitation of CVE-2026-6807 has been reported to CISA as of this writing, but the advisory’s existence will likely spur both security researchers and threat actors to take a closer look at the archived code. If your GRASSMARLIN installation is still running, now is the moment to pull the plug.