PHPUnit EUVD-2026-113349

All of the following must hold: PHPUnit version 13.4.0-13.4.3 is in use; PHPT tests are executed with code coverage collection enabled (requires a coverage driver such as PCOV or Xdebug); sys_get_temp_dir() is shared between users - e.g. a shared /tmp on Linux/Unix without systemd PrivateTmp, pam_namespace, or a per-user TMPDIR; the attacker has a local account (or controls a process/service running as another user) on the same host; and the attacker creates /tmp/phpunit-phpt before the developer's first coverage run since temp was last cleaned, then wins the race to replace the job file before the child process requires it. Exploitation is LIMITED by: required victim action (a developer must actually run PHPT tests with coverage), the timing/race window, the need for a pre-existing local account, and configuration dependence. Explicitly NOT affected: PHPUnit 12.5 and earlier (temp files written next to the PHPT file), default macOS and Windows (per-user temp directories), and single-user environments such as containers or ephemeral single-user CI runners where no other user can create files in the temp path.

This is a genuine but narrowly-scoped local privilege-escalation issue (CWE-379), not a high-severity remote threat. The supplied CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:L/UI:P, base 5.4 Medium) correctly reflects that exploitation is local, requires an existing low-privileged account (PR:L), depends on a specific attack precondition/timing window (AT:P - the attacker must create the directory before the developer and win a race to swap the job file), and requires the victim to take action (UI:P - a developer must run PHPT tests with code coverage). Impact is high (VC:H/VI:H/VA:H) because successful exploitation yields arbitrary code execution as the developer. The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a real-but-non-urgent fix. No EPSS score and no CISA KEV entry were provided in the input, and there is no indication of active exploitation. However, the official GitHub Security Advisory (GHSA-9vw2-f4vp-x7gf) publishes a complete, step-by-step working proof-of-concept (an attacker script plus full reproduction), so exploit knowledge is fully public even though real-world exploitation is not confirmed. The vendor itself rates likelihood as low because of the stacked prerequisites. Net: patch within the normal cycle; the stacked local/timing/configuration conditions keep real-world risk well below what the 'RCE' tag alone might suggest.

On a Linux build or development host where /tmp is shared between users, a logged-in attacker (e.g. mallory) pre-creates the predictable /tmp/phpunit-phpt directory and runs a watcher that polls for the job file. When the developer (alice) runs PHPT tests with code coverage, the attacker renames the generated phpunit_phpt_<random>.php job file and drops a malicious replacement, which the child process then executes via require with alice's privileges while the test still reports success. A full working PoC for exactly this is published in the GitHub advisory.