Summary
PhpSpreadsheet's WEBSERVICE() function allows bypassing its domain whitelist by following HTTP redirects without re-validating the final destination, enabling server-side request forgery.
When an attacker can upload or control spreadsheets processed with WEBSERVICE() and domain whitelisting, they may force the server to read data from arbitrary internal or external URLs and return it into cell values.
PhpSpreadsheet's WEBSERVICE() function allows bypassing its domain whitelist by following HTTP redirects without re-validating the final destination, enabling server-side request forgery.
When an attacker can upload or control spreadsheets processed with WEBSERVICE() and domain whitelisting, they may force the server to read data from arbitrary internal or external URLs and return it into cell values.
Affected context
This vulnerability arises in applications that:
- Integrate PhpSpreadsheet to evaluate formulas, especially WEBSERVICE()
- Rely on Spreadsheet::setDomainWhiteList() to restrict outbound HTTP calls
- Call getCalculatedValue() (or equivalent) on user-supplied or semi-trusted XLSX files
- Run PhpSpreadsheet in environments with network access to internal services or cloud metadata endpoints
In such contexts, redirects from whitelisted domains can quietly route requests to unintended internal or sensitive targets.
This vulnerability arises in applications that:
- Integrate PhpSpreadsheet to evaluate formulas, especially WEBSERVICE()
- Rely on Spreadsheet::setDomainWhiteList() to restrict outbound HTTP calls
- Call getCalculatedValue() (or equivalent) on user-supplied or semi-trusted XLSX files
- Run PhpSpreadsheet in environments with network access to internal services or cloud metadata endpoints
In such contexts, redirects from whitelisted domains can quietly route requests to unintended internal or sensitive targets.
Exploit preconditions
- Attack surface: PhpSpreadsheet formula evaluation, specifically WEBSERVICE() calls.
- Required access: Ability to upload, modify, or otherwise influence spreadsheets that the server will process; or control remote endpoints that a spreadsheet's WEBSERVICE() points to.
- Trigger point: Evaluation of a worksheet cell containing a WEBSERVICE() formula when getCalculatedValue() (or similar evaluation routines) is invoked.
- Why exploitation is possible: The WEBSERVICE implementation validates only the initial URL host against a whitelist, then uses file_get_contents with PHP's HTTP stream wrapper, which automatically follows 301/302 redirects. The final redirect target hostname and port are never re-validated, allowing traversal from a trusted domain to arbitrary internal or external URLs.
- Attack surface: PhpSpreadsheet formula evaluation, specifically WEBSERVICE() calls.
- Required access: Ability to upload, modify, or otherwise influence spreadsheets that the server will process; or control remote endpoints that a spreadsheet's WEBSERVICE() points to.
- Trigger point: Evaluation of a worksheet cell containing a WEBSERVICE() formula when getCalculatedValue() (or similar evaluation routines) is invoked.
- Why exploitation is possible: The WEBSERVICE implementation validates only the initial URL host against a whitelist, then uses file_get_contents with PHP's HTTP stream wrapper, which automatically follows 301/302 redirects. The final redirect target hostname and port are never re-validated, allowing traversal from a trusted domain to arbitrary internal or external URLs.
Why this happens
Conceptually, this maps to CWE-918: Server-Side Request Forgery (SSRF).
The security model assumes that validating the initial hostname against a whitelist is sufficient to constrain outbound HTTP calls. However, the underlying transport (PHP's HTTP stream wrapper) transparently follows HTTP redirects while the code neglects to re-check the final destination's host or port against the whitelist. This gap between policy enforcement and actual network behavior lets attackers design URLs or endpoints that respond with redirects from whitelisted domains to untrusted targets, leveraging the application as a network proxy for internal-only resources and metadata services.
Conceptually, this maps to CWE-918: Server-Side Request Forgery (SSRF).
The security model assumes that validating the initial hostname against a whitelist is sufficient to constrain outbound HTTP calls. However, the underlying transport (PHP's HTTP stream wrapper) transparently follows HTTP redirects while the code neglects to re-check the final destination's host or port against the whitelist. This gap between policy enforcement and actual network behavior lets attackers design URLs or endpoints that respond with redirects from whitelisted domains to untrusted targets, leveraging the application as a network proxy for internal-only resources and metadata services.
Potential impact
- May exfiltrate cloud instance metadata, including temporary credentials (e.g., AWS, GCP, Azure metadata services).
- Could access internal-only HTTP services (e.g., admin panels, microservices, debug endpoints).
- May be used for internal port scanning by probing arbitrary host:port combinations.
- Can leak internal configuration files or service responses, up to the WEBSERVICE cell size limit.
- Could facilitate lateral movement or privilege escalation when combined with other weaknesses.
- May exfiltrate cloud instance metadata, including temporary credentials (e.g., AWS, GCP, Azure metadata services).
- Could access internal-only HTTP services (e.g., admin panels, microservices, debug endpoints).
- May be used for internal port scanning by probing arbitrary host:port combinations.
- Can leak internal configuration files or service responses, up to the WEBSERVICE cell size limit.
- Could facilitate lateral movement or privilege escalation when combined with other weaknesses.
General mitigation guidance
Effective mitigation focuses on tightening outbound request handling and decoupling business logic from raw URL fetching:
- Enforce strict, centralized URL validation that is applied after all redirects or disable automatic redirect following for formula-driven requests.
- Restrict WEBSERVICE() usage in server-side contexts, or treat it as a privileged capability that is disabled for user-controlled spreadsheets.
- Constrain the execution environment's network access (e.g., disallow access to metadata IPs and internal ranges from the PhpSpreadsheet worker).
- Implement defense-in-depth controls such as egress filtering and application-layer proxies that enforce domain and port policies independently of library behavior.
- Adopt least-privilege IAM and network policies so that even if SSRF is possible, sensitive services and credentials remain inaccessible.
Effective mitigation focuses on tightening outbound request handling and decoupling business logic from raw URL fetching:
- Enforce strict, centralized URL validation that is applied after all redirects or disable automatic redirect following for formula-driven requests.
- Restrict WEBSERVICE() usage in server-side contexts, or treat it as a privileged capability that is disabled for user-controlled spreadsheets.
- Constrain the execution environment's network access (e.g., disallow access to metadata IPs and internal ranges from the PhpSpreadsheet worker).
- Implement defense-in-depth controls such as egress filtering and application-layer proxies that enforce domain and port policies independently of library behavior.
- Adopt least-privilege IAM and network policies so that even if SSRF is possible, sensitive services and credentials remain inaccessible.
How teams detect issues like this
Organizations can identify and manage this class of risk through:
- Static analysis or code search for uses of WEBSERVICE(), setDomainWhiteList(), and formula evaluation on user-supplied spreadsheets, especially where file_get_contents or similar HTTP helpers are involved.
- Code reviews that flag any trust placed in domain whitelists without considering redirect behavior or port constraints.
- Network monitoring and logging for unusual outbound HTTP patterns originating from spreadsheet-processing services, including calls to metadata IPs (169.254.169.254) and internal address ranges.
- Security policies that require SSRF-safe patterns for outbound HTTP, including explicit redirect controls and enforcement by outbound proxies or firewalls.
- Periodic penetration tests that attempt SSRF via spreadsheet uploads and formula evaluation in applications using PhpSpreadsheet.
Organizations can identify and manage this class of risk through:
- Static analysis or code search for uses of WEBSERVICE(), setDomainWhiteList(), and formula evaluation on user-supplied spreadsheets, especially where file_get_contents or similar HTTP helpers are involved.
- Code reviews that flag any trust placed in domain whitelists without considering redirect behavior or port constraints.
- Network monitoring and logging for unusual outbound HTTP patterns originating from spreadsheet-processing services, including calls to metadata IPs (169.254.169.254) and internal address ranges.
- Security policies that require SSRF-safe patterns for outbound HTTP, including explicit redirect controls and enforcement by outbound proxies or firewalls.
- Periodic penetration tests that attempt SSRF via spreadsheet uploads and formula evaluation in applications using PhpSpreadsheet.
