CVE-2026-95806 in MISP
Summary
by MITRE • 09/22/2026
MISP ships with PHP's phar stream wrapper registered in both its web entry point and its console entry point.
The phar stream wrapper causes PHP to treat a phar archive as a directory, which has two security consequences:
- any filesystem operation on a caller-influenced path that resolves to a phar archive triggers an implicit unserialize() call, creating a deserialization sink; - a relocated application root can reach executable code inside an uploaded phar file, enabling arbitrary code execution as the web user.
No component of MISP, the vendored CakePHP framework, or any runtime-loaded library reads or constructs phar archives. The wrapper therefore serves no legitimate purpose in the MISP runtime and exists solely as an available primitive for an attacker who can influence a filesystem path argument.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified within the Malware Information Sharing Platform (MISP) stems from the default configuration of PHP's Phar stream wrapper, which is registered by default in both the web entry point and the console entry point of the application. This registration allows PHP to treat a PHAR archive file as if it were a directory structure during filesystem operations. While this feature can be useful for certain development or packaging workflows, its presence in a production-facing web application introduces significant security risks when user-controlled input influences any path resolution logic that interacts with the filesystem. The core issue is not necessarily a flaw in MISP's code itself but rather the exposure of an inherent PHP behavior that becomes dangerous when combined with insufficient validation of file paths provided by external actors.
The first major consequence of this configuration is the creation of an implicit deserialization sink. When any filesystem operation, such as reading or listing directory contents, targets a path that resolves to a PHAR archive, PHP automatically attempts to unserialize the metadata stored within the archive header. This process occurs without explicit invocation by the application code, meaning it happens transparently during standard file system interactions. If an attacker can influence the path argument passed to these operations, they can craft a malicious PHAR file containing serialized objects with gadget chains designed for remote code execution or other harmful effects. Upon access, PHP will deserialize these objects, potentially leading to arbitrary command execution depending on the available classes in the runtime environment. This aligns closely with CWE-502, which describes deserialization of untrusted data, a critical vulnerability class that allows attackers to manipulate internal application states and execute code by exploiting trusted libraries or frameworks present in the server's memory space.
The second significant consequence involves arbitrary code execution through file inclusion mechanisms if the application root directory is relocated or improperly configured. Because PHAR archives can be treated as directories containing files, an attacker who uploads a malicious PHAR archive to a location accessible by the web server may trigger PHP's include or require functions to execute code embedded within that archive. This effectively bypasses traditional file upload restrictions that might only check extensions like .php or .exe, since the attack vector relies on the Phar stream wrapper interpreting the uploaded file as a container of executable scripts rather than a static binary. This scenario is particularly dangerous in environments where user uploads are stored in publicly accessible directories and subsequent operations attempt to list or include files from those locations without rigorous validation.
From an operational impact perspective, this vulnerability allows for remote code execution under specific conditions where path traversal or file inclusion logic exists within MISP's handling of uploaded assets or configuration paths. An attacker does not need direct access to the application source code but only needs the ability to upload a PHAR file and trigger its processing through any vulnerable filesystem function in the web entry point. This could lead to full compromise of the underlying server, data exfiltration, or lateral movement within the network infrastructure hosting MISP instances. The risk is exacerbated by the fact that no component of MISP, nor the vendored CakePHP framework, actually requires PHAR archives for legitimate runtime operations. Therefore, the presence of this wrapper serves no functional purpose and exists solely as an attack surface available to adversaries who can manipulate filesystem paths.
To mitigate this vulnerability, it is essential to disable the Phar stream wrapper entirely in production environments where it is not explicitly required. This can be achieved by modifying the PHP configuration file (php.ini) to set phar.readonly=1 or by using ini_set() within application bootstrap files to restrict PHAR access at runtime. Additionally, developers should implement strict allowlisting for all filesystem operations involving user-supplied paths and avoid passing unvalidated input directly into functions like opendir(), scandir(), include, or require. Regular security audits of third-party dependencies and framework configurations are also recommended to ensure that default settings do not introduce unnecessary risks. Aligning with MITRE ATT&CK techniques such as T1059 (Command and Scripting Interpreter) via deserialization gadgets highlights the need for defense-in-depth strategies including input validation, output encoding, and least privilege principles in application deployment architectures.