CVE-2026-6735

What it actually does

This is a reflected cross-site scripting flaw in the PHP-FPM status page. When the status endpoint is enabled and reachable, insufficient sanitization of user-controlled URL data can allow attacker-supplied content to be rendered as executable JavaScript in the browser of a user who views the crafted status-page URL. The vulnerability does not directly execute code on the PHP server, but it can execute script in the victim’s browser in the security context of the PHP-FPM status page origin, potentially enabling session theft, credential capture, forced actions, or access to sensitive status-page content visible to that user.

Why it matters to the business

Organizations that expose PHP-FPM status pages, especially to administrators or monitoring users, could have those users’ browsers compromised through a malicious link. This may lead to stolen administrative sessions, leakage of operational details, phishing inside a trusted application context, or pivoting to other management interfaces hosted on the same origin. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV, but the issue is remotely reachable where the status page is exposed and should be remediated as part of normal patch cycles, with higher urgency for internet-facing or broadly accessible status endpoints.

How an attack unfolds

An attacker first identifies a PHP-FPM status page that is enabled and reachable, either directly or through a web server location such as a status or monitoring path. The attacker then crafts a URL containing JavaScript payload data in parameters or URL components processed by the vulnerable PHP-FPM status page. Because affected PHP versions do not properly sanitize that user-controlled data, the payload can be reflected into the generated status page. The attacker must then cause a target user to open the crafted URL, such as by sending a link through email, chat, ticket comments, documentation, or another trusted workflow. If the user loads the URL in a vulnerable deployment, the browser executes the injected JavaScript in the context of the status page origin. The attacker can then attempt to read visible page content, steal cookies or tokens not protected by browser controls, perform actions available to the user on the same origin, or redirect the user to a credential-harvesting page.

How to fix it

Upgrade PHP to a fixed release for the affected branch: PHP 8.2.31 or later, PHP 8.3.31 or later, PHP 8.4.21 or later, or PHP 8.5.6 or later. If immediate patching is not possible, disable the PHP-FPM status page or restrict it to trusted administrative networks only. Require authentication for access to status endpoints, block public internet access, and avoid hosting administrative or monitoring status pages on the same origin as sensitive applications. Add web server rules to deny access to the configured PHP-FPM status path except from approved IP ranges. As defense in depth, deploy a restrictive Content Security Policy on status or administrative endpoints to reduce the impact of reflected script execution.

How to confirm the fix worked

Confirm the installed PHP runtime version is no longer in an affected range: 8.2.x must be 8.2.31 or later, 8.3.x must be 8.3.31 or later, 8.4.x must be 8.4.21 or later, and 8.5.x must be 8.5.6 or later. Review web server and PHP-FPM configuration to determine whether the PHP-FPM status page is enabled and what URI exposes it. From an untrusted network location, verify the status endpoint is not reachable unless explicitly intended. From an authorized test environment, request the status endpoint with benign encoded HTML or script-like characters and confirm they are safely escaped rather than rendered or executed. Also verify that web server access controls, authentication, and any Content Security Policy changes are active on the status endpoint.

Typical attack path

1. Discover or infer that a PHP-FPM status page is enabled and accessible through a web server route.
2. Craft a malicious status-page URL containing encoded JavaScript or HTML event-handler payloads.
3. Deliver the crafted URL to a user likely to have access to the status page, such as an administrator, developer, or monitoring operator.
4. The user opens the link and the vulnerable PHP-FPM status page reflects the attacker-controlled data without proper sanitization.
5. The victim’s browser executes the injected JavaScript in the context of the status page origin.
6. The attacker uses the script to steal accessible data, capture credentials, perform same-origin actions, or redirect the user to additional attacker-controlled content.

How to detect it

To determine whether exploitation may already have occurred, review HTTP access logs from web servers, reverse proxies, WAFs, load balancers, and API gateways that front PHP-FPM status endpoints. Focus on requests to configured PHP-FPM status URIs that include script tags, URL-encoded HTML, JavaScript schemes, SVG payloads, or HTML event-handler attributes. Investigate requests followed by administrative browser activity, redirects to unfamiliar domains, unusual referrers, or repeated probing of status paths. Review WAF alerts for reflected XSS attempts and browser-side security telemetry for script execution, blocked Content Security Policy events, or navigation to suspicious external domains after visiting a status page. If administrative sessions are used on the same origin, review authentication logs and application audit logs for anomalous actions after a user accessed a suspicious status-page URL.

• %3Cscript
• <script
• %3C%2Fscript%3E
• </script>
• javascript:
• %6A%61%76%61%73%63%72%69%70%74%3A
• onerror=
• onload=
• onclick=
• onmouseover=
• %3Cimg
• <img
• %3Csvg
• <svg
• alert(
• document.cookie
• fetch(
• XMLHttpRequest
• eval(
• atob(
• /status?
• /fpm-status?
• /php-fpm-status?

What your security team should do

• Inventory PHP deployments and identify systems running PHP 8.2.x, 8.3.x, 8.4.x, or 8.5.x with PHP-FPM enabled.
• Prioritize internet-facing systems and administrative or monitoring endpoints that expose the PHP-FPM status page.
• Upgrade affected PHP branches to 8.2.31+, 8.3.31+, 8.4.21+, or 8.5.6+ as applicable.
• Disable the PHP-FPM status page where it is not operationally required.
• Restrict required status endpoints to trusted networks and authenticated users only.
• Search historical web access logs for suspicious status-page requests containing encoded script tags, JavaScript URLs, or HTML event-handler payloads.
• Add SIEM detections for XSS payload patterns targeting PHP-FPM status routes or other monitoring endpoints.
• Educate administrators and operations staff not to open unsolicited monitoring or status-page links from untrusted sources.