Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-42811 is a critical-severity Improper Input Validation (CWE-20) vulnerability in Apache Polaris. Its CVSS base score is 9.4 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploit Public-Facing Application (T1190); ranked at the 36th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
Apache Polaris, an open-source catalog for Apache Iceberg tables, contains a vulnerability (CVE-2026-42811) in its generation of short-lived Google Cloud Storage (GCS) credentials. Polaris constructs Credential Access Boundary (CAB) policies using CEL conditions to restrict access to a specific table's storage path, derived from namespace and table identifiers. Due to improper escaping, a crafted namespace or table name containing a single quote and URI-safe CEL fragments can break out of the quoted string in the CEL expression, altering the condition to effectively remove path restrictions within the configured GCS bucket. This issue was confirmed in private testing against Polaris 1.4.0 using real GCS infrastructure.
An authenticated attacker with low privileges (PR:L), such as a Polaris principal with catalog privileges, can exploit this by requesting credentials for a crafted table or namespace. The resulting delegated GCS credentials grant broader-than-intended access across the bucket, enabling the attacker to list object prefixes of other tables, read their Iceberg metadata JSON files, create and delete objects under other tables' prefixes, and perform list, read, create, and delete operations on unrelated prefixes in the same bucket. The CVSS v3.1 score of 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) reflects the network-accessible, low-complexity exploitation leading to high confidentiality, integrity, and availability impacts. Testing used a principal with broad catalog privileges; least-privilege RBAC variants remain untested for this storage credential broadening.
Advisories detailing the issue appear on the Apache mailing lists (https://lists.apache.org/thread/hovn5hmkj9wj7v9cd8sn67svg03klgvg) and OSS-Security (http://www.openwall.com/lists/oss-security/2026/05/02/12), published around May 4, 2026. No specific patch or mitigation details are provided in the available information.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-27038
Vulnerability Data
In plain terms, Apache Polaris is supposed to issue short-lived GCS credentials that only work for one table's files, but a crafted namespace or table name can cause those credentials to work across the configured bucket instead. Apache Polaris builds…
more
Google Cloud Storage downscoped credentials by creating a Credential Access Boundary (CAB) with CEL conditions that are intended to restrict access to the requested table's storage path. The relevant CEL string is built from the bucket name and the table path. That table path is derived from namespace and table identifiers. In current code, that path appears to be inserted into the CEL expression without escaping. As a result, a namespace or table identifier containing a single quote and other URI-safe CEL fragments can break out of the intended quoted string and change the meaning of the CEL condition. In private testing against Polaris 1.4.0 on real Google Cloud Storage, it was confirmed that Polaris accepted a crafted identifier and returned delegated GCS credentials whose CEL path restriction had effectively collapsed. Those delegated credentials could then: - list another table's object prefix; - read another table's metadata control file (Iceberg metadata JSON); - create and delete an object under another table's object prefix; - and also list, read, create, and delete objects under an unrelated external prefix in the same bucket that was not part of any table path. That last point is important. The issue is not limited to "another table". In the confirmed setup, once Apache Polaris returned credentials for the crafted table, the path restriction inside the configured bucket was effectively gone. The practical effect is that temporary credentials for one crafted table can be broader than the table Polaris was asked to authorize, and can become effectively bucket-wide within the configured bucket. The current GCS testing used a Polaris principal with broad catalog privileges for setup. A separate least-privilege Polaris RBAC variant has not yet been tested on GCS. However, the storage-credential broadening behavior itself has been confirmed on GCS.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
- 6 hardening rules · 3 OS baselines
V1.1.2V1.3.2V1.3.5V4.3.1
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover missing input validation through analysis or test cases.
SI-10 directly requires validity checks on information inputs, structurally preventing improper or missing validation.
Requiring documented development standards and tools can embed input-validation practices into the engineering process.
Security engineering principles include requirements for safe construction and sanitization of dynamic statements, structurally preventing expression-language injection at design time.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require and enforce input validation during development.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Testing against a defined set of requirements and using code review plus vulnerability scanning forces validation of inputs and handling of unanticipated conditions, reducing the chance that malformed data will be accepted.
Secure-coding guidelines and mandatory security testing (including code scans) compel developers to validate and sanitize inputs at design and implementation time, lowering the incidence of malformed or malicious data reaching downstream components.
Mandating input controls that include integrity checks and input validation ensures that untrusted data is examined before use, blocking the root cause of many injection and malformed-data weaknesses.
Security-by-design principles explicitly call for data validation and sanitization at every layer, reducing the chance that malformed or malicious input will be processed without scrutiny.
Requiring language-specific secure coding standards, peer review, SAST and documented mitigation of common programming errors forces validation of all inputs before they are trusted.
Regular automated validation of system software and data content, combined with scanning of all inbound files, enforces input validation at the boundary before untrusted content is processed.
Hardening callouts derived
Configuration rules from DISA STIG baselines that bear on weaknesses of the type cited by this CVE. Each rule is shown with the relationship its mapping actually records, against the CWE it was authored against. Derived via CVE→CWE over `controls_xwalks` (authoritative rows only; rows rated `none` are excluded).
RHEL 8 (1 rule)
- V-230265 RHEL 8 must prevent the installation of software, patches, service packs, device drivers, or operating system components of local packages without verification they have been digitally signed using a certificate that is issued by a Certificate Authority (CA) that is recognized and approved by the organization. prevents CWE-20