CVE-2026-94416

Executive Summary

CVE-2026-94416 is an authentication bypass by spoofing (CWE-290) in the Ansible Automation Platform (AAP) gateway. An authenticated administrator can create a service key for the Controller service cluster outside the installer-provisioned path; because that key is cryptographically indistinguishable from a legitimate one, the attacker can forge a service-authentication token and, via the gateway OIDC workload-identity endpoint, cause the gateway to sign Workload Identity Tokens (WITs) for arbitrary Controller workloads. A downstream resource server that trusts the gateway OIDC key — for example, HashiCorp Vault — will accept the forged WIT and return the AAP credentials bound to that workload, disclosing secrets beyond the attacker's authorization boundary. Impact is high-confidentiality with a scope change (CVSS 6.8, S:C/C:H), requiring high privileges (PR:H) and no user interaction.

Technical Analysis

The AAP gateway exposes a service-key provisioning mechanism that binds a client to the Controller service cluster. Legitimate service keys are provisioned by the installer during deployment. The vulnerability is a missing restriction: service-key creation through the gateway API is not limited to the installer-provisioned provisioning path, so an authenticated administrator can invoke it directly and mint a new key for the Controller service cluster.

The core defect is the absence of a cryptographic or logical differentiator between installer-provisioned keys and administrator-issued keys. From the gateway's perspective the administrator-issued key is indistinguishable from the legitimate one, so any downstream check that relies on possession of the key to establish service identity succeeds. This is the "authentication bypass by spoofing" class (CWE-290): the attacker does not break the crypto, they satisfy it with material the system should never have issued to them.

The second component is the gateway OIDC workload-identity endpoint, gated behind the FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED flag. When enabled, the gateway operates as an OIDC identity provider that issues Workload Identity Tokens (WITs) for Controller workloads. With a forged service-authentication token impersonating the Controller service, the attacker can drive the gateway to sign a WIT for any arbitrary Controller workload — the authorization decision is made on the identity the attacker successfully spoofed, not on the actual caller.

The trust boundary failure lands at the third party: a downstream resource server (HashiCorp Vault is named) that has been configured to trust the gateway OIDC key will validate a forged WIT as authentic and release the AAP credentials bound to the spoofed workload. That is secrets disclosure through an identity-provider chain-of-trust, entirely within protocol rules. The attacker's effective authorization boundary is expanded from "administrator with the ability to enumerate their own credentials" to "credentials bound to arbitrary Controller workloads."

Notable technical constraints evident from the vector: AC:L (no unusual access conditions beyond the feature being present), PR:H (a pre-existing administrative account is required), UI:N, S:C (the vulnerable component is the gateway, but the impact crosses to a separate security authority — the relying party resource server), C:H with I:N/A:N (this is a read/disclosure primitive, not tampering or denial of service).

No function names, API routes, or request schemas are published in the NVD description; those implementation specifics are unavailable and are deliberately not invented here. Detection and mitigation must therefore target the class: unauthorized service-key creation, service-token reuse from non-installer contexts, and WIT issuance to workloads that do not normally request them.

Exploitation Scenarios

No public PoC, exploit code, or Nuclei template is available; the attack chain below is inferred strictly from the vulnerability class and the mechanism in the NVD description.

1. Reconnaissance / target identification. The attacker must already hold valid administrative credentials for the AAP gateway (PR:H). They confirm the deployed gateway exposes the OIDC workload-identity functionality — operationally indicated by the FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED flag being enabled — and identify which downstream resource servers (e.g., HashiCorp Vault) are configured to trust the gateway as an OIDC provider. Reconnaissance also maps which Controller workloads have valuable credentials bound to them.

2. Triggering the flaw class. Using the administrative session, the attacker calls the gateway API to create a new service key for the Controller service cluster. The missing control is that this operation is not restricted to the installer-provisioned path, so the gateway issues the key. Because the resulting key carries no marker distinguishing it from an installer-provisioned key, the attacker now holds service-authentication material that the gateway will treat as legitimate Controller identity.

3. Payload / execution at the vulnerability-class level. The attacker uses the administrator-issued key to forge a service-authentication token impersonating the Controller service. Presenting that token, they reach the gateway's OIDC workload-identity endpoint and cause it to sign Workload Identity Tokens (WITs) for arbitrary Controller workloads. No cryptographic breaking is required — the gateway signs because it has been convinced of the caller's identity by the forged-but-indistinguishable token.

4. Post-exploitation impact. The forged WIT is presented to a downstream resource server that trusts the gateway OIDC key. The resource server validates the signature, accepts the workload identity, and returns the AAP credentials bound to that workload. The attacker obtains secrets that were never within their authorization boundary. With C:H / I:N / A:N, the outcome is broad credential disclosure without destructive or modifying effects — ideal for quiet lateral movement and privilege escalation inside the AAP and connected Vault estates.

