CVE-2026-108736 in Speedtest Tracker
Summary
by MITRE • 10/11/2026
Speedtest Tracker through 1.15.0 contains an IP allowlist bypass vulnerability that allows unauthenticated remote attackers to evade ALLOWED_IPS and Prometheus allowlists by spoofing X-Forwarded-For headers. Because bootstrap/app.php trusts every peer as a proxy, attackers can supply an allowlisted address to read /prometheus metrics and reach protected web and API endpoints.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in Speedtest Tracker versions up to 1.15.0 represents a critical failure in access control mechanisms related to IP-based authentication and authorization. This flaw stems from the application's reliance on trusting every peer as a trusted proxy, which leads to an improper validation of client identity based solely on spoofed HTTP headers rather than actual network connection data. Specifically, the bootstrap/app.php file is configured to accept X-Forwarded-For header values without sufficient verification against known reverse proxies or load balancers that legitimately set these headers. This architectural decision creates a significant security gap where unauthenticated remote attackers can manipulate their perceived source IP address by injecting arbitrary values into the X-Forwarded-For HTTP request header. By doing so, they effectively bypass the application's ALLOWED_IPS configuration and any associated Prometheus metrics allowlists, gaining unauthorized access to resources that should be restricted to specific internal or trusted networks.
From a technical perspective, this vulnerability is classified under CWE-287 Improper Authentication because the system fails to correctly verify the identity of an actor claiming to have administrative privileges or authorized access. The attacker exploits the trust relationship between the web server and its proxies by spoofing the source IP address in the X-Forwarded-For header. Since many modern applications rely on this header to determine the true client IP when sitting behind a reverse proxy, misconfigurations where all peers are trusted allow attackers to masquerade as an allowed internal host. This bypass mechanism allows the attacker to access sensitive endpoints such as Prometheus metrics and protected web or API interfaces without providing valid credentials. The impact is severe because it exposes operational data that may include performance statistics, system health indicators, and potentially other sensitive information contained within the application's state or configuration files accessible through these unprotected routes.
The operational impact of this vulnerability extends beyond simple unauthorized access to internal tools. By reaching protected web and API endpoints, an attacker could potentially extract valuable intelligence about the network infrastructure, including server performance metrics from Prometheus which might reveal details about backend services, database load, or microservice architecture. Furthermore, if these unprotected endpoints allow for any form of input processing or state modification, the risk escalates to include potential remote code execution or data manipulation. The ability to bypass IP-based restrictions also undermines security policies designed to limit exposure to untrusted networks, effectively rendering network segmentation controls ineffective against this specific attack vector. This type of vulnerability is often associated with ATT&CK technique T1078 Valid Accounts if the attacker uses stolen credentials in conjunction with the IP spoofing, or more directly with techniques involving header manipulation and access control bypasses that fall under initial access or privilege escalation phases depending on the subsequent actions taken by the adversary.
To mitigate this vulnerability, it is essential to reconfigure the application's proxy trust settings so that only known, legitimate reverse proxies are trusted to set X-Forwarded-For headers. This typically involves updating configuration files to explicitly list the IP addresses of authorized load balancers or CDN services rather than trusting all incoming connections as proxies. Additionally, implementing strict input validation and ensuring that critical endpoints require multi-factor authentication or token-based authorization independent of IP address checks can provide defense in depth. Organizations should also consider deploying Web Application Firewalls configured to detect and block suspicious X-Forwarded-For header patterns indicative of spoofing attempts. Regular security audits and penetration testing focused on access control mechanisms are recommended to identify similar misconfigurations across the infrastructure, ensuring that reliance on single-factor IP-based restrictions is minimized in favor of more robust authentication protocols aligned with industry best practices for secure application design.