CVE-2026-27696: 
Python vulnerability analysis and mitigation

CVE-2026-27696 is a Server-Side Request Forgery (SSRF) vulnerability in changedetection.io, a free open-source web page change detection tool. The flaw exists in all versions prior to 0.54.1 (affected versions listed as <= 0.53.1 in the security advisory). It was discovered and disclosed by researcher route2shell, with the GitHub advisory published on February 23, 2026, and the NVD entry published on February 25, 2026. The vulnerability carries a CVSS v3.1 base score of 8.6 (High) (GitHub Advisory, Security Advisory).

The root cause is classified as CWE-918 (Server-Side Request Forgery). The URL validation function is_safe_valid_url() in changedetectionio/validate_url.py only checks the URL protocol (http/https/ftp) and format using the validators library, but performs no DNS resolution or IP address validation against private (RFC 1918), loopback (127.0.0.0/8), or link-local (169.254.0.0/16) address ranges. The HTTP fetcher in changedetectionio/content_fetchers/requests.py then makes the request without any additional IP validation, and the response is stored and exposed via the web UI. This validation gap affects all URL entry points: the Web UI (store/__init__.py:718), REST API (api/watch.py:163, 428), and Import API (api/import.py:188). Additionally, the original code did not validate redirect targets, enabling open-redirect SSRF bypass attacks. A detailed PoC is included in the official security advisory (Security Advisory, Patch Commit).

Successful exploitation allows an attacker to exfiltrate data from internal network services, including cloud instance metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/iam/security-credentials/ on AWS), internal APIs, databases, and admin interfaces not exposed to the internet. Because fetched content is stored and viewable through the web UI, this is a non-blind SSRF — full response data is accessible to the attacker. Watches are fetched periodically, creating a persistent SSRF that continuously accesses internal resources. Since no password is set by default, any user with network access to the instance can exploit this without authentication, making cloud-hosted deployments particularly at risk of IAM credential theft and lateral movement (GitHub Advisory).

A proof-of-concept exploit is publicly available in the official GitHub security advisory, demonstrating both web UI and REST API exploitation paths (Security Advisory). There is no confirmed evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.022% (0.000320 per Feedly), placing it in the 6th percentile for exploitation likelihood. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No specific threat actor attribution has been reported (GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible changedetection.io instances (default port 5000) using tools like Shodan or Censys. Confirm the version is prior to 0.54.1 and check whether authentication is enabled (default is no password).
2. Access the web UI or API: Navigate to http://<target>:5000/ in a browser (no credentials required by default), or obtain the API key from the Settings page.
3. Add a watch for an internal URL: In the URL field, enter an internal network address such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS metadata), http://10.0.0.1/, or http://127.0.0.1/. Click "Watch" to submit. Alternatively, use the REST API: curl -s -X POST "http://<target>:5000/api/v1/watch" -H "x-api-key: <API_KEY>" -H "Content-Type: application/json" -d '{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'
4. Wait for the fetch: The application automatically fetches the watch URL server-side on its configured schedule (typically within seconds to minutes).
5. Retrieve exfiltrated data: Click the watch entry and select "Preview" in the web UI, or query the API: curl -s "http://<target>:5000/api/v1/watch/<WATCH_UUID>/history/<LATEST_TS>" -H "x-api-key: <API_KEY>". The full response from the internal service — including IAM credentials or other sensitive data — is displayed.
6. Exploit open-redirect bypass (if needed): If partial mitigations are in place, use a public host that redirects to a private IP to bypass add-time URL validation, as the original code did not validate redirect destinations (Security Advisory).

• Network: Outbound HTTP requests from the changedetection.io server to 169.254.169.254, RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), or 127.0.0.1; unexpected connections to internal services on non-standard ports.
• Logs: Application logs showing watches created for internal/private IP URLs; access logs recording requests to /api/v1/watch with internal URL payloads; log entries containing 169.254.169.254 or private IP ranges in watch URL fields.
• File System: Datastore files (e.g., /datastore/url-watches.json) containing watch entries with internal network URLs; stored snapshot files containing cloud metadata or internal API responses (e.g., JSON blobs with AccessKeyId, SecretAccessKey, or Token fields).
• Application Behavior: New watch entries appearing in the UI targeting private IP ranges; periodic fetch activity directed at internal services; watch history snapshots containing credential-like data or internal service responses (Security Advisory).

Upgrade changedetection.io to version 0.54.1 or later, which adds IP address validation to is_safe_valid_url() and performs a fresh DNS check at fetch time to prevent DNS rebinding attacks. The patch also validates redirect destinations to block open-redirect SSRF bypass. For deployments that legitimately need to monitor internal services, the environment variable ALLOW_IANA_RESTRICTED_ADDRESSES=true can be set to explicitly permit private IP access. As interim mitigations for unpatched instances: enable authentication on the web UI, restrict network access to the changedetection.io instance, and implement network segmentation to isolate it from sensitive internal services and cloud metadata endpoints (Patch Commit, GitHub Advisory).

The vulnerability received coverage from The Hacker Wire, which published a dedicated technical write-up (The Hacker Wire). Social media discussion was observed on Bluesky and Mastodon shortly after disclosure. The vulnerability was detected by Qualys scanners and indexed by multiple vulnerability databases including CIRCL, VulnDB, and INCIBE-CERT. Community reaction highlighted the severity of the default no-authentication configuration combined with the non-blind nature of the SSRF as particularly concerning for cloud-hosted deployments.