CVE-2026-115416 in Athena
Summary
by MITRE • 10/23/2026
Incorrect authorization checks in Amazon Athena engine version 3 query processing could have allowed an authenticated user to read AWS account identifiers and SQL statement text query metadata from other AWS accounts. Query results, and data stored in Amazon S3 or other data sources, were not accessible through this issue.
AWS remediated the issue on October 7, 2026. No customer action is required.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified within the Amazon Athena engine version 3 query processing mechanism represents a critical failure in access control logic, specifically categorized under CWE-862: Missing Authorization. This flaw allowed authenticated users to bypass intended isolation boundaries between distinct AWS accounts. In cloud-native environments where multi-tenancy is fundamental, such as that provided by managed data lake services like Amazon Athena, the integrity of identity and access management policies is paramount. The specific technical deficiency lay in how query metadata was handled during processing; rather than strictly binding metadata retrieval operations to the principal initiating the request or validating ownership against a centralized authorization service with sufficient granularity, the engine permitted cross-account enumeration of sensitive operational data. This indicates that while the core data plane remained secure, the control plane interactions lacked rigorous validation checks for resource ownership when exposing query-related information.
The operational impact of this vulnerability was primarily informational and related to metadata exposure rather than direct data compromise. An attacker with valid credentials in one AWS account could exploit this misconfiguration to read AWS account identifiers associated with other accounts as well as the text of SQL statements being processed by those external entities. This leakage poses significant risks regarding intellectual property theft, competitive intelligence gathering, and operational security degradation. By observing the structure and content of SQL queries from competitors or partner organizations, an adversary could infer business logic, data schemas, reporting requirements, and strategic initiatives. Furthermore, obtaining AWS account identifiers facilitates further reconnaissance efforts, allowing for targeted attacks against specific organizational units or enabling correlation with other leaked identity information to build a comprehensive profile of target infrastructure.
It is crucial to emphasize that the scope of this vulnerability was strictly limited to metadata and did not extend to the underlying data assets themselves. Query results remained inaccessible through this flaw, nor could an attacker access any data stored in Amazon S3 buckets or other connected data sources via this specific vector. This distinction highlights a successful defense-in-depth strategy where the core data storage layer maintained its integrity despite weaknesses in the query processing engine's metadata handling. The security boundary for actual data content remained intact, preventing unauthorized reading of sensitive records, financial information, or personal identifiable information that resides within the lakehouse architecture.
AWS addressed this issue by implementing stricter authorization checks within the Athena engine version 3 codebase to ensure that metadata requests are properly validated against account ownership before being served. The remediation was deployed on October 7, 2026, effectively closing the gap in access control logic. Because AWS managed the fix at the service level and pushed it as part of their standard infrastructure maintenance cycle, no customer action is required to mitigate this specific vulnerability. Users relying on Amazon Athena are protected by default once they utilize versions that include these security patches. This incident serves as a reminder for organizations to maintain awareness of cloud provider security bulletins and ensure that any custom integrations or scripts interacting with query APIs adhere to the principle of least privilege, even when underlying platform vulnerabilities have been resolved.