CVE-2026-85614 in OpenPanel
Summary
by MITRE • 09/04/2026
OpenPanel before 2.3.0 contains an unauthenticated server-side request forgery vulnerability in the GET /tools/site-checker endpoint that accepts a fully client-controlled URL parameter with no private IP filtering or DNS-rebinding protection. Attackers can make the OpenPanel server issue requests to internal services, localhost, and cloud metadata endpoints, reading internal HTTP response titles, headers, status codes, and SSL certificate information.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified in versions of OpenPanel prior to 2.3.0 represents a critical security flaw classified as an unauthenticated Server-Side Request Forgery (SSRF). This specific weakness resides within the GET /tools/site-checker endpoint, which is designed to perform external connectivity checks or site validation tasks. The core technical failure lies in the application's handling of user-supplied input; specifically, it accepts a URL parameter that is fully controlled by the client without implementing any form of server-side validation. This lack of sanitization allows an attacker to dictate exactly where the OpenPanel server directs its outbound network requests, bypassing standard security controls such as private IP address filtering and protections against DNS rebinding attacks.
From a technical perspective, this flaw enables remote attackers to force the vulnerable application server to initiate HTTP or HTTPS connections to arbitrary destinations. Because there is no restriction on internal networks, an attacker can target localhost services that are not exposed to the public internet but remain accessible via loopback interfaces. Furthermore, the absence of DNS-rebinding protection means that even if initial IP filtering appears effective, attackers can manipulate Domain Name System responses during the resolution process to redirect requests back into trusted local environments or cloud infrastructure metadata endpoints. This capability effectively turns the OpenPanel server into a proxy for internal network reconnaissance and data exfiltration.
The operational impact of this vulnerability is severe due to its unauthenticated nature. Any user with access to the web interface can exploit it without needing valid credentials, significantly lowering the barrier for entry. By probing internal services, attackers can read HTTP response titles, headers, status codes, and SSL certificate information from backend systems that should remain isolated. This data leakage can reveal sensitive architectural details about the underlying infrastructure, such as running software versions on internal servers, configuration settings exposed in headers, or authentication mechanisms employed by other services within the same network segment. Additionally, targeting cloud metadata endpoints allows attackers to potentially retrieve instance identity credentials and temporary security tokens, which could lead to full compromise of associated cloud resources if not properly scoped.
This vulnerability aligns with CWE-918, Server-Side Request Forgery (SSRF), specifically highlighting the failure to restrict outbound connections from a web application. It also maps directly to MITRE ATT&CK technique T1571, which covers Non-Standard Ports and protocols often used in SSRF attacks to bypass firewalls or access internal services that are not listening on standard ports like 80 or 443. The exploitation path demonstrates how a seemingly benign administrative tool can be weaponized for lateral movement within an organization's network perimeter.
To mitigate this risk, organizations running OpenPanel versions earlier than 2.3.0 must upgrade to the patched version immediately where possible. If upgrading is not feasible, administrators should implement strict input validation on the site-checker endpoint by whitelisting only allowed domains or IP ranges for outbound requests. It is critical to enforce a deny-by-default policy that blocks all private IP addresses (such as 127.0.0.1, 192.168.x.x, and 10.x.x.x) and link-local addresses from being resolved by the server-side request mechanism. Additionally, deploying network-level controls such as egress filtering at the firewall or proxy level can provide a secondary layer of defense by preventing the application server from initiating connections to unauthorized internal subnets or cloud metadata endpoints regardless of the application's configuration.