SURIQ
The software defenders use to collect threat intelligence is built to accept data from strangers. That is the whole point of a sharing platform, and it is also why a parsing bug in one deserves attention. On August 21, 2026, CIRCL published CVE-2026-77751, a path traversal flaw rated 8.8 in misp-stix, the library that MISP uses to translate records to and from STIX. MISP is an open-source threat-intelligence sharing platform; STIX (Structured Threat Information Expression) is the standard format teams use to trade indicators. A booby-trapped name inside imported data can make the converter read a file from outside its own folder and fold that file's contents into your threat data.
This is not remote code execution, and it helps to say that up front. What an attacker gets is the contents of a local file the process can reach, plus the ability to quietly change the meaning of a converted object. For a platform whose job is ingesting hostile input, that is still a problem worth moving on.
How does the flaw work?
MISP names each kind of indicator with an object template stored in a folder. The converter finds a template by joining that folder, the object's name, and a definition file into one path. Before the fix, a name that arrived in imported data was trusted as written, so ../ characters let the lookup climb out of the intended folder.
If a usable definition file sits at the escaped location, its fields are read back as though they were a legitimate template and copied into the converted object. On import, the attacker controls this through the x_misp_name value of a custom STIX object, with no account on your instance and nothing for your team to click. The reachable file's contents leak into data your analysts then treat as normal intelligence. It is the same class of mistake we saw when repository metadata could reach outside its lane in SUSE's package layer: a name from an untrusted source became a file path.
The part that makes it worse: it can wait
A malicious name does not have to do its damage the moment it lands. The second patch covers the export side, and that is the more interesting half. A crafted name can sit stored inside a MISP event and trigger later, when that event is converted back to STIX. Export routinely runs as automation, sometimes under a different or higher privilege than the analyst who imported the original data. So content one person pulled from a low-trust feed on a Monday can reach the filesystem weeks later through a scheduled job nobody is watching.
Stored path traversal is harder to catch than the parse-at-import kind precisely because the trigger and the ingestion are separated in time. You cannot reason about it by looking only at what came in today. It behaves the way a rigged sync update that reaches sensitive logic downstream does: the poison enters through a trusted channel and detonates somewhere else.
How exposed are you, really?
The 8.8 score reflects a network-reachable bug that needs no privileges and no interaction, with high impact on confidentiality and low impact on integrity. Read that literally. An attacker who can place a crafted object into STIX you ingest can read a file on your server and can tamper with an object's metadata. That is the ceiling, not code execution or takeover.
The real question is where your STIX comes from. A closed instance that only imports data your own team produces has little to worry about here. An instance that subscribes to public feeds, federates with partners, or accepts custom objects from a wide sharing community has a genuine path: an adversary who can get one crafted object into a feed you trust reaches your host. The broader and more automatic your ingestion, the more this matters, the same trust-the-package assumption that burned teams when packages that passed inspection turned hostile a day later.
What to do now
Confirm your build first. Every misp-stix release up to and including 2026.7.8 is affected. The fix landed in the project repository on August 13, 2026, as two commits covering the import and export paths, credited to reporter Jeroen Pinoy and CIRCL maintainer Christian Studer. At the time of writing the newest tagged release still predates that fix, so pulling the latest published version is not enough on its own. Confirm your installed misp-stix includes both commits, or move to the first release cut after them.
Reduce the interim blast radius. Until you are on a fixed build, treat custom-object names from low-trust STIX as suspect, and tighten which feeds and partners are allowed to push custom objects into your instance.
Turn the patch into a hunt. The fix does something useful for defenders: when it rejects a bad name, it rewrites the object to a generic unknown-template name, preserves the original name in the object's comment, and logs a warning. Those warnings are not noise. Each one points at a piece of imported content that carried a traversal-shaped name, which is exactly the material you want to review after an upgrade. Independently, watch for the MISP or PyMISP process opening definition files outside its configured object-templates directory.
Revisit what you already stored. Because export can trigger on old data, review events ingested from untrusted feeds before you patched. A poisoned name from last month is still live until the event is re-converted on a fixed build.
The lesson is older than this bug. Any parser that turns names supplied by strangers into file paths is a path traversal waiting to happen, and a threat-intelligence platform parses hostile input for a living. Treat the ingestion boundary as the perimeter it actually is, and give the same scrutiny to the intel you consume that you give to the code you run.