CVE-2025-56563: Server-Side Request Forgery in Zenith Satellite Tracker

Overview

CVE-2025-56563 is a critical, unauthenticated Server-Side Request Forgery (SSRF) vulnerability in Zenith Satellite Tracker 1.0, a web-based satellite tracking application used by amateur radio operators and satellite enthusiasts. The flaw lives in sat_proxy.php (reported as api/sat_proxy.php), which accepts an attacker-controlled address URL parameter and hands it directly to curl_setopt(CURLOPT_URL) with no validation of the host or scheme.

Because the endpoint requires no authentication and performs no allow-listing, any remote attacker who can reach the application can force the server to issue arbitrary outbound HTTP/HTTPS requests — including to loopback addresses, internal-network services, and cloud metadata endpoints. NVD assigned this a CVSS v3.1 base score of 9.8 (Critical). The vulnerability was published September 16, 2026.

Technical Details

The vulnerability is classified under CWE-918 (Server-Side Request Forgery). The affected version is Zenith Satellite Tracker 1.0; no other versions have been identified in public reporting at the time of writing.

How It Works

sat_proxy.php appears to exist as a convenience proxy — likely intended to let the browser-side tracker UI fetch satellite telemetry or tracking data from a third-party API without running into CORS restrictions. The server-side implementation takes the client-supplied address parameter and passes it straight into cURL as the request target, roughly equivalent to:

$url = $_GET['address'];
curl_setopt($ch, CURLOPT_URL, $url);
$response = curl_exec($ch);
echo $response;

Because there is no validation of scheme, host, or destination IP, an attacker can substitute any value they like for address and the server will fetch it on their behalf, then reflect the response back — turning the application into an open proxy. A representative proof-of-concept request looks like this:

GET /api/sat_proxy.php?address=127.0.0.1:80/some-internal-path HTTP/1.1
Host: target-host

Swapping the address value lets an attacker:

• Reach services bound to localhost or 127.0.0.1 that are not otherwise exposed to the network
• Target RFC 1918 private-network ranges reachable from the server's network position
• Query cloud instance-metadata services (for example 169.254.169.254 on AWS/Azure/GCP-style deployments) to attempt to retrieve temporary credentials or instance identity data
• Potentially use non-HTTP schemes supported by the underlying cURL build if the scheme itself is not restricted, widening the attack surface beyond simple HTTP GETs

Since the request is proxied and the response is returned to the client, this is a "full response" SSRF — the attacker does not need a blind/out-of-band channel to observe the result, which makes exploitation and data exfiltration considerably easier than blind-SSRF variants.

Impact Assessment

Anyone running a public-facing or otherwise reachable instance of Zenith Satellite Tracker 1.0 is at risk. Because the endpoint is unauthenticated, exposure is not limited to registered users — any network path to the application is sufficient.

Realistic attack chains include:

• Cloud credential theft: if the host runs on AWS, Azure, or GCP without IMDSv2-style protections (or an older metadata service still reachable over plain HTTP), an attacker can query the instance metadata endpoint through the proxy and attempt to retrieve IAM/role credentials, enabling further compromise of cloud resources beyond the vulnerable host itself.
• Internal network reconnaissance and pivoting: the server can be abused as a scanning proxy to enumerate internal hosts, ports, and services that are not directly reachable from the internet, then to interact with any internal admin panels, databases, or management interfaces that trust requests originating from the application server's IP.
• Bypassing network segmentation: firewalls and network ACLs that trust the application server (because it sits inside a "trusted" segment) provide no protection once that server can be coerced into making arbitrary outbound requests on the attacker's behalf.
• Abuse as an open proxy: because responses are reflected back to the caller, the endpoint can also be used to relay or launder outbound requests through the victim's infrastructure.

Given the CVSS 9.8 rating, unauthenticated network access, and full-response nature of the SSRF, this should be treated as a high-priority finding for any internet-reachable or shared-network deployment of the affected software.

Mitigation

No confirmed, publicly documented patched release for this issue was identified at the time of writing. The GitHub security advisory referenced by NVD indicates remediation work was still in progress and does not cite a specific fixed version. Until an official fix is confirmed, apply the following mitigations:

Immediate actions

• If sat_proxy.php is not actively required, disable or remove it, or block external access to it at the web server/reverse-proxy layer.
• Place the application behind a WAF or reverse proxy rule that rejects requests to sat_proxy.php where the address parameter resolves to loopback (127.0.0.0/8, ::1), link-local/metadata (169.254.0.0/16), or RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
• Restrict outbound egress from the host running Zenith Satellite Tracker so it can only reach the specific third-party satellite-tracking APIs it legitimately needs — deny-by-default egress filtering neutralizes most SSRF impact even if the code-level flaw remains unpatched.
• If hosted in a cloud environment, enforce IMDSv2 (or the equivalent session-bound metadata token mechanism) and/or block metadata-service access from the application process entirely if it has no legitimate need for it.

Defense-in-depth, once a patch is available or as a longer-term fix

• Replace ad hoc validation with a strict allow-list of permitted destination hosts/domains for the proxy feature, rather than a deny-list of "bad" addresses.
• Restrict the accepted URL scheme to https (and http only if genuinely required) — reject anything else outright.
• Resolve the destination hostname server-side and reject requests where the resolved IP falls in a private, loopback, link-local, or reserved range, to defend against DNS-rebinding bypasses of hostname-based allow-lists.
• Disable automatic redirect-following in cURL (CURLOPT_FOLLOWLOCATION), or re-validate the redirect target against the same allow-list before following it.
• Consider requiring authentication for the proxy endpoint if it does not strictly need to be public.

Detection opportunities

• Review web server access logs for requests to sat_proxy.php/api/sat_proxy.php where the address parameter contains loopback, private-range, or metadata-service IP addresses, or unexpected URL schemes.
• Monitor egress/firewall logs on the hosting server for outbound connections to 169.254.169.254 or internal-only IP ranges originating from the web application process.
• Alert on unusually high volumes of outbound requests from the application host, which may indicate the endpoint is being used for scanning or as an open proxy.

References

• NVD — CVE-2025-56563
• GitHub Security Advisory — RIFTI-Offensive-Security/security-advisories: CVE-2025-56563
• Zenith Satellite Tracker project (magicbug/Zenith) — GitHub