PHP Group PHP Phar TAR parser integer overflow enables archive entry injection

phar_tar_number() parses the octal size field of a TAR header into a uint32_t with no overflow check. The field is 11 octal digits wide and holds values up to 0x1FFFFFFFF, so a size above 0xFFFFFFFF silently wraps. The parser then skips the wrong number of data blocks and interprets attacker-controlled file content as the next TAR header, which lets a crafted archive inject entries that PharData reports and extracts as if they were genuine.

PHP Group PHP has a default status of unaffected outside the branches listed in the record. The supported affected and fixed boundaries are:

• Branch 8.2.*: affected when less than 8.2.34; the listed fix is 8.2.34.
• Branch 8.3.*: affected when less than 8.3.35; the listed fix is 8.3.35.
• Branch 8.4.*: affected when less than 8.4.26; the listed fix is 8.4.26.
• Branch 8.5.*: affected when less than 8.5.11; the listed fix is 8.5.11.

Do not infer the status of other branches or distribution packages from these boundaries alone. Verify the deployed PHP package against the vendor advisory and the package source used by the deployment.

phar_tar_number() parses the octal size field of a TAR header into uint32_t without checking for overflow. The field is 11 octal digits wide and can represent values through 0x1FFFFFFFF, so values above 0xFFFFFFFF silently wrap. The wrapped size causes the parser to skip the wrong number of data blocks and then interpret attacker-controlled content as the next TAR header. When an application uses PharData or the phar:// stream wrapper to open an untrusted archive, injected entries can appear genuine and be written to disk by extractTo(). The PHP advisory states that the fix changes size parsing to uint64_t, rejects invalid values, and corrects data-block handling for entry types that carry data. The evidence does not establish how a particular application authorizes or uses extracted files.

The record classifies exploitation as local, with low complexity, no authentication requirement, and no user interaction requirement. The prerequisite is that an application or tool processes a specially crafted TAR or TAR.GZ through PharData or phar://; the evidence does not by itself establish a remote network attack path. The record marks public_exploit as true, and the returned enrichment identifies a proof of concept. The supplied evidence does not identify an active campaign, a specific victim, or exploitation in the wild.

When the parser processes a size field beyond the uint32_t limit, the value wraps and TAR data boundaries are calculated incorrectly. Attacker-controlled file content can then be read as a new header, causing PharData to report fabricated entries and extractTo() to write them to disk. The technical effect is an integrity change to the archive view and extracted files, potentially affecting dependency or application output directories. The record does not establish privilege escalation, information disclosure, or denial of service as consequences of this flaw. The practical outcome depends on whether the application processes untrusted archives and what write permissions the extraction process has.

The flaw can make archive validation disagree with the files actually written to the destination, creating an integrity risk for data and software artefacts.

• Applications using PharData or phar:// may see entries that do not match the archive structure presented to other tools.
• extractTo() can write injected entries to disk, allowing validation to inspect one file set while extraction produces another.
• Composer's TarDownloader uses PharData and then extracts TAR.GZ packages into vendor/, so a crafted package can place files there.
• Further consequences depend on which files are written and how the application uses them; the evidence does not establish data disclosure or loss of availability.

1. Upgrade within the deployed branch: update branch 8.2.* to 8.2.34, branch 8.3.* to 8.3.35, branch 8.4.* to 8.4.26, or branch 8.5.* to 8.5.11.
2. Verify the actual PHP package used by the workload after updating, ensuring that ext-phar received the fix rather than updating an unused binary or image.
3. Until the update is complete, avoid sending untrusted TAR or TAR.GZ archives through PharData, phar://, or Composer TarDownloader where the workflow permits.
4. Add independent manifest and content checks before extraction as a temporary risk-reduction measure. This does not replace the vendor fix.
5. Do not treat a fixed release on one branch as an open-ended fix for every other branch. Verify branches outside the listed boundaries separately.

1. Inventory PHP servers and jobs, identifying deployments with ext-phar and workloads that use PharData, phar://, or Composer TarDownloader.
2. Compare deployed PHP versions with the affected branches and corresponding fixed releases listed in affected_summary.
3. Review TAR and TAR.GZ intake and extraction workflows, especially processes that validate an archive manifest before calling extractTo().
4. Review application and package-manager records for untrusted archives processed through these paths, together with unexpected files appearing in extraction destinations such as vendor/. This is a review signal, not a vendor-confirmed IOC.
5. Where practical, compare the entries reported by PharData with the result from an independent TAR parser. A mismatch is a review signal, but the absence of a mismatch does not prove that the system is safe.