Impact Assessment

Business impact. The disclosed material is credentials — specifically AAP credentials bound to Controller workloads. Credential compromise in an automation platform is high-leverage: AAP credentials frequently unlock managed nodes, cloud subscriptions, CI/CD pipelines, and secret backends. A single successful chain can convert one administrator account into the credential set of many workloads.

Affected systems. AAP gateway deployments where the service-cluster service-key path is reachable by administrators and where OIDC workload identity is enabled. The blast radius extends to every downstream resource server that trusts the gateway OIDC key — HashiCorp Vault is named in the description, but the pattern generalizes to any relying party. Note that no affected/fixed version data was published, so asset owners must determine exposure by configuration, not by version banner.

CVSS subscores (v3.1, 6.8 Medium). AV:N — reachable over the network. AC:L — no conditions beyond the pre-existing admin session and feature flag. PR:H — administrative privileges required, which is the primary score limiter and the reason this is not Critical on the base metric. UI:N — no victim interaction. S:C — the gateway and the downstream resource server are separate security authorities, so impact crosses scope. C:H — full disclosure of the credentials bound to targeted workloads. I:N / A:N — no integrity or availability impact; this is a disclosure primitive.

Exploit availability. None public. EPSS has not scored this CVE by FIRST.org, and CISA KEV does not list it. Exploitation is nonetheless attractive to a post-compromise insider because it requires no exploit code — only legitimate administrative API access used off-label.

Detection Guidance

Detection strategy: monitor creation of service keys for the Controller service cluster, look for service-authentication tokens presented from administrative sessions rather than installer/provisioning contexts, and alert on anomalous WIT issuance. All rules below are behavioral and signature-flexible because no request schema is published; tune field names to your deployment before enabling.

Sigma Rule

title: Suspicious AAP Gateway Controller Service-Key Creation
id: 8f3a1c2e-9441-4a6b-9c1d-aapgateway94416
status: experimental
description: Detects creation of a Controller service-cluster service key through the AAP gateway API outside the installer-provisioned path, consistent with CVE-2026-94416 CWE-290 authentication bypass by spoofing.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-94416
author: valtersit.com
date: 2026/01/01
tags:
  - attack.t1078
  - attack.t1550.001
  - cve.2026.94416
logsource:
  product: ansible
  service: gateway
detection:
  selection_endpoint:
    http.method: 'POST'
    http.url|contains:
      - '/service_key'
      - '/service-key'
      - '/service_key/'
  selection_actor:
    user.role: 'admin'
  filter_installer:
    user.name|contains:
      - 'installer'
      - 'aap-setup'
  condition: selection_endpoint and selection_actor and not filter_installer
falsepositives:
  - Legitimate administrative rotation of a Controller service key
level: high

YARA Rule

