CVE-2025-49521 Overview
CVE-2025-49521 is a code injection flaw in the Event-Driven Ansible (EDA) component of the Red Hat Ansible Automation Platform. The platform evaluates user-supplied Git branch or refspec values as Jinja2 templates without proper sanitization. Authenticated users can inject template expressions that execute arbitrary commands or read sensitive files on the EDA worker. On OpenShift deployments, attackers can use this primitive to steal service account tokens and pivot deeper into the cluster. The flaw is classified under CWE-94: Improper Control of Generation of Code.
Critical Impact
Authenticated attackers can achieve arbitrary command execution on EDA workers and steal OpenShift service account tokens, leading to cluster compromise.
Affected Products
- Red Hat Ansible Automation Platform (Event-Driven Ansible component)
- Ansible Automation Platform deployments on OpenShift
- EDA worker nodes processing Git source-controlled rulebooks
Discovery Timeline
- 2025-06-30 - CVE-2025-49521 published to NVD
- 2025-06-30 - Red Hat publishes advisory RHSA-2025:9986
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-49521
Vulnerability Analysis
The Event-Driven Ansible component accepts Git repository configuration parameters, including branch names and refspecs, from authenticated users. These string inputs flow into code paths that render them through the Jinja2 templating engine before passing the result to Git operations. Because Jinja2 supports Python expressions and attribute traversal, an attacker who controls the input controls the executed expression.
An attacker with valid platform credentials and the ability to create or edit a project can supply a branch value containing Jinja2 syntax. When the EDA worker resolves the project, the engine evaluates the expression in the worker's process context. The attacker gains command execution, file read primitives, and access to environment variables holding secrets.
Root Cause
The root cause is the unsafe rendering of untrusted input as a template. Branch and refspec fields should be treated as opaque strings passed verbatim to Git. Instead, the EDA logic invokes Jinja2 rendering on them, conflating data with code [CWE-94]. No allowlist, escaping, or sandboxing prevents the engine from resolving expressions such as object introspection chains that reach os.system, subprocess, or the file system.
Attack Vector
Exploitation requires network access to the Ansible Automation Platform API and an authenticated account with permission to define or modify project sources. The attacker submits a Git project where the branch or refspec field contains a Jinja2 payload. When EDA syncs or activates the rulebook, the worker evaluates the payload. On OpenShift, the worker pod mounts a service account token at /var/run/secrets/kubernetes.io/serviceaccount/token, which the attacker exfiltrates to authenticate as the workload identity and expand access within the cluster. The vulnerability requires low privileges, no user interaction, and yields high impact to confidentiality, integrity, and availability.
Detection Methods for CVE-2025-49521
Indicators of Compromise
- Project definitions containing Jinja2 delimiters such as {{, }}, {%, or %} inside Git branch or refspec fields.
- EDA worker processes spawning unexpected child processes such as sh, bash, curl, or python outside normal Git operations.
- Outbound network connections from EDA worker pods to external hosts that do not match configured Git remotes.
- Reads of /var/run/secrets/kubernetes.io/serviceaccount/token followed by outbound HTTPS traffic.
Detection Strategies
- Audit the Ansible Automation Platform database for project records whose scm_branch or refspec fields contain template syntax characters.
- Inspect EDA worker logs for Jinja2 rendering errors or unusual exceptions tied to project sync operations.
- Correlate authenticated API actions that create or modify projects with subsequent process and network activity on EDA workers.
Monitoring Recommendations
- Enable process and file telemetry on EDA worker nodes and OpenShift pods running EDA workloads.
- Forward Ansible Automation Platform audit logs and OpenShift API audit logs to a central analytics platform for correlation.
- Alert on service account token reads from EDA pods that are followed by API calls to the Kubernetes control plane from unexpected source identities.
How to Mitigate CVE-2025-49521
Immediate Actions Required
- Apply the Red Hat patches referenced in RHSA-2025:9986 to all Ansible Automation Platform installations.
- Review and restrict which roles can create or modify EDA projects and Git source configurations.
- Rotate any OpenShift service account tokens and Git credentials accessible from EDA worker pods if compromise is suspected.
- Audit existing project definitions for malicious template syntax in branch and refspec fields before upgrading.
Patch Information
Red Hat addressed the flaw in the updates published under RHSA-2025:9986. The fix removes Jinja2 evaluation from Git branch and refspec handling so user input is passed as a literal string to Git operations. Refer to the Red Hat CVE page and Bugzilla #2370817 for component versions and errata mapping.
Workarounds
- Limit project creation and editing permissions to a small set of trusted administrators until patches are applied.
- Constrain EDA worker pods on OpenShift with restrictive service accounts, NetworkPolicies, and minimal RBAC to reduce blast radius.
- Apply egress filtering on EDA worker namespaces so workers can only reach approved Git endpoints.
# Configuration example: restrict EDA worker egress and token exposure on OpenShift
# 1. Remove default service account token automount on EDA worker pods
oc patch serviceaccount eda-worker -n aap \
-p '{"automountServiceAccountToken": false}'
# 2. Apply a NetworkPolicy limiting egress to approved Git hosts only
oc apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: eda-worker-egress
namespace: aap
spec:
podSelector:
matchLabels:
app: eda-worker
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/8
ports:
- protocol: TCP
port: 443
EOF
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

