EUVD-2026-53835
GHSA-62q9-5g2h-5gxp
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/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:N/AU:X/R:X/V:X/RE:X/U:Clear
AC:H reflects deployment-specific preconditions (S3 credential vending enabled, out-of-bounds readable object) beyond attacker control; PR:L confirmed by required authenticated registration privilege; C:L only.
Primary rating from Vendor (apache).
CVSS VectorVendor: apache
Lifecycle Timeline
2DescriptionCVE.org
Apache Polaris did not consistently validate storage locations supplied during table and view registration.
An authenticated principal with permission to register a table or view could, depending on the affected release and registration path, cause Polaris to use the catalog's storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog's allowed storage locations.
If the catalog's underlying credentials could read an object outside that boundary, this could disclose limited information from the object.
Polaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary.
This second condition did not itself cause Polaris to read the referenced external locations during registration.
The demonstrated impact is limited to confidentiality.
No unauthorized data modification or availability impact has been demonstrated.
The server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog's underlying storage credentials can read.
Exploitation requires an authenticated principal with table- or view-registration privileges.
AnalysisAI
Apache Polaris incorrectly enforces storage location boundaries during Iceberg table and view registration, enabling an authenticated principal with registration privileges to cause the catalog service to read S3 objects outside the configured allowed storage perimeter. Exploitation depends on a deployment running S3 credential vending where the catalog's underlying credentials can access objects beyond the allowed boundary - a constrained but realistic enterprise configuration. The demonstrated impact is limited to partial confidentiality disclosure of out-of-bounds objects; no unauthorized write or availability impact has been demonstrated, and no public exploit or active exploitation has been identified at time of analysis.
Technical ContextAI
Apache Polaris is an open-source REST catalog implementation for Apache Iceberg, enabling centralized governance of table and view metadata across object storage backends. The vulnerability stems from CWE-863 (Incorrect Authorization): Polaris failed to consistently validate that caller-supplied storage location URIs in registration requests fell within the catalog's configured allowed storage locations before using the catalog's own storage credentials to fetch the referenced Iceberg metadata file. This breaks the SSRF-adjacent trust boundary that S3 credential vending relies on - the catalog's IAM role or access key may have broad read access across an S3 bucket hierarchy, and the authorization check that should gate which paths those credentials are applied to was not uniformly enforced across all registration paths and affected releases. No CPE strings were provided in the input; affected version ranges must be confirmed via the Apache security advisory at https://lists.apache.org/thread/scd8p9wy8b9j3om5wohbotpfycnmmjl4.
RemediationAI
Consult the Apache Polaris security advisory at https://lists.apache.org/thread/scd8p9wy8b9j3om5wohbotpfycnmmjl4 for the patched release version and upgrade instructions; an exact fix version was not specified in the available intelligence data, so the advisory is authoritative. As an immediate compensating control, restrict the table- and view-registration privilege to only trusted, internal principals in your Polaris authorization model - reducing the population of users who can trigger the affected code paths. If S3 credential vending is not required for your workloads, disabling or not configuring it removes the primary exploitation pathway for the server-side read condition, though the second condition (accepting metadata with out-of-boundary references) may still apply. Ensure catalog IAM credentials are scoped with least-privilege S3 read access limited to the catalog's allowed storage prefixes at the IAM policy level as a defense-in-depth measure, so that even if boundary validation is bypassed, the credentials cannot read unintended objects. Review audit logs for anomalous table or view registration requests referencing unexpected S3 paths.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today