CVE-2026-71204: changedetection.io Auth Bypass Vulnerability

CVE-2026-71204 Overview

CVE-2026-71204 affects changedetection.io, an open-source web page change monitoring application. The vulnerability resides in the /settings save handler, which builds an update dictionary from form.data['application'] and blind-merges it into stored application settings using .update(). WTForms represents an unchecked checkbox as False rather than unchanged, and only the password field is special-cased to avoid this problem. A POST to /settings that omits the api_access_token_enabled field silently disables API key enforcement across the entire REST API. This exposes the full watch list, history, and configuration to unauthenticated requests. The issue is classified under [CWE-284: Improper Access Control].

Critical Impact
An authenticated user submitting a minimal /settings POST can disable API authentication, exposing all monitored data and configuration to unauthenticated network requests.

Affected Products

changedetection.io (self-hosted web change monitoring application)

Discovery Timeline

2026-08-05 - CVE CVE-2026-71204 published to NVD
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-71204

Vulnerability Analysis

The vulnerability is a broken access control flaw rooted in unsafe form-to-model merging. The /settings handler treats every field present in form.data['application'] as an intentional user-submitted value. WTForms renders unchecked boolean checkboxes as literal False during data binding, which is indistinguishable from an explicit user choice to disable a feature. The handler then passes this dictionary to .update() against the persisted application settings.

This pattern breaks when clients submit partial forms. The password field is guarded with a special case, but api_access_token_enabled is not. Any authenticated user with settings access can therefore turn off API key enforcement, converting the REST API into an unauthenticated interface exposing watch lists, monitoring history, and configuration.

Root Cause

The root cause is a mass assignment pattern combined with WTForms boolean semantics. The application does not distinguish between fields omitted from a request and fields explicitly set to False. Only the password field has been given defensive handling, leaving other security-relevant booleans, including api_access_token_enabled, vulnerable to silent downgrade.

Attack Vector

An attacker with authenticated access to the settings endpoint sends a minimal scripted POST to /settings that omits api_access_token_enabled. The server persists the missing checkbox as False. Subsequent REST API calls from anywhere on the network succeed without an API token, exposing all stored watches and configuration data. See the changedetection.io repository for source-level details.

// No verified exploit code is available. The vulnerability manifests when the
// /settings POST handler merges WTForms output into stored settings without
// distinguishing omitted checkbox fields from an explicit False value.

Detection Methods for CVE-2026-71204

Indicators of Compromise

Unexpected changes to the api_access_token_enabled value in application settings, particularly transitions from True to False.
REST API requests to /api/v1/* endpoints succeeding without an x-api-key header.
POST requests to /settings with unusually small payloads or missing checkbox fields.

Detection Strategies

Audit application settings on a schedule and alert on any change to API authentication flags.
Inspect web server or reverse proxy access logs for unauthenticated calls to REST endpoints that historically required an API key.
Compare rendered /settings form snapshots against submitted POST bodies to identify fields dropped by clients.

Monitoring Recommendations

Forward changedetection.io access logs to a centralized logging platform and alert on API responses that succeed without token headers.
Track configuration drift on the container or host running changedetection.io using file integrity monitoring on the settings store.
Alert on new external network sources issuing successful requests to the REST API.

How to Mitigate CVE-2026-71204

Immediate Actions Required

Restrict network exposure of the changedetection.io instance to trusted networks or place it behind an authenticating reverse proxy.
Verify that api_access_token_enabled is set to True and rotate the existing API access token.
Limit which users can reach /settings until an upstream fix is applied.

Patch Information

No fixed version is listed in the NVD entry at time of publication. Monitor the changedetection.io GitHub repository for releases that special-case api_access_token_enabled in the settings handler or replace the blind .update() with an explicit field allowlist.

Workarounds

Deploy an authenticating reverse proxy (for example, nginx with auth_basic or an OAuth2 proxy) in front of changedetection.io so REST endpoints require an additional authentication layer.
Bind the changedetection.io listener to 127.0.0.1 and access it only through a controlled tunnel until a patch is released.
Periodically re-assert api_access_token_enabled = True through automation to detect and revert silent downgrades.

bash

# Example nginx location block to require basic auth on the REST API
location /api/ {
    auth_basic "changedetection API";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:5000;
}