rule CVE_2026_94416_AAP_Gateway_Service_Key_Abuse
{
    meta:
        description = "Detects AAP gateway service-key creation or WIT-issuance log/artifact content consistent with CVE-2026-94416 authentication bypass by spoofing"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-94416"
        cve = "CVE-2026-94416"
        date = "2026-01-01"
        severity = "high"

    strings:
        $a = "service_key" ascii wide nocase
        $b = "service-key" ascii wide nocase
        $c = "controller" ascii wide nocase
        $d = "workload_identity_token" ascii wide nocase
        $e = "FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED" ascii wide
        $f = "oidc/workload" ascii wide nocase
        $g = "service_auth_token" ascii wide nocase

    condition:
        filesize < 2MB and
        (2 of ($a,$b,$c,$g)) and
        (any of ($d,$e,$f))
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-94416 Possible AAP Gateway Controller Service-Key Creation / WIT Issuance"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"service"; nocase; http.uri; content:"key"; nocase; http.header; content:"Authorization"; nocase; classtype:attempted-admin; reference:cve,2026-94416; reference:url,nvd.nist.gov/vuln/detail/CVE-2026-94416; sid:2026944161; rev:1;)

alert http any any -> any any (msg:"CVE-2026-94416 AAP Gateway OIDC Workload-Identity Endpoint Access"; flow:established,to_server; http.uri; content:"oidc"; nocase; http.uri; content:"workload"; nocase; http.method; content:"POST"; classtype:policy-violation; reference:cve,2026-94416; sid:2026944162; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ api where http.request.method == "POST"
      and http.request.uri : "*service*key*"
      and user.roles : "admin" ]
  [ authentication where event.action == "token_issuance"
      and oauth.token.type : "workload_identity" ]

api where http.request.method == "POST"
  and http.request.uri : "*service*key*"
  and user.name != "installer"
  and user.roles : "admin"

Splunk SPL Query

index=ansible_gateway sourcetype=aap:gateway:api
(http.method=POST AND (uri_path="*service_key*" OR uri_path="*service-key*" OR uri_path="*workload_identity*" OR uri_path="*oidc*workload*"))
NOT user=installer
| eval risk=case(match(uri_path,"service_key"),"service_key_creation", match(uri_path,"workload_identity"),"wit_issuance", true(),"other")
| stats count min(_time) as first_seen max(_time) as last_seen values(uri_path) as paths values(src_ip) as src_ips by user risk
| where count > 0
| eval first_seen=strftime(first_seen,"%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen,"%Y-%m-%d %H:%M:%S")
| sort - count

Wazuh OSSEC Rule

<group name="ansible,aap,gateway,cve-2026-94416,">
  <rule id="2026944" level="12">
    <decoded_as>json</decoded_as>
    <field name="http_method">POST</field>
    <field name="uri_path" type="pcre2">(?i)service[_-]?key</field>
    <field name="user_role">admin</field>
    <description>CVE-2026-94416: AAP gateway Controller service-key created via admin session outside installer path</description>
    <mitre>
      <id>T1078</id>
      <id>T1550.001</id>
    </mitre>
    <group>authentication_bypass,</group>
  </rule>

  <rule id="2026945" level="13">
    <decoded_as>json</decoded_as>
    <field name="uri_path" type="pcre2">(?i)oidc.*workload|workload.*identity</field>
    <field name="token_type">workload_identity</field>
    <description>CVE-2026-94416: AAP gateway issued a Workload Identity Token - possible forged service token abuse</description>
    <mitre>
      <id>T1550.001</id>
    </mitre>
    <group>credential_access,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED) — no patch evidence from any tracked source. No vendor fix or workaround has been published. Version range is unspecified, so exposure must be assessed by configuration.

1) Immediate mitigations

• Disable the OIDC workload-identity feature by setting FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED to a disabled value. This removes the WIT-signing capability the chain depends on and is the single highest-value initial control.
• Review downstream resource servers (e.g., HashiCorp Vault) for trust relationships that accept the AAP gateway as an OIDC provider. Where the trust is not operationally required, suspend the trust relationship or the associated role bindings until the gateway is fixed.
• Audit and rotate existing service keys for the Controller service cluster. Any key that cannot be attributed to the installer provisioning run should be treated as suspect and revoked.
• Restrict administrative access to the AAP gateway to the minimum necessary set, since PR:H is the only barrier in the exploit chain.

2) Patch / upgrade steps

• No patch is currently available. There is nothing to upgrade to. Subscribe to vendor security advisories for Red Hat / Ansible Automation Platform and to the NVD entry for CVE-2026-94416 to be notified when a fixed release, affected-version range, and CVE-specific workaround are published.
• When a fix ships, apply it to the gateway, then re-enable the OIDC workload-identity feature only after verifying that service-key creation is once again restricted to the installer-provisioned path.

3) Long-term hardening

• Enforce cryptographic differentiation between installer-provisioned keys and any administrator-issued key, so a self-minted key can never be accepted as service identity. Where the platform supports it, bind service credentials to hardware/attestation or short-lived certificates rather than long-lived symmetric keys.
• Reduce token lifetime and scope for WITs so that a forged token has narrow, auditable reach.
• Apply least-privilege to downstream credential bindings so a single workload identity does not unlock a large blast radius, and enable audit logging on the relying party side so every WIT presentation is recorded and reviewable.
• Enforce strict separation of duties so administrators cannot unilaterally mint service identities; require dual control for service-cluster credential lifecycle operations.
• Continuously monitor for service-key creation and WIT issuance outside expected provisioning windows using the detection content above.

References

• NVD — CVE-2026-94416: https://nvd.nist.gov/vuln/detail/CVE-2026-94416
• MITRE CWE-290 — Authentication Bypass by Spoofing: https://cwe.mitre.org/data/definitions/290.html
• MITRE ATT&CK — T1078 Valid Accounts: https://attack.mitre.org/techniques/T1078/
• MITRE ATT&CK — T1550.001 Use Alternate Authentication Material: Application Access Token: https://attack.mitre.org/techniques/T1550/001/
• Red Hat Product Security — Ansible Automation Platform security advisories: https://access.redhat.com/security/

Exploit-in-the-wild and threat-actor campaign evidence: none available. CISA KEV does not list CVE-2026-94416, no public PoC or exploit code exists, and FIRST.org has not yet assigned an EPSS score. This is an unpatched, design-level authorization bypass requiring pre-existing administrative access; the practical risk today is privilege abuse by an insider or a holder of compromised admin credentials.