CVE-2026-71460 in Ansible Automation Platform
Summary
by MITRE • 09/23/2026
/api/v2/config/ is protected only by IsAuthenticated. license_info (account_number, subscription_id, pool_id, sku, support_level, instance counts) returned to any authenticated user. The superuser/auditor gate only covers project_base_dir/project_local_paths/custom_virtualenvs, not license_info. Enables social engineering against Red Hat support and estate sizing reconnaissance.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/23/2026
The vulnerability identified in the /api/v2/config endpoint represents a critical failure in access control logic within the application's authentication and authorization framework. While the endpoint is correctly protected by an IsAuthenticated middleware, which ensures that only logged-in users can access it, it lacks granular role-based or attribute-based access controls necessary to restrict sensitive data exposure. Specifically, this endpoint returns comprehensive license information including account numbers, subscription identifiers, pool IDs, SKU details, support levels, and instance counts. This level of detail is typically reserved for administrative functions or specific billing integrations but has been inadvertently exposed to any authenticated user regardless of their role within the organization. The security architecture incorrectly assumes that authentication alone provides sufficient protection for this data class, failing to distinguish between general users who require basic configuration access and privileged entities like superusers or auditors who are authorized to view licensing details.
The technical flaw lies in the misalignment between the scope of protected resources and the permissions granted by the IsAuthenticated gate. The system correctly restricts access to sensitive directories such as project_base_dir, project_local_paths, and custom_virtualenvs through elevated privilege checks for superusers or auditors. However, this restrictive logic was not applied consistently across all endpoints containing proprietary business data. Consequently, any valid user account can query the configuration endpoint and retrieve a complete snapshot of the organization's licensing posture. This inconsistency creates an authorization bypass where standard users gain access to information that should be strictly confined to higher-privilege roles or external billing systems only.
The operational impact of this vulnerability is significant, primarily facilitating estate sizing reconnaissance by potential attackers. By obtaining accurate data on subscription IDs and instance counts, adversaries can map the scale and structure of an organization's infrastructure without needing elevated privileges. This intelligence allows for precise planning of subsequent attacks tailored to the specific resources available within the target environment. Furthermore, the exposure of account numbers and support levels enables sophisticated social engineering campaigns against Red Hat support channels. Attackers possessing this data can impersonate legitimate administrators or billing contacts with greater credibility, potentially tricking support staff into resetting credentials, modifying subscription settings, or revealing additional internal details under the guise of routine account verification.
This vulnerability aligns closely with CWE-284 Improper Access Control and CWE-359 Exposure of Private Information to an Unauthorized Actor. From a tactical perspective, it supports ATT&CK techniques related to Discovery such as T1087 Account Discovery and potentially influences Social Engineering via Pretexting if the data is leveraged against support personnel. To mitigate this risk, immediate remediation should involve implementing role-based access control checks on the /api/v2/config endpoint. Access to license_info fields must be restricted exclusively to users with specific administrative or auditing roles that have been explicitly verified for such privileges. Additionally, input validation and output filtering mechanisms should be reviewed to ensure that sensitive data is not serialized in responses intended for general user contexts. Regular security audits of API endpoints are recommended to prevent similar inconsistencies where authentication gates are applied broadly while authorization checks remain absent for specific high-value data objects.