Unbounded symlink recursion in PHP Group PHP phar archives can crash processes

Circular symbolic links in phar archives could lead to unbounded recursion, exhausting the C stack and crashing the PHP process, in PHP versions from 8.2.* before 8.2.33, from 8.3.* before 8.3.33, from 8.4.* before 8.4.24, and from 8.5.* before 8.5.9.

PHP Group PHP package ext-phar has a default status of unaffected, with the following specifically affected branches:

• Branch 8.2.*: affected before 8.2.33; the confirmed patched release is 8.2.33.
• Branch 8.3.*: affected before 8.3.33; the confirmed patched release is 8.3.33.
• Branch 8.4.*: affected before 8.4.24; the confirmed patched release is 8.4.24.
• Branch 8.5.*: affected before 8.5.9; the confirmed patched release is 8.5.9.

Other branches or products not listed here should not be inferred to be affected or unaffected without separate evidence.

The flaw is in phar_get_link_source() in ext/phar/util.c, where PHP recursively follows symbolic links in phar archives without a depth limit or cycle detection. A crafted tar-based phar archive containing circular symlinks can therefore cause unbounded recursion, exhaust the C stack, and crash the PHP process. The attacker-controlled input is an archive containing circular symbolic links. The record classifies reachability as local, with no privileges required but active user interaction needed. The advisory does not identify the specific application workflow or API that causes the archive to be processed, so a remote attack path is not established.

The record describes a local attack that has low complexity, requires no privileges, and depends on active user interaction with specially crafted data or an archive. The vendor advisory identifies a tar-based archive containing circular symbolic links as the condition needed to trigger the flaw. No specific remote delivery path or vulnerable endpoint is established by the available evidence. The supplied record does not identify a public exploit or known exploitation; returned enrichment recorded exploitation as none at its assessment time, but that does not prove that later exploitation cannot occur.

The confirmed technical outcome is unbounded recursion that exhausts the C stack and crashes the PHP process. The primary effect is loss of availability for the process or service that depends on it; the record does not establish a confidentiality or integrity impact. The assessed scope is unchanged, with no evidence that the flaw automatically crosses into another security authority. Exploitation requires local reachability and active user interaction, so direct remote exposure would depend on a specific application workflow that processes an attacker-supplied archive, and that workflow is not identified. The duration and breadth of service disruption depend on the deployment's supervision, restart, and worker isolation controls.

The flaw can crash a PHP process while it is processing an archive, interrupting application or worker functionality that depends on that process. If the process is automatically restarted, the operational effect may appear as request failures, worker churn, or service degradation rather than a sustained outage, but the actual result depends on the deployment architecture. Risk is higher in systems that permit untrusted phar archives to be uploaded, imported, or inspected. The record does not describe data disclosure, data modification, or a breach scenario.

1. Upgrade PHP within the deployed branch: upgrade branch 8.2.* to 8.2.33, branch 8.3.* to 8.3.33, branch 8.4.* to 8.4.24, or branch 8.5.* to 8.5.9.
2. Recheck inventory after upgrading to ensure that every PHP runtime using ext-phar, including web workers, CLI jobs, container images, and background processing hosts, has reached the corresponding fixed release.
3. Review pipelines that process phar archives from untrusted sources and limit processing of those archives until the update is complete. This is a precaution, not a vendor-confirmed mitigation.
4. The record and advisory do not provide a separate workaround. Configuration changes or log monitoring alone should therefore not be treated as a substitute for updating.

1. Inventory PHP runtimes and identify the deployed version of the ext-phar package or module across servers, workers, CLI jobs, and containers.
2. Compare each version with the affected branches in affected_summary; do not infer safety merely because the application does not normally use phar archives.
3. Review workflows that accept, unpack, inspect, or otherwise process phar archives, especially where archives can be supplied by users or untrusted sources.
4. Check for PHP process crashes or restarts that coincide with phar archive processing. This is a precautionary investigation signal, not a vendor-confirmed IOC.
5. After updating, verify that every deployed PHP branch has reached its corresponding fixed release. The absence of a related crash or log event does not prove that the system is unaffected.