CVE-2026-94416 in Ansible Automation Platform
Summary
by MITRE • 09/24/2026
An authorization bypass was found in the Ansible Automation Platform (AAP) gateway. The gateway API allows an authenticated administrator to create a new service key for the Controller service cluster. Because service-key creation is not restricted to the installer-provisioned provisioning path, an administrator-issued key is cryptographically indistinguishable from a legitimate one and can be used to forge a service-authentication token that impersonates the Controller service. Combined with the gateway OIDC workload-identity endpoint (enabled via FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED), the attacker can drive the gateway to sign Workload Identity Tokens (WITs) for arbitrary Controller workloads. A downstream resource server such as HashiCorp Vault that trusts the gateway OIDC key will accept the forged WIT and return the AAP credentials bound to that workload, disclosing secrets beyond the attacker's authorization boundary.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability in question represents a critical authorization bypass within the Ansible Automation Platform gateway component, specifically targeting the service-key management functionality. The core technical flaw stems from an insufficient restriction on the creation of new service keys for the Controller service cluster. While the system is designed to allow authenticated administrators to generate these keys, it fails to enforce that such operations must occur exclusively through the installer-provisioned provisioning path. This architectural oversight allows any administrator with valid credentials to manually create a service key outside of the intended secure workflow. Because there are no distinguishing cryptographic markers or metadata fields that differentiate between an installer-generated key and one created by an arbitrary administrator, the resulting keys are cryptographically indistinguishable from legitimate ones. This lack of differentiation is fundamental to the exploit chain, as it enables an attacker to generate a valid service-authentication token that the system will accept without question, effectively allowing the impersonation of the Controller service itself.
The operational impact of this flaw is significantly amplified when combined with specific configuration settings, particularly the enabling of the FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED flag. When this feature is active, the gateway provides an OIDC workload-identity endpoint capable of signing Workload Identity Tokens for various workloads within the platform. An attacker who has obtained a forged service key through the aforementioned authorization bypass can leverage this endpoint to drive the gateway into signing WITs for arbitrary Controller workloads. This capability transforms a simple authentication issue into a severe identity forgery problem, as the attacker gains the ability to masquerade as any workload running within the Ansible Automation Platform environment. The forged tokens are structurally valid and cryptographically signed by the trusted gateway key, making them indistinguishable from legitimate tokens issued during normal operations.
The consequences of this vulnerability extend beyond the immediate platform boundaries into downstream resource servers that trust the gateway's OIDC identity provider model. A prime example is HashiCorp Vault, which is commonly integrated with Ansible Automation Platform to manage secrets and credentials securely. When a downstream service like Vault receives a forged Workload Identity Token from an attacker impersonating a specific workload, it validates the token against its trusted issuer configuration. Since the token was signed by the gateway's legitimate OIDC key, the resource server accepts it as authentic. Consequently, HashiCorp Vault will return secrets and credentials bound to that specific workload identity. This results in a complete disclosure of sensitive data beyond the attacker's original authorization boundary, effectively granting them access to all resources associated with the impersonated workload.
From a classification perspective, this vulnerability aligns closely with CWE-269: Improper Privilege Management, as it involves an actor obtaining privileges that they are not authorized to possess through bypassing intended controls. Furthermore, the exploitation technique maps directly to MITRE ATT&CK techniques such as T1078: Valid Accounts and T1550: Use Alternate Authentication Credentials, where the attacker uses forged credentials derived from a compromised or misconfigured service identity to gain unauthorized access. The scenario also reflects aspects of CWE-287: Improper Authentication, specifically in the failure to distinguish between different sources of authentication tokens despite having distinct trust levels.
Mitigation strategies must address both the immediate configuration risks and the underlying architectural flaws. Administrators should immediately disable the FEATURE_OIDC_WORKLOAD_IDENTITY_ENABLED setting if it is not strictly required for their deployment model, thereby removing the ability to forge Workload Identity Tokens even if a service key is compromised. Additionally, strict access controls should be implemented around the gateway API endpoints responsible for service-key creation, ensuring that only automated provisioning scripts or highly restricted administrative processes can invoke these functions. Patching to the latest version of Ansible Automation Platform where this logic has been corrected is essential. Long-term remediation requires implementing cryptographic differentiation between installer-provisioned keys and manually created ones, such as embedding a distinct issuer claim or signature prefix in tokens generated by non-standard paths, ensuring that downstream services can validate not just the signature but also the provenance of the identity token.