If you write PHP code for a living — or if your company's website runs on PHP — a quietly devastating flaw in one of the most trusted developer tools on the planet could hand an attacker full control of the machine running your software tests.

Who Is at Risk — and How Big Is This?

PHPUnit is not a niche product. It is the standard testing framework for PHP, the language that quietly powers an estimated 75% of all websites on the internet — including WordPress, Wikipedia, and vast stretches of e-commerce. PHPUnit is downloaded hundreds of millions of times per year via Composer, PHP's package manager. Virtually every professional PHP development team uses it.

The vulnerability, tracked as CVE-2026-24765, affects PHPUnit versions 8, 9, 10, 11, and 12 — essentially the entire actively used history of the product. That means the exposure window covers development pipelines, continuous integration servers, cloud build environments, and individual developer laptops all at once. If your build server runs PHPUnit and an attacker can sneak a single poisoned file onto it, they may be able to run any code they choose.

What Is Actually Happening Here — in Plain English

Imagine your testing tool keeps a little notebook between test runs. After it checks your code, it writes down the results in a file with a .coverage extension — basically a record of which lines of code were exercised during testing. The next time tests run, the tool might glance at that notebook before it gets started. That seems harmless enough, right?

Here is the problem: the tool is not just reading that notebook — it is trusting it completely. In software terms, it is "deserializing" the file, which means it takes the data stored in that file and reassembles it back into live, active code objects inside the program. If a normal developer wrote that file, great — no problem. But if an attacker replaced that file with a specially crafted poisoned version before the tests ran, the testing tool would cheerfully reassemble that attacker's malicious instructions into live code and execute them. The attacker's code runs with whatever privileges the developer or build server has — which is often quite broad.

The especially sneaky part is the timing. A .coverage file should not exist before a test run begins — it gets created during the run. So if PHPUnit finds one already sitting there when it starts up, that is actually a red flag that something is wrong. But instead of stopping and raising an alarm, vulnerable versions of PHPUnit simply open the file and execute whatever is inside it. An attacker who can write a single file to a build directory — through a compromised dependency, a misconfigured server, or even a malicious pull request — could use this to plant their payload and wait for the next scheduled test run to detonate it.

The Technical Detail Security Teams Need to Know

The root cause lives in a method called cleanupForCoverage(), located in PHPUnit's PHPT test execution engine. The method deserializes .coverage files using PHP's native unserialize() function — critically, without specifying an allowed_classes whitelist parameter. This is a textbook PHP Object Injection vulnerability. Without the allowed_classes restriction, PHP will reconstruct any class present in the codebase from the serialized data, enabling classic Property-Oriented Programming (POP) chain exploitation. The vulnerability is classified CVSS 7.8 (HIGH) on a cross-platform basis, meaning it is reproducible on Linux, macOS, and Windows build environments alike. Exploitation requires the ability to write a file to the test execution directory — a condition that is realistic in shared CI/CD pipelines, compromised package repositories, or supply-chain attack scenarios.

Has Anyone Been Attacked Yet?

As of publication, no active exploitation has been confirmed in the wild. The vulnerability was responsibly disclosed to the PHPUnit maintainers, who have released patched versions across all supported branches. That said, the security community's concern level is elevated — and for good reason. PHPUnit has been targeted before: in 2017, a different PHPUnit flaw (CVE-2017-9841) became one of the most widely exploited developer-tool vulnerabilities of that year, used by botnet operators to compromise thousands of servers that had accidentally exposed their test directories to the internet. History has a way of repeating itself with beloved developer tools that organizations forget to treat as attack surface.

The current flaw is particularly attractive to supply-chain attackers — threat actors who compromise software at the build or dependency level rather than attacking production servers directly. A poisoned .coverage file could theoretically be introduced through a malicious package update, a compromised shared build cache, or a rogue contributor submitting a pull request to an open-source project. No patch for developer negligence exists — only urgency.

What You Should Do Right Now — 3 Specific Steps

1. Update PHPUnit immediately to a patched version.
   Run composer update phpunit/phpunit in your project directory. The patched versions are:
   
   • PHPUnit 12.x → upgrade to 12.5.8 or later
   • PHPUnit 11.x → upgrade to 11.5.50 or later
   • PHPUnit 10.x → upgrade to 10.5.62 or later
   • PHPUnit 9.x → upgrade to 9.6.33 or later
   • PHPUnit 8.x → upgrade to 8.5.52 or later
   Confirm your installed version with ./vendor/bin/phpunit --version. If you are running a version of PHPUnit older than version 8, it is end-of-life and you should treat it as fully compromised — migrate immediately.
2. Audit your CI/CD pipeline for unexpected .coverage files.
   Search your build directories, artifact stores, and shared caches for any .coverage files that were not generated by your own recent test runs. On Linux and macOS, you can run: find . -name "*.coverage" -not -path "*/vendor/*". Any file you cannot account for should be treated as suspicious and deleted immediately. Lock down write permissions on your test execution directories so only authorized processes can create files there.
3. Review access controls on your build and test infrastructure.
   This vulnerability requires an attacker to be able to write a file to your test directory. Audit who — and what — has write access to your CI/CD build environments. Ensure that third-party dependencies are pinned to specific, verified versions using composer.lock and that your lock file is committed and reviewed. Consider enabling Composer's audit command (composer audit) in your pipeline to flag known vulnerable packages automatically on every build.

The Bottom Line

CVE-2026-24765 is a sharp reminder that the tools developers use to verify their software can themselves become attack vectors. PHPUnit sits inside millions of build pipelines worldwide, often with elevated permissions and network access, and it is rarely treated with the same security scrutiny as production software. That asymmetry is exactly what sophisticated attackers look for. Patch today, audit your pipelines, and treat your development infrastructure as the high-value target it has always been.

🔴 No active exploitation confirmed — but the window between "no known attacks" and "widespread exploitation" has historically been very short for PHP tooling vulnerabilities. Do not wait.