PbootCMS CVE-2025-15154

The get_user_ip() function in core/function/handle.php reads the client-supplied X-Forwarded-For HTTP header and trusts it as the source IP without validating that it came from a trusted upstream proxy. Exploitation requires no authentication, no user interaction, and no non-default configuration - any remote client can set the header. The practical impact is LIMITED by how a deployment consumes the returned IP: it is only security-relevant where PbootCMS (or surrounding logic) uses that IP for access control, rate limiting, geolocation, or audit logging; where the IP is merely displayed or unused, the effect is negligible. There is no RCE, no data read, and no service disruption.

This is a genuinely low-to-moderate risk issue that should not be over-prioritized despite the network attack vector. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) confirms remote, unauthenticated, low-complexity exploitation, but the impact metrics are the decisive signal: VC:N/VI:L/VA:N means only a limited integrity effect and no confidentiality or availability loss - consistent with CWE-348 (Use of Less Trusted Source), i.e. the attacker can spoof the client IP that PbootCMS derives from the X-Forwarded-For header. EPSS is low at 0.25% (15th percentile), the CVE is NOT on CISA KEV, and no active exploitation is reported; the only elevated signal is that public exploit code exists (E:P in the vector and an 'exploit' reference), so exploitation is possible but there is no evidence of real-world weaponization. The signals are internally consistent - no network-vs-local contradiction - so the correct read is a credible but low-severity IP-spoofing/log-injection weakness, not an emergency. Its real-world danger is entirely dependent on whether a given deployment uses the returned IP for a security decision (see exploitation_conditions); absent that, impact is cosmetic.

An attacker sends an HTTP request to a PbootCMS site with a forged X-Forwarded-For header, causing get_user_ip() to return an attacker-controlled IP address. Because public exploit code is available, this can be used to spoof the logged/trusted source IP to evade IP-based restrictions, poison access logs, or bypass naive IP allow/deny or rate-limiting logic. No authentication or user interaction is required.