CVE-2026-12564 Red Hat · Red Hat Ansible Automation Platform 2.4 for RHEL 8

Automation-controller: automation-controller: kubernetes service account token exfiltration via hashicorp vault credenti

Vulnerability at a glance

Severity, exploitation likelihood & attack requirements

CVSS v3.1 severity
9.6Critical
EPSS · exploitation likelihood
0.348% Probability within 30 daysPercentile 28.2
EPSS trend
Unchanged Since 2026-10-19
Known exploitation
Not in KEV CISA KEV catalog Absence does not establish safety
Attack vector
NetworkRemotely reachable
Attack complexity
LowFewer obstacles to exploitation
Privileges required
LowBasic privileges required
User interaction
NoneNo user action needed
Exploit availability & maturity
Not scored Availability not established No explicit exploit maturity assessment View exploit evidence
How to read the colors & trend
Higher exposureElevatedModerateLower exposureUnknown / unassessed

CVSS colors follow its reported severity. Attack-factor colors describe each requirement, not an overall risk rating. Gray also covers absence from KEV; absence does not establish safety.

EPSS display bands: below 1% blue, 1–10% amber, 10–50% orange, 50% and above red. These are presentation bands, not FIRST severity categories. The trend compares daily EPSS probabilities, not percentile ranks; “pp” means percentage points. The sparkline shows relative movement, with its vertical scale fitted to the observed scores.

Already protected by existing Atomicorp rules No new CVE-specific rule required.

Atomicorp ModSecurity protection

Protected by Atomicorp rules

Atomicorp ModSecurity rules block attacks exploiting this vulnerability. Keep your rules current.

By targeting underlying attack techniques and CWE weakness classes, existing rules can protect against newly disclosed vulnerabilities. Rule changes are regression-tested against attack and false-positive corpora.

10 rules identified Verified 2026-09-06 View rules & research details →

WAF protection does not change the CVSS or EPSS score. Keep your software patched and your Atomicorp rules current.

CISA SSVC assessment

CISA ADP · Assessed 2026-08-18 · SSVC 2.0.3

Exploitation
None reported
Automatable
No
Technical Impact
Total

Stakeholder-Specific Vulnerability Categorization records CISA’s assessment of exploitation, automation, and technical impact. “None reported” reflects the assessment date; it does not establish that no exploit exists. View SSVC source details.

On this page

CVE Details

Technical vulnerability details · CVSS assessments, exploit evidence & CPE data

CVSS assessments

CVSS v3.1 · secalert@redhat.com

  • Base score: 9.6
  • Base severity: CRITICAL
  • Exploitability subscore: 3.1
  • Impact subscore: 5.8
  • Assessment type: Secondary
  • Source identifier: secalert@redhat.com
  • Full vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N
    • Attack vector: Network
    • Attack complexity: Low
    • Privileges required: Low
    • User interaction: None
    • Scope: Changed
    • Confidentiality impact: High
    • Integrity impact: High
    • Availability impact: None
  • Exploit maturity: Not scored

Exploitability and impact subscores describe the vulnerability’s technical characteristics. Exploit maturity describes the reported state of exploitation; these are separate measures.

Assessment source: NVD record (opens in a new tab) · CVE record (opens in a new tab)

CISA SSVC assessments

These are CISA’s published decision points at the assessment time. They are not a complete organization-specific prioritization decision.

  • Provider: CISA ADP
  • Provider identifier: 134c704f-9b21-4f2e-91b3-4a467353bcc0
  • SSVC version: 2.0.3
  • Role: CISA Coordinator
  • Assessment timestamp: 2026-08-18T19:43:25.467171Z
  • Exploitation: none
  • Automatable: no
  • Technical Impact: total
  • Source: CISA ADP in the CVE record (opens in a new tab)

Vulnerable CPE configurations

No vulnerable CPE configurations are supplied in the current NVD record. See the affected-product information and vendor guidance on this page.

Vulnerability Description

A flaw was found in the AAP Controller’s HashiCorp Vault credential plugin. The kubernetes_auth() function in awx_plugins/credentials/hashivault.py reads the controller pod’s Kubernetes service account token and sends it to an attacker-controlled URL when a HashiCorp Vault Secret Lookup credential with kubernetes_role authentication is tested. An authenticated attacker with credential-creation privileges can exfiltrate the service account token, gaining Kubernetes API access to the control plane namespaces with full pod CRUD and secret read permissions, including database credentials and the Django SECRET_KEY.

  1. Maintain the observed Atomicorp protections. Keep your Atomicorp commercial rules current and confirm that the selected observed rules (337109 , 337110 , 340162 , 340163 , 340165 , 344360 , 347009 , 390722 , 398021 , 398022 ) have not been locally disabled. Atomicorp commercial rules are enabled by default. If you use Atomic WAF, review the applicable policy and rule settings.

  2. Apply the vendor’s remediation. WAF protection is defense in depth and does not replace upgrading or following the affected vendor’s guidance.

    • Versions reported unaffected: Red Hat Red Hat Ansible Automation Platform 2.4 for RHEL 8 version 0:4.5.36-1.el8ap.
    • Versions reported unaffected: Red Hat Red Hat Ansible Automation Platform 2.4 for RHEL 9 version 0:4.5.36-1.el9ap.
    • Versions reported unaffected: Red Hat Red Hat Ansible Automation Platform 2.5 for RHEL 8 version 0:4.6.33-1.el8ap.
    • Versions reported unaffected: Red Hat Red Hat Ansible Automation Platform 2.5 for RHEL 9 version 0:4.6.33-1.el9ap.
    • Versions reported unaffected: Red Hat Red Hat Ansible Automation Platform 2.6 for RHEL 9 version 0:4.7.17-1.el9ap.
    • Versions reported unaffected: Red Hat Red Hat Ansible Automation Platform 2.6 version 1789673739.
    • Versions reported unaffected: Red Hat Red Hat Ansible Automation Platform 2.7 version 1788918363.
    • CNA guidance source: redhat (opens in a new tab)
    • Vendor workaround: The following practices would help for avoiding exposure and mitigate this flaw:
  • Restrict network egress from controller pods using Kubernetes NetworkPolicy to prevent outbound connections to untrusted destinations. Only allow connections to known Vault server endpoints.
  • Review and restrict the RBAC permissions of the automation-controller service account to follow the principle of least privilege. Remove unnecessary secret read access.
  • In AAP Cloud environments, audit credential-creation activity for suspicious HashiCorp Vault credentials with external or unusual URLs.
  • Monitor Kubernetes audit logs for unexpected API calls using the automation-controller service account, particularly secret reads and pod operations from EE pods.
  • Rotate the automation-controller service account token if unauthorized access is suspected.
  • Consider restricting the “create credential” privilege to only trusted administrators until the fix is available.
  1. Validate after changes. Confirm rule updates are current, review WAF events for the affected application, and test application behavior after vendor upgrades, mitigations, or local policy changes.

Research Notes

Atomicorp WAF protections are designed around attack techniques and exploit behaviors, allowing existing protections to apply across multiple vulnerabilities without requiring a unique rule for every CVE.

Public Vulnerability References

Test or Research Source

  • Source: Atomicorp AI Research Framework
  • Tags: cve, derived, ssrf, waf-probe

Research Note Context

This research note documents exploit-technique analysis associated with this vulnerability and references Atomicorp WAF protections observed during engineering review, testing, or validation activities.

Atomicorp security controls are generally designed to identify and mitigate attack techniques and exploit behaviors rather than individual CVE identifiers. As a result, protections developed for one vulnerability may also apply to related attack variants and future vulnerabilities using similar techniques.

Learn More

Atomicorp develops commercially supported security technologies for web applications, servers, endpoints, workloads, and legacy enterprise platforms.

Organizations interested in protecting systems against exploit techniques associated with vulnerabilities such as this one can learn more about:

  • Atomic ModSecurity Rules: commercially maintained WAF rules for ModSecurity deployments, including protections for web attacks, bots, scanners, malware, exploitation attempts, and emerging vulnerability classes.
  • Atomic WAF: an enterprise web application firewall with Atomicorp rules, centralized management, reporting, authentication controls, and operational tooling.
  • Atomic ModSecurity Integrator: a special licensing option for MSPs, MSSPs, OEMs, VARs, reverse proxy providers, and other integrators who want to incorporate Atomicorp ModSecurity rule technology into their own products or services.
  • Atomic OSSEC: an enterprise OSSEC-based intrusion detection, compliance, and security monitoring platform.
  • Atomic Protector: workload protection for Linux, web, cloud, data center, and hybrid environments.

For additional information, product evaluations, or technical discussions, visit https://www.atomicorp.com/ or https://modsecurity.io/ (opens in a new tab) .