Pecee Simple Router EUVD-2026-90440

Exploitation requires that the target application actively uses simple-php-router's IpRestrictAccess middleware to whitelist or blacklist clients by IP on one or more routes - this feature IS the attack surface. The bypass succeeds because the middleware derives the client IP from attacker-controllable HTTP headers (X-Forwarded-For, CF-Connecting-IP, Client-IP) rather than the trusted socket/remote address. The primary limiting factor is deployment: applications that do not employ IP-based route restriction are unaffected, and deployments fronted by a correctly configured reverse proxy or CDN that strips or overwrites these inbound headers before they reach the app materially reduce exploitability. No authentication, special privileges, or user interaction is needed when the vulnerable middleware is in use.

This is a moderate-risk access-control flaw whose real-world severity depends entirely on deployment. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) correctly describes a remote, unauthenticated, low-complexity attack with no user interaction, but caps impact at VC:L/VI:L/VA:N - a partial loss, reflecting that the bug only defeats an IP allow/deny gate rather than directly exposing data or executing code. The assigned 6.9 (MEDIUM) is reasonable; my independent CVSS 3.1 assessment lands at ~6.4, consistent with the vendor. No EPSS score was provided, there is no CISA KEV listing, and no proof-of-concept is explicitly confirmed in the input (though the referenced GitHub issue #727 and VulnCheck advisory may contain exploitation detail). This is a genuine, easily triggered bug - spoofing a forwarding header is trivial - but it is only a priority for applications that actually rely on IpRestrictAccess as a security boundary. For deployments that do not use IP-based route restriction, the practical risk is near zero. No conflicting signals in the CVSS vector itself; the network vector matches the HTTP-header-spoofing description.

An application uses simple-php-router's IpRestrictAccess middleware to limit an admin or internal route to a whitelisted office IP. A remote attacker sends an HTTP request to that route with a forged X-Forwarded-For (or CF-Connecting-IP / Client-IP) header set to the whitelisted address, and the middleware trusts the attacker-controlled header instead of the real socket IP, granting access. No authentication or user interaction is required; no public exploit is confirmed in the provided data, though the technique is trivial to reproduce.