CVE-2026-77755 in misp-stix
Summary
by MITRE • 08/21/2026
A denial-of-service vulnerability was identified in misp-stix when processing attacker-controlled STIX 1 or STIX 2 documents.
The STIX import code used sys.exit() to handle several parsing and loading failures. Because SystemExit inherits from BaseException rather than Exception, these failures bypassed the exception handlers used by callers of the library. As a result, a malformed STIX document could terminate a long-running importer process instead of returning a recoverable parsing error.
Additionally, no limit was imposed on the size of STIX documents before parsing. A submitted document was therefore read and materialised in memory before its validity or type was evaluated. Depending on the document and parsing path, processing could consume approximately two to seven times the input size in memory, allowing a sufficiently large STIX document to cause excessive memory and CPU consumption and potentially terminate or severely degrade the importing service.
An attacker able to provide STIX content to a MISP-STIX import workflow could exploit either condition to affect availability. A malformed document could cause abnormal process termination through an uncaught SystemExit, while a large document could exhaust resources during deserialisation and conversion.
The fixes replace process-terminating sys.exit() calls with catchable exceptions such as STIXLoadingError and MissingSTIXContentError, and extend exception handling around the complete STIX detection and conversion process. The importer also now enforces an input-size limit before parsing. The default maximum is 100 MB, can be adjusted by callers, and can explicitly be disabled when required. STIX 1 inputs are additionally checked for the expected root element before the complete XML tree is constructed.
ImpactSuccessful exploitation can cause:
* termination of a long-running MISP-STIX importer; * excessive memory allocation; * excessive CPU consumption; * degradation or temporary unavailability of services relying on the converter; * interruption of batch or automated STIX ingestion workflows.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/21/2026
The identified vulnerability in misp-stix represents a critical availability risk stemming from improper exception handling and resource management during the processing of Security Incident Text (STIX) documents, specifically versions 1 and 2. The core technical flaw lies in the use of sys.exit() to handle parsing and loading failures within the library's import code. In Python, SystemExit inherits directly from BaseException rather than Exception, which means it bypasses standard exception handlers that typically catch ValueError, TypeError, or other common runtime errors. Consequently, when a malformed STIX document triggers one of these internal exit calls, the error is not caught by the calling application logic designed to handle recoverable parsing issues. Instead, the entire process terminates abruptly. This behavior violates fundamental principles of robust software design where external inputs should trigger controlled failures rather than catastrophic system exits, aligning with CWE-754: Improper Check for Unusual or Exceptional Conditions and CWE-248: Unhandled Exception.
Beyond the exception handling flaw, a significant resource exhaustion vulnerability exists due to the absence of input size limits prior to parsing. The library reads and materializes the entire STIX document into memory before evaluating its validity or type. This eager loading strategy means that even invalid documents consume substantial resources during deserialization and conversion processes. Depending on the specific structure of the malicious payload, processing can consume approximately two to seven times the input size in memory. An attacker providing a sufficiently large STIX document can therefore trigger excessive memory allocation and CPU consumption, leading to severe performance degradation or complete service unavailability for systems relying on the converter. This characteristic is indicative of CWE-400: Uncontrolled Resource Consumption and maps directly to ATT&CK technique T1496: Resource Hijacking, where an adversary uses computing resources to disrupt availability rather than compromising confidentiality or integrity.
The operational impact of exploiting these vulnerabilities is severe for organizations utilizing automated STIX ingestion workflows. Successful exploitation allows a remote attacker to cause the termination of long-running MISP-STIX importer processes through uncaught SystemExit exceptions triggered by malformed documents. Alternatively, an attacker can exhaust system resources via large payloads, resulting in excessive memory allocation and CPU spikes that degrade or temporarily halt services dependent on threat intelligence sharing capabilities. This disruption interrupts batch processing pipelines and automated ingestion workflows, effectively creating a denial-of-service condition against the threat intelligence platform's ability to ingest new data. The availability of critical security information is compromised, potentially leaving defenders blind to emerging threats during the period of service degradation.
Mitigation strategies implemented in recent updates address these flaws by replacing process-terminating sys.exit() calls with catchable exceptions such as STIXLoadingError and MissingSTIXContentError. This change ensures that parsing failures are handled gracefully within the application's exception handling framework, allowing for recovery or logging without terminating the host process. Furthermore, an input-size limit is now enforced before any parsing occurs, with a default maximum of 100 MB configurable by callers to suit specific operational requirements. For STIX version 1 inputs, additional validation checks verify the expected root element before constructing the complete XML tree, preventing unnecessary resource consumption on invalid structures early in the processing pipeline. These measures collectively restore resilience against both malformed input attacks and resource exhaustion attempts, aligning with secure coding practices recommended by industry standards for handling untrusted data streams.