misp-stix cross-document parser state contamination (CVSS 4.0 6.3), reused parser instances retained galaxy data, references, titles and timestamps across conversions, so one document's content can appear in the event generated from the next. Last affected 2026.7.8; fixed by commits only.

Three misp-stix flaws put the CTI pipeline itself in scope: a crafted STIX document can set its own MISP distribution and sharing fields, kill a long-running importer, or bleed data into the next event

Three CVEs published on 2026-08-21 against misp-stix (the Python library MISP and other threat-intelligence platforms use to convert between MISP's own format and STIX 1 / STIX 2) sit in the ingestion path of the intelligence pipeline rather than in an internet-facing service, which is what makes them relevant to a constituency whose national CERTs, ISACs and sector sharing communities run MISP.

The one that changes a trust assumption is CVE-2026-77710 (CVSS 4.0 base 6.9). The import logic chose between the internal-MISP parser and the external-STIX parser using metadata carried in the document itself: MISP-specific tool labels for STIX2, the document title for STIX1. The advisory states plainly that "These classification indicators are fully controlled by the STIX producer and therefore cannot constitute a trusted indication of the document's origin" (MISP Project advisory, 2026-08-21). When a document was accepted as an internal export, attributes inside an x-misp-object were converted by copying the entire x_misp_attributes dictionary straight into add_attribute(), so a crafted bundle could supply fields outside the expected round-trip format, the advisory names distribution, sharing_group_id and tags specifically. The consequence it draws is the one that matters operationally: imported intelligence could be given sharing restrictions or classification the importing organisation never chose, "potentially causing information to be shared contrary to the importing organization's policy", or could carry attacker-chosen tags that downstream automation keys on. The fix introduces an explicit classification parameter so the caller decides, and restricts assignment to an allow-list.

CVE-2026-77755 (8.7) is the availability half. The importer used sys.exit() on several parse and load failures; because SystemExit inherits from BaseException rather than Exception, those failures walked straight past the except Exception handlers a calling application would normally wrap an import in, so "a malformed STIX document could terminate a long-running importer process instead of returning a recoverable parsing error" (MISP Project advisory, 2026-08-21). Separately, no size limit was applied before parsing, and the advisory puts memory use during conversion at roughly two to seven times the input size, so a large crafted document degrades or kills the service during deserialisation. The fixes replace the exits with catchable exceptions and add a size ceiling, defaulting to 100 MB, that callers can adjust or disable.

CVE-2026-77761 (6.3) is narrower and depends on how the library is called. Several STIX1 and STIX2 parser components kept per-document state across a reset (galaxy and galaxy-cluster data, references, passive DNS bookkeeping, package titles, dates and timestamps) so reusing one parser instance across independent documents could produce an event carrying information that was only present in an earlier one. The advisory notes an attacker who can influence what such a long-lived parser processes "could potentially cause information from one conversion to contaminate a subsequent MISP event", and flags that where consecutive documents carry different distribution scopes the retained state can disclose a little of the earlier one (MISP Project advisory, 2026-08-21). Entry points that instantiate a fresh parser per file are not affected.

None of the three is reported as exploited, and each carries an EPSS below 0.4% on its own record, 0.29 for the trust-boundary flaw (ENISA EU Vulnerability Database, 2026-08-21), 0.30 for the denial of service (ENISA EU Vulnerability Database, 2026-08-21) and 0.37 for the state-contamination flaw (ENISA EU Vulnerability Database, 2026-08-21). The reason they still warrant attention is the remediation state: the last affected version is 2026.7.8 and no tagged release yet carries any of the fixes; remediation today means applying individual commits.