CVE-2024-32651

What it actually does

This vulnerability is an unauthenticated server-side template injection in changedetection.io’s Jinja2 template handling. An attacker can submit crafted template syntax through an exposed application workflow and cause the server to evaluate attacker-controlled Jinja2 expressions. Because the template context can be abused to reach Python internals and operating system execution primitives, successful exploitation results in remote command execution as the user running the changedetection.io process. The flaw is network exploitable, requires no authentication when the service is publicly reachable without a login layer, requires no user interaction, and can lead to full compromise of the host or container, including data theft, persistence, lateral movement, and service disruption.

Why it matters to the business

A vulnerable changedetection.io instance can be turned from a monitoring tool into an attacker-controlled execution point. Business consequences include loss of monitored-site data, theft of notification tokens and credentials, compromise of connected services, unauthorized network scanning from trusted infrastructure, malware or cryptominer deployment, and outages caused by destructive commands or resource exhaustion. The CVSS score is critical, public weaponized exploitation is reported, and the EPSS probability is very high, so internet-exposed deployments should be treated as urgent even though this issue is not currently listed in CISA KEV.

How an attack unfolds

An attacker first identifies a reachable changedetection.io service, commonly by scanning for exposed web interfaces or fingerprinting application responses. If the instance does not enforce authentication or is otherwise reachable by the attacker, they interact with a feature that stores or renders user-controlled template content. The attacker submits Jinja2 template syntax designed to escape the intended rendering context and access Python objects capable of invoking operating system commands. After confirming code execution with a benign command, the attacker typically runs discovery commands, retrieves environment variables and application configuration, and attempts to obtain secrets such as notification service credentials, browser automation tokens, API keys, or mounted cloud credentials. In more advanced cases, the attacker downloads tooling, opens a reverse shell, establishes persistence through cron jobs or startup scripts, pivots to other reachable internal services, or uses the host for proxying, scanning, spam, cryptomining, or ransomware preparation.

How to fix it

Upgrade changedetection.io to a version containing the fix, or build from a commit at or after ee5294740afe26cecb432a9dbceffa0ae7dc426d. Remove duplicate or stale container images and redeploy from a verified fixed image or source revision. If immediate upgrade is not possible, place the service behind strong authentication, restrict access by VPN or IP allowlist, block public internet exposure, and disable or tightly control any feature that renders user-controlled templates. Run the service with least privilege, preferably in a hardened container with a read-only filesystem where possible, no Docker socket mount, no host-sensitive volume mounts, dropped Linux capabilities, constrained seccomp/AppArmor profiles, and limited outbound network access. Rotate secrets that may have been available to the changedetection.io process, including notification webhooks, API keys, browser automation credentials, cloud credentials, and any credentials stored in the application configuration or environment.

How to confirm the fix worked

Confirm the deployed application source or container image includes commit ee5294740afe26cecb432a9dbceffa0ae7dc426d or a later fixed release. Verify that all running containers, pods, services, and scheduled redeployments use the fixed build rather than an older cached image. From an untrusted network location, confirm the changedetection.io interface is not publicly reachable or requires authentication before any watch creation, edit, notification, or template-rendering workflow is accessible. In a controlled non-production environment, test a harmless template expression in affected fields and verify it is not evaluated as server-side code. Review dependency manifests, image digests, and runtime banners where available, then restart the service and confirm no old worker processes remain. Validate compensating controls by checking reverse proxy rules, identity provider enforcement, firewall policy, and outbound egress restrictions.

Typical attack path

1. Scan the internet or internal address space for exposed changedetection.io web interfaces.
2. Confirm the service is reachable without enforced authentication or obtain access through weak credentials or another exposure path.
3. Submit a crafted Jinja2 template expression into an application field that is later rendered server-side.
4. Use the template injection to reach Python execution primitives and run an operating system command under the changedetection.io process account.
5. Validate execution with low-noise commands such as identity, hostname, or environment discovery commands.
6. Collect application configuration, datastore contents, environment variables, notification credentials, and other secrets accessible to the process.
7. Establish interactive access, commonly through a reverse shell or downloaded remote access tooling.
8. Perform post-exploitation actions such as persistence, lateral movement, data exfiltration, service disruption, or deployment of additional malware.

How to detect it

Investigate reverse proxy, web server, WAF, application, container, and EDR logs for suspicious requests to changedetection.io containing Jinja2 template syntax, Python object traversal strings, command-execution keywords, or URL-encoded equivalents. Focus on the period before patching and any time the service was reachable without authentication. Review application audit artifacts for newly created or modified watches, notification templates, tags, or settings containing template delimiters or Python introspection strings. On the host or container, look for child processes spawned by the changedetection.io Python process, Flask, Gunicorn, uWSGI, or related runtime processes; suspicious children include sh, bash, dash, curl, wget, nc, ncat, python, perl, php, openssl, socat, busybox, and chmod. Examine outbound network telemetry for unexpected connections from the changedetection.io host to unfamiliar IP addresses, especially high ports or connections shortly after suspicious HTTP requests. Review filesystem artifacts such as scripts or binaries written to /tmp, /var/tmp, /dev/shm, application writable directories, cron locations, SSH authorized_keys, shell histories, and container overlay filesystems. Check for credential access by reviewing environment dumps, configuration reads, datastore access, and use of notification tokens or webhooks from unusual sources. If running in containers or Kubernetes, inspect container logs, exec events, image changes, pod restarts, anomalous egress, service account token access, and attempts to reach metadata services.

• {{
• }}
• {%
• %}
• __class__
• __mro__
• __subclasses__
• __globals__
• __builtins__
• os.popen
• subprocess.Popen
• config.__class__
• request.application
• cycler.__init__.__globals__
• joiner.__init__.__globals__
• namespace.__init__.__globals__
• /bin/sh -c
• /bin/bash -c
• bash -i
• sh -i
• python -c
• python3 -c
• perl -e
• php -r
• ruby -e
• nc -e
• ncat -e
• mkfifo /tmp
• /dev/tcp/
• curl http://
• curl https://
• wget http://
• wget https://
• chmod +x /tmp
• /tmp/
• /var/tmp/
• /dev/shm/
• crontab -e
• /etc/cron.d/
• /var/spool/cron/
• authorized_keys
• python
• gunicorn
• flask
• changedetection.io

What your security team should do

• Treat internet-exposed changedetection.io instances as an emergency patch priority because exploitation is weaponized and the EPSS probability is high.
• Immediately inventory all changedetection.io deployments, including containers, self-hosted Git builds, homelab-style instances, and monitoring stacks managed outside central IT.
• Upgrade to a fixed build at or after commit ee5294740afe26cecb432a9dbceffa0ae7dc426d and verify running image digests or source revisions.
• Temporarily remove public exposure or enforce VPN, SSO, reverse-proxy authentication, and IP allowlisting until the upgrade is complete.
• Hunt for prior exploitation before assuming patching is sufficient, especially on systems exposed before remediation.
• Rotate credentials accessible to the application process, including notification provider tokens, webhooks, API keys, and cloud or infrastructure secrets.
• Review container and host hardening: remove privileged mode, Docker socket mounts, broad hostPath mounts, unnecessary writable directories, and unrestricted outbound internet access.
• Add SIEM detections for Jinja2 SSTI patterns in HTTP requests and for shell/network utilities spawned by Python, Flask, Gunicorn, or changedetection.io processes.
• If evidence of command execution is found, preserve forensic artifacts, isolate the host or container, rebuild from known-good images, and perform broader credential and lateral-movement investigation.