Summary
Termix's homepage proxy endpoint can fetch attacker-selected URLs without restricting destinations, creating a server-side request forgery (SSRF) vulnerability. An authenticated low-privilege or self-registered user may use it to access internal services, cloud metadata, and sensitive credentials when the server can reach those destinations.
Affected context
The issue occurs in Termix deployments that expose the /homepage/proxy endpoint and allow authenticated users to provide a URL for server-side retrieval. Syntactic URL parsing alone does not prevent requests to loopback, RFC1918 private, link-local, or cloud metadata addresses, and the endpoint returns the complete upstream response.
Exploit preconditions
- Attack surface: The authenticated
/homepage/proxyweb endpoint - Required access: A valid low-privilege or self-registered Termix account, subject to deployment settings
- Trigger point: Server-side HTTP or HTTPS retrieval of the user-controlled
urlparameter - Why exploitation is possible: Destination validation checks URL syntax but does not enforce an allowlist or block internal and metadata address ranges
Why this happens
The vulnerability results from treating a user-supplied URL as a trusted server-side request destination. Although new URL can confirm that a value is syntactically valid, it does not establish that the destination is safe to contact. Passing the resulting URL directly to HTTP client functions without network-aware destination controls maps to CWE-918: Server-Side Request Forgery.
Potential impact
- An attacker could access internal administrative or service endpoints
- Sensitive internal JSON responses may be exfiltrated
- Cloud instance metadata and temporary credentials could be exposed
- The vulnerable server may be used to reach systems unavailable to the attacker directly
- Internal network reconnaissance or follow-on compromise could occur
General mitigation guidance
Mitigation typically focuses on making outbound proxying deny-by-default and reducing trust in user-controlled destinations.
Common defensive patterns include:
- Restricting proxy requests to an explicit, narrowly scoped destination allowlist
- Resolving hostnames and validating the resulting addresses against loopback, private, link-local, multicast, and metadata ranges
- Rechecking destinations after redirects and preventing unsafe protocol changes
- Applying outbound network policies that limit access from the application to internal services and metadata endpoints
- Returning only the minimum response data required by the feature
- Running the service with least-privilege network and cloud identity permissions
- Separating proxy functionality from sensitive network segments where possible
How teams detect issues like this
Organizations can identify SSRF risks through:
- Static analysis rules for HTTP client calls that consume request parameters or other untrusted URL values
- Code review checks for missing destination allowlists, redirect validation, and IP-range filtering
- Dynamic testing with controlled endpoints representing loopback, private, link-local, and metadata destinations
- Egress monitoring for unexpected connections from the application to internal addresses or cloud metadata services
- Policy enforcement requiring approved outbound destinations for server-side fetch functionality
Automated code review tools may help flag user-controlled URLs passed directly to network libraries.
