GHSA-VVJ3-C3RP-C85P

Vulnerability from github – Published: 2026-01-27 22:26 – Updated: 2026-01-27 22:26
VLAI?
Summary
PHPUnit Vulnerable to Unsafe Deserialization in PHPT Code Coverage Handling
Details

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

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 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
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpunit/phpunit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "8.5.52"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpunit/phpunit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "9.0.0"
            },
            {
              "fixed": "9.6.33"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpunit/phpunit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "10.0.0"
            },
            {
              "fixed": "10.5.62"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpunit/phpunit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "11.0.0"
            },
            {
              "fixed": "11.5.50"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpunit/phpunit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "12.0.0"
            },
            {
              "fixed": "12.5.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24765"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-27T22:26:22Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Overview\n\nA 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.\n\n### Technical Details\n\n**Affected Component:** PHPT test runner, method `cleanupForCoverage()`\n**Affected Versions:** \u003c= 8.5.51, \u003c= 9.6.32, \u003c= 10.5.61, \u003c= 11.5.49, \u003c= 12.5.7\n\n### Vulnerable Code Pattern\n\n```php\nif ($buffer !== false) {\n    // Unsafe call without restrictions\n    $coverage = @unserialize($buffer);\n}\n```\n\nThe 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.\n\n### Attack Prerequisites and Constraints\n\nThis vulnerability requires **local file write access** to the location where PHPUnit stores or expects code coverage files for PHPT tests. This can occur through:\n\n* **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\n* **Local Development Environment:** An attacker with shell access or ability to write files to the project directory\n* **Compromised Dependencies:** A supply chain attack inserting malicious files into a package or monorepo\n\n**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.\n\n### Proposed Remediation Approach\n\nRather than just silently sanitizing the input via `[\u0027allowed_classes\u0027 =\u003e false]`, the maintainer has chosen to make the anomalous state explicit by treating pre-existing `.coverage` files for PHPT tests as an error condition.\n\n#### Rationale for Error-Based Approach:\n\n1. **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\n2. **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:\n    * A malicious actor placed it intentionally\n    * Build artifacts from a previous run contaminated the environment\n    * An unexpected filesystem state requiring investigation\n3. **Defense-in-Depth Principle:** Protecting a single deserialization call does not address the fundamental attack surface. Proper mitigations for PPE attacks lie outside PHPUnit\u0027s scope:\n    * Isolate CI/CD runners (ephemeral, containerized environments)\n    * Restrict code execution on protected branches\n    * Scan pull requests and artifacts for tampering\n    * Use branch protection rules to prevent unreviewed code execution\n\n### Severity Classification\n\n* **Attack Vector (AV):** Local (L) \u2014 requires write access to the file system where tests execute\n* **Attack Complexity (AC):** Low (L) \u2014 exploitation is straightforward once the malicious file is placed\n* **Privileges Required (PR):** Low (L) \u2014 PR submitter status or contributor role provides sufficient access\n* **User Interaction (UI):** None (N) \u2014 automatic execution during standard test execution\n* **Scope (S):** Unchanged (U) \u2014 impact remains within the affected test execution context\n* **Confidentiality Impact (C):** High (H) \u2014 full remote code execution enables complete system compromise\n* **Integrity Impact (I):** High (H) \u2014 arbitrary code execution allows malicious modifications\n* **Availability Impact (A):** High (H) \u2014 full code execution permits denial-of-service actions\n\n### Mitigating Factors (Environmental Context)\n\nOrganizations can reduce the effective risk of this vulnerability through proper CI/CD configuration:\n\n* **Ephemeral Runners:** Use containerized, single-use CI/CD runners that discard filesystem state between runs\n* **Code Review Enforcement:** Require human review and approval before executing code from pull requests\n* **Branch Protection:** Enforce branch protection rules that block unreviewed code execution\n* **Artifact Isolation:** Separate build artifacts from source; never reuse artifacts across independent builds\n* **Access Control:** Limit file write permissions in CI environments to authenticated, trusted actors\n\n### Fixed Behaviour\n\nWhen 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:\n\n* **Visibility:** The error appears prominently in CI/CD output and test logs\n* **Investigation:** Operations teams can investigate the root cause (potential tampering, environment contamination)\n* **Fail-Fast Semantics:** Test execution stops rather than proceeding with an unexpected state\n\n### Recommendation\n\n**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\u0027s CI/CD configuration to ensure:\n\n* Pull requests from forks or untrusted sources execute in isolated environments\n* Branch protection rules require human review before code execution\n* CI/CD runners are ephemeral and discarded after each build\n* Build artifacts are not reused across independent runs without validation",
  "id": "GHSA-vvj3-c3rp-c85p",
  "modified": "2026-01-27T22:26:22Z",
  "published": "2026-01-27T22:26:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/security/advisories/GHSA-vvj3-c3rp-c85p"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/commit/613d142f5a8471ca71623ce5ca2795f79248329e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sebastianbergmann/phpunit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/releases/tag/10.5.63"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/releases/tag/11.5.50"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/releases/tag/12.5.8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/releases/tag/8.5.52"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebastianbergmann/phpunit/releases/tag/9.6.33"
    },
    {
      "type": "WEB",
      "url": "https://owasp.org/www-project-top-10-ci-cd-security-risks/CICD-SEC-04-Poisoned-Pipeline-Execution"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PHPUnit Vulnerable to Unsafe Deserialization in PHPT Code Coverage Handling"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…