Description

Ground Station prior to 0.6.0 contains an unauthenticated blind server-side request forgery vulnerability in the orbital-source configuration path that allows any unauthenticated Socket.IO client to cause the ground-station process to issue outbound HTTP requests to attacker-chosen destinations. Attackers can connect to the Socket.IO server on port 7000 without credentials due to disabled authentication enforcement and a wildcard CORS policy, then submit a data_submission event with submit-orbital-sources action to persist an attacker-supplied URL in the database, then trigger an orbital sync via the equally unauthenticated background_task:start event. The URL is stored with no scheme allowlist, no host validation, and no rejection of loopback, RFC1918, or link-local (cloud instance metadata at 169.254.169.254) addresses, and is passed directly to requests.get in _fetch_http_3le and _fetch_http_omm in backend/tlesync/source_adapters.py. HTTP status codes and error messages from the outbound request are emitted in the orbital_sync_state Socket.IO event to all connected clients, providing a serviceable oracle for interpreting internal-service and cloud-metadata responses even though the raw response body is not directly leaked. Because the malicious source persists in the database across restarts and re-fires every 24 hours on the scheduled sync cycle, the primitive gives durable long-term SSRF without the attacker needing to remain connected.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.6",
  "pubDate": "2026-08-06T22:17:42.120Z",
  "pubdate": "2026-08-06T22:17:42.120Z",
  "executiveSummary": "Ground Station prior to 0.6.0 suffers from an unauthenticated blind Server-Side Request Forgery (SSRF) vulnerability located within the orbital-source configuration path.\nThe vulnerability allows any unauthenticated Socket.IO client to force the ground-station process to issue arbitrary outbound HTTP requests to attacker-designated destinations.\nThe flaw stems from missing authentication enforcement, a wildcard CORS policy, and a lack of input validation on the URL parameter, which accepts internal destinations such as loopback, RFC1918, and cloud instance metadata endpoints (169.254.169.254).\nAttackers can leverage the Socket.IO service running on port 7000 to persist a malicious URL in the database and trigger background synchronization tasks.\nAlthough raw response bodies are not directly leaked, the application emits HTTP status codes and error messages via the orbital_sync_state Socket.IO event, serving as an oracle for probing internal networks and cloud metadata services.\nThe malicious configuration persists across application restarts and automatically re-fires every 24 hours, resulting in durable, long-term SSRF exposure without requiring sustained attacker connectivity.",
  "technicalDetails": "The vulnerability resides in Ground Station prior to 0.6.0, specifically impacting the orbital-source configuration path and background synchronization handlers.\nThe root cause encompasses multiple security deficiencies: completely disabled authentication enforcement on the Socket.IO server running on port 7000, a permissive wildcard CORS policy, and the total absence of URL scheme allowlists, host validation, and IP address filtering in backend/tlesync/source_adapters.py.\nThe affected components include backend/tlesync/source_adapters.py, where user-supplied URLs are passed directly into the requests.get function via _fetch_http_3le and _fetch_http_omm.\nThe attack flow proceeds in a structured sequence: First, an unauthenticated attacker connects to the exposed Socket.IO server on port 7000 over the network. Second, the attacker submits a data_submission event utilizing the submit-orbital-sources action containing an arbitrary, attacker-supplied URL. Third, the application stores this URL directly in the database without any validation or sanitization. Fourth, the attacker triggers an orbital synchronization process by emitting the unauthenticated background_task:start event.\nUpon execution of the synchronization task, the application invokes requests.get with the malicious URL, allowing targeting of internal services, RFC1918 private subnets, loopback interfaces, and cloud instance metadata endpoints such as 169.254.169.254.\nWhile the raw HTTP response body is withheld, exploitation yields significant information leakage through the orbital_sync_state Socket.IO event, which broadcasts HTTP status codes and error messages to all connected clients. This functions as an effective side-channel oracle for interpreting internal service responses.\nBecause the payload is persisted within the database, the SSRF primitive survives application restarts and automatically re-executes every 24 hours during the scheduled synchronization cycle, eliminating the need for persistent attacker connection."
}