Summary
A server-side request forgery vulnerability in changedetection.io allows a remote attacker to influence the URL used by the Preview Endpoint.
When the endpoint processes attacker-controlled URLs without adequately restricting destinations, the server may send requests to internal or otherwise unintended services.
Affected context
The vulnerability occurs in the Preview Endpoint implementation, specifically the add_watch_ui_snapshot function in changedetectionio/blueprint/add_watch_ui/__init__.py. It affects deployments where a remotely supplied url value is used to initiate server-side requests without sufficient destination validation or network egress restrictions.
Exploit preconditions
- Attack surface: The remotely accessible Preview Endpoint
- Required access: Ability to reach the endpoint and provide or influence the
urlparameter - Trigger point: Processing a preview request through
add_watch_ui_snapshot - Why exploitation is possible: The server may trust the supplied destination and make a request from its own network context
Why this happens
The underlying issue is insufficient validation and authorization of a user-controlled URL before the application performs a server-side request.
This maps to CWE-918: Server-Side Request Forgery, where an application retrieves attacker-influenced resources from a privileged server-side network position. Insecure destination handling can allow requests to internal services, local interfaces, cloud metadata endpoints, or other restricted locations.
Potential impact
- An attacker may access services that are not directly reachable from the internet
- Internal application or infrastructure data could be disclosed
- Cloud instance metadata or service credentials may be exposed
- Internal endpoints could receive unintended requests
- The vulnerable server's network position may be used for reconnaissance or lateral movement
General mitigation guidance
Mitigation generally focuses on treating all externally supplied URLs as untrusted and limiting where the server can connect.
Common defensive patterns include:
- Allowing requests only to explicitly approved schemes, hosts, ports, and destinations
- Resolving hostnames and validating resulting IP addresses before connecting
- Blocking loopback, link-local, private, reserved, and other restricted address ranges
- Rechecking destinations after redirects and limiting redirect behavior
- Applying outbound network policies and egress controls at the host or deployment layer
- Running the application with least-privilege network and service permissions
- Avoiding exposure of sensitive response bodies or detailed connection errors through preview features
How teams detect issues like this
Organizations can detect SSRF risks through:
- Static analysis for server-side HTTP clients that consume request parameters without destination validation
- Code review checks for URL fetches, redirect handling, DNS resolution, and IP-range filtering
- Runtime monitoring of outbound requests from web application processes
- Network policies that alert on connections to private, loopback, link-local, or metadata-service addresses
- Policy enforcement requiring approved destination lists for server-side fetch functionality
- Automated security review tools that identify user-controlled URL flows and external request sinks
