CVE-2026-95806: MISP: PHP phar stream wrapper enables deserialization and code execution via caller-influenced filesystem paths
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Call stream_wrapper_unregister('phar') at the top of both the web and console entry points, before framework bootstrap or application code executes.
MISP PHP runtime phar stream wrapper = unregistered
Event History
Frequently Asked Questions
Who is exposed to this issue?
MISP deployments are exposed because the phar stream wrapper is registered in both the web and console entry points. The practical risk applies where an attacker can influence a filesystem path that resolves to a phar archive; a relocated application root can also reach executable code in an uploaded phar file.
What does an attacker need to exploit it?
The attacker needs influence over a filesystem path argument that PHP resolves through the phar stream wrapper. If that path points to a phar archive, filesystem operations can trigger implicit deserialization; an uploaded phar file combined with a relocated application root can enable code execution as the web user.
Is the phar wrapper required for normal MISP operation?
No. The available information states that MISP, its vendored CakePHP framework, and runtime-loaded libraries do not read or construct phar archives, so the wrapper has no legitimate purpose in the MISP runtime.
What can be done if patching cannot happen immediately?
Remove or disable PHP's phar stream wrapper in the MISP web and console runtimes, since it is not needed for normal operation according to the provided information. Also prevent untrusted users from influencing filesystem path arguments or placing uploaded phar files where application paths could resolve to them.