Staging Environment: Content and features may be unstable or change without notice.
Search for packages
Package details: pkg:composer/phpunit/phpunit@5.3.0
purl pkg:composer/phpunit/phpunit@5.3.0
Next non-vulnerable version 8.5.52
Latest non-vulnerable version 13.1.6
Risk 10.0
Vulnerabilities affecting this package (2)
Vulnerability Summary Fixed by
VCID-6bt7-kw89-v3dt
Aliases:
CVE-2026-24765
GHSA-vvj3-c3rp-c85p
PHPUnit Vulnerable to Unsafe Deserialization in PHPT Code Coverage Handling ### Overview A vulnerability has been discovered involving unsafe deserialization of code coverage data in PHPT test execution. The vulnerability exists in the `cleanupForCoverage()` method, which deserializes code coverage files without validation, potentially allowing remote code execution if malicious `.coverage` files are present prior to the execution of the PHPT test. ### Technical Details **Affected Component:** PHPT test runner, method `cleanupForCoverage()` **Affected Versions:** <= 8.5.51, <= 9.6.32, <= 10.5.61, <= 11.5.49, <= 12.5.7 ### Vulnerable Code Pattern ```php if ($buffer !== false) { // Unsafe call without restrictions $coverage = @unserialize($buffer); } ``` The vulnerability occurs when a `.coverage` file, which should not exist before test execution, is deserialized without the `allowed_classes` parameter restriction. An attacker with local file write access can place a malicious serialized object with a `__wakeup()` method into the file system, leading to arbitrary code execution during test runs with code coverage instrumentation enabled. ### Attack Prerequisites and Constraints This vulnerability requires **local file write access** to the location where PHPUnit stores or expects code coverage files for PHPT tests. This can occur through: * **CI/CD Pipeline Attacks:** A malicious pull request that places a `.coverage` file alongside test files, executed when the CI system runs tests using PHPUnit and collects code coverage information * **Local Development Environment:** An attacker with shell access or ability to write files to the project directory * **Compromised Dependencies:** A supply chain attack inserting malicious files into a package or monorepo **Critical Context:** Running test suites from unreviewed pull requests without isolated execution is inherently a code execution risk, independent of this specific vulnerability. This represents a broader class of [Poisoned Pipeline Execution (PPE) attacks](https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-04-Poisoned-Pipeline-Execution) affecting CI/CD systems. ### Proposed Remediation Approach Rather than just silently sanitizing the input via `['allowed_classes' => false]`, the maintainer has chosen to make the anomalous state explicit by treating pre-existing `.coverage` files for PHPT tests as an error condition. #### Rationale for Error-Based Approach: 1. **Visibility Over Silence:** When an invariant is violated (a `.coverage` file existing before test execution), the error must be visible in CI/CD output, alerting operators to investigate the root cause rather than proceeding with sanitized input 2. **Operational Security:** A `.coverage` file should never exist before tests run, coverage data is generated by executing tests, not sourced from artifacts. Its presence indicates: * A malicious actor placed it intentionally * Build artifacts from a previous run contaminated the environment * An unexpected filesystem state requiring investigation 3. **Defense-in-Depth Principle:** Protecting a single deserialization call does not address the fundamental attack surface. Proper mitigations for PPE attacks lie outside PHPUnit's scope: * Isolate CI/CD runners (ephemeral, containerized environments) * Restrict code execution on protected branches * Scan pull requests and artifacts for tampering * Use branch protection rules to prevent unreviewed code execution ### Severity Classification * **Attack Vector (AV):** Local (L) — requires write access to the file system where tests execute * **Attack Complexity (AC):** Low (L) — exploitation is straightforward once the malicious file is placed * **Privileges Required (PR):** Low (L) — PR submitter status or contributor role provides sufficient access * **User Interaction (UI):** None (N) — automatic execution during standard test execution * **Scope (S):** Unchanged (U) — impact remains within the affected test execution context * **Confidentiality Impact (C):** High (H) — full remote code execution enables complete system compromise * **Integrity Impact (I):** High (H) — arbitrary code execution allows malicious modifications * **Availability Impact (A):** High (H) — full code execution permits denial-of-service actions ### Mitigating Factors (Environmental Context) Organizations can reduce the effective risk of this vulnerability through proper CI/CD configuration: * **Ephemeral Runners:** Use containerized, single-use CI/CD runners that discard filesystem state between runs * **Code Review Enforcement:** Require human review and approval before executing code from pull requests * **Branch Protection:** Enforce branch protection rules that block unreviewed code execution * **Artifact Isolation:** Separate build artifacts from source; never reuse artifacts across independent builds * **Access Control:** Limit file write permissions in CI environments to authenticated, trusted actors ### Fixed Behaviour When a `.coverage` file is detected for a PHPT test prior to execution, PHPUnit will emit a clear error message identifying the anomalous state. This ensures: * **Visibility:** The error appears prominently in CI/CD output and test logs * **Investigation:** Operations teams can investigate the root cause (potential tampering, environment contamination) * **Fail-Fast Semantics:** Test execution stops rather than proceeding with an unexpected state ### Recommendation **Update to the patched version immediately** if a project runs PHPT tests using PHPUnit with coverage instrumentation in any CI/CD environment that executes code from external contributors. Additionally, audit the project's CI/CD configuration to ensure: * Pull requests from forks or untrusted sources execute in isolated environments * Branch protection rules require human review before code execution * CI/CD runners are ephemeral and discarded after each build * Build artifacts are not reused across independent runs without validation
8.5.52
Affected by 0 other vulnerabilities.
9.6.33
Affected by 0 other vulnerabilities.
10.5.62
Affected by 0 other vulnerabilities.
11.5.50
Affected by 0 other vulnerabilities.
12.5.8
Affected by 0 other vulnerabilities.
VCID-ks7b-f17t-dfd4
Aliases:
CVE-2017-9841
GHSA-r7c9-c69m-rph8
Code Injection in PHPUnit Util/PHP/eval-stdin.php in PHPUnit starting with 4.8.19 and before 4.8.28, as well as 5.x before 5.6.3, allows remote attackers to execute arbitrary PHP code via HTTP POST data beginning with a `<?php ` substring, as demonstrated by an attack on a site with an exposed /vendor folder, i.e., external access to the /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php URI.
5.6.3
Affected by 1 other vulnerability.
Vulnerabilities fixed by this package (0)
Vulnerability Summary Aliases
This package is not known to fix vulnerabilities.