CVE-2026-77751 is a path traversal in MISP's object-template resolution, but the real vulnerability is the trust boundary that was never modeled at the STIX 2 import seam.
MISP's object templates are resolved by name using an internal mechanism designed for a world where template names originated from trusted internal sources or MISP events within a shared security context. When STIX 2 import was implemented, an attacker-controlled field (x_misp_name from custom STIX objects) gained direct access to this resolution without equivalent threat modeling. The developer who added STIX import almost certainly inherited the existing template resolution code as "somebody else's code" without re-examining whether its implicit trust assumptions still held.
What makes this worse structurally is the persistence dimension. The fix patches both import AND export because the vulnerability's lifecycle spans multiple processing contexts with different privilege levels. Import handles low-privilege user content; export triggers platform-level processing that reaches filesystem paths. The same malicious object name stored in an event can sit dormant until export activates it. This is a classic data flow blind spot—validation at entry point A doesn't protect against the same data being processed at point B where privileges differ.
The blast radius extends beyond the technical severity. MISP is a sharing platform where events cross organizational trust boundaries routinely. An attacker doesn't need to compromise each consuming organization—they compromise the source, and the platform distributes the payload. Stored malicious events can propagate through sharing relationships, re-triggering on export across multiple instances. The CVSS 8.8 captures the technical vulnerability; it doesn't capture exposure-events multiplied by processing-cycles multiplied by sharing-topology-size.
Remediation does two things: rejects non-alphanumeric names at the import seam and falls back to a generic template while preserving the original name in comments. That comment-preservation is intentional forensic breadcrumb—it creates a log of attempted exploitation vectors. But note: the patch fixes the code, not the data. Events containing malicious object names seeded before the patch may still exist in MISP instances worldwide, waiting for export, migration, or cross-instance sharing to trigger them.
Three things to check: First, confirm you're running a version with the dual-sided fix (import AND export patched). Second, review your stored event history for any pre-patch STIX imports that might contain anomalous object names—the remediation may have sanitized them but the original intent is already in your database. Third, examine your sharing topology—who receives your exports, and do those connections trust your instance's import chain?