Circular symbolic links in phar archives could lead to unbounded recursion

CVE-2026-7260 is a stack-exhaustion crash in PHP's ext/phar extension. The function phar_get_link_source() in ext/phar/util.c follows symbolic links inside tar-based phar archives without any depth limit or cycle detection. A crafted phar containing two symlinks pointing at each other causes unbounded C-stack recursion → segfault → PHP process termination. All maintained PHP branches prior to 8.2.33, 8.3.33, 8.4.24, and 8.5.9 are affected. The impact is availability only — no memory corruption leading to code execution, no information disclosure, no integrity violation.

The GHSA advisory (GHSA-vc5h-9ppw-p5f3) rates this Moderate at CVSS 5.5 with a local attack vector and required user interaction. That feels right. The crash kills a single PHP worker; under PHP-FPM (the dominant production deployment model), the master process respawns the worker in milliseconds. Sustained DoS requires repeated delivery of malicious phars, and the attack surface — applications that open untrusted .phar or .tar archives via the phar:// stream wrapper — is a narrow slice of the PHP install base. This is a real bug, but the ceiling is a transient service hiccup, not a breach.

Why this verdict

• DoS-only, no code execution: The crash is a clean SIGSEGV from stack exhaustion. There is no heap corruption, no controlled overwrite, and no path to RCE. The impact ceiling is process termination.
• Auto-recovery blunts operational impact: PHP-FPM (used by >90% of production PHP deployments) respawns crashed workers automatically. A single exploit attempt kills one request, not the service. Sustained DoS requires repeated delivery at a rate exceeding respawn — a high bar against any rate-limited endpoint.
• Narrow reachable surface: The attack requires the target to open an attacker-supplied file via the phar extension. Most PHP applications never invoke phar:// on user-uploaded content. The exposed population is a small fraction of the ~30M PHP servers indexed by Shodan.
• Local vector + user interaction: CVSS classifies this as AV:L/UI:R. In web scenarios, an upload-to-phar-processing chain partially satisfies this remotely, but that pipeline is uncommon and adds friction.
• Role multiplier: PHP runs on web servers (typical role) and occasionally on CI/CD workers or CLI batch processors. Even in a high-value web-tier role, the outcome is a transient worker crash — not domain compromise, not data exfiltration, not supply-chain pivot. The blast radius is host-local, single-process, auto-recovering. No high-value role elevates this beyond MEDIUM because the impact type (availability only, self-healing) caps the damage regardless of where PHP runs.

Why not higher?

Upgrading to HIGH would require either a code-execution path or a persistent denial-of-service that survives process restart. Neither exists here. The auto-respawn behavior of PHP-FPM means even a successful exploit has sub-second impact per request. There is no KEV listing, no active exploitation, and no evidence of weaponization. The attack surface (apps that phar-process uploads) is narrow enough that fleet-wide risk is minimal.

Why not lower?

Downgrading to LOW would undercount the ease of crafting the payload (trivial) and the fact that the phar extension is compiled-in by default on every PHP installation. While the *reachable* surface is small, PHP's install base is enormous, so even a small percentage represents meaningful absolute numbers. A crash is still a crash — it produces log noise, triggers alerts, and could mask other attacks. The 5.5 GHSA score is a reasonable anchor; dropping below 5.0 is not warranted.

1. Disable the phar extension if unused — Add phar.require_hash=1 and remove extension=phar from php.ini if your application does not use phar archives. This eliminates the attack surface entirely. Since there is no noisgate mitigation SLA for MEDIUM, this is an optional hardening step — apply it as part of your standard configuration review.
2. Block .phar and .tar uploads at the WAF/reverse proxy — Configure your WAF or upload handler to reject files with phar-associated extensions and MIME types (application/x-phar, application/x-tar). This prevents delivery of the malicious payload to PHP. Implement as part of your upload allow-list policy.
3. Set PHP-FPM pm.max_children and request_terminate_timeout — Ensure PHP-FPM is configured with a reasonable pm.max_children (e.g., 50–200 depending on server capacity) and request_terminate_timeout to limit the duration of any single request. This contains the blast radius of repeated crash attempts.
4. Monitor for repeated SIGSEGV in PHP-FPM workers — Create a SIEM alert on SIGSEGV or segfault in /var/log/php-fpm/*.log and dmesg. More than 3 crashes in 5 minutes from the same endpoint warrants investigation — it could indicate active exploitation or mask a more serious attack.

Run this script on each PHP host to check whether the installed PHP version is vulnerable. Execute as any user with access to the php binary: bash check_cve_2026_7260.sh. No special privileges required.

#!/usr/bin/env bash
# check_cve_2026_7260.sh
# Checks if the installed PHP version is vulnerable to CVE-2026-7260
# (phar circular symlink stack overflow)
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

PHP_BIN="${1:-php}"

if ! command -v "$PHP_BIN" &>/dev/null; then
  echo "UNKNOWN: php binary not found at '$PHP_BIN'"
  exit 2
fi

VERSION=$($PHP_BIN -r 'echo PHP_VERSION;' 2>/dev/null)
if [[ -z "$VERSION" ]]; then
  echo "UNKNOWN: could not determine PHP version"
  exit 2
fi

MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3 | sed 's/[^0-9].*//')

echo "Detected PHP version: $VERSION"

# Fixed versions: 8.2.33, 8.3.33, 8.4.24, 8.5.9
# Affected: < 8.2.33, < 8.3.33, < 8.4.24, < 8.5.9

if [[ "$MAJOR" -lt 8 ]]; then
  echo "VULNERABLE: PHP $VERSION — PHP 7.x and below are end-of-life and contain this flaw"
  exit 1
fi

if [[ "$MAJOR" -eq 8 ]]; then
  case "$MINOR" in
    2)
      if [[ "$PATCH" -ge 33 ]]; then
        echo "PATCHED: PHP $VERSION contains the fix for CVE-2026-7260"
        exit 0
      else
        echo "VULNERABLE: PHP $VERSION — upgrade to >= 8.2.33"
        exit 1
      fi
      ;;
    3)
      if [[ "$PATCH" -ge 33 ]]; then
        echo "PATCHED: PHP $VERSION contains the fix for CVE-2026-7260"
        exit 0
      else
        echo "VULNERABLE: PHP $VERSION — upgrade to >= 8.3.33"
        exit 1
      fi
      ;;
    4)
      if [[ "$PATCH" -ge 24 ]]; then
        echo "PATCHED: PHP $VERSION contains the fix for CVE-2026-7260"
        exit 0
      else
        echo "VULNERABLE: PHP $VERSION — upgrade to >= 8.4.24"
        exit 1
      fi
      ;;
    5)
      if [[ "$PATCH" -ge 9 ]]; then
        echo "PATCHED: PHP $VERSION contains the fix for CVE-2026-7260"
        exit 0
      else
        echo "VULNERABLE: PHP $VERSION — upgrade to >= 8.5.9"
        exit 1
      fi
      ;;
    *)
      # 8.6+ presumably includes the fix
      echo "PATCHED: PHP $VERSION — version is newer than all affected branches"
      exit 0
      ;;
  esac
fi

# PHP 9+ presumably includes the fix
echo "PATCHED: PHP $VERSION — version is newer than all affected branches"
exit 0

Sources

1. GHSA-vc5h-9ppw-p5f3 — GitHub Security Advisory
2. PHP 8.4 branch fix commit
3. PHP 8.3.33 branch fix commit
4. PHP 8.4.24 tagged release fix
5. PHP ChangeLog
6. Fedora/RHEL package updates for PHP 8.2.33–8.5.9
7. GBHackers — PHP Patches 3 Security Flaws