Four critical CVE in one service in one day. On May 4, 2026, Apache Polaris received security advisory, from which data engineers had to get in mood. CVE-2026-42809 from this bundle - the most indicative: CVSS 9.4 (CRITICAL according to CVSS 4.0), vector AV:N/AC:L/AT:N/PR:L/UI:N. The authenticated user with minimal rights sends one request to the REST client API, and Polaris himself designs temporary credentials for him to a random cloud object. No exploit running, no bypassing the WAF. The service works as a credential-automatic with a button "give out the keys to someone else's tank".
In Russian, this vulnerability is devoted only to NVD cards and aggregators - there is no technical analysis. Shut down the gap.
Business logic: why credential vending in data lakehouse is dangerous
Apache Polaris - REST catalog for Apache Iceberg, open-source data organization format in data lakehouse. In production-deeplops, Polaris manages hundreds of tables scattered across S3 (WS), GCS (GCP) or Azure Blob Storage. Every time a client (Spark, Trino, Flink) refers to the table, Polaris can give him temporary credentials - short-lived STS tokens limited to a specific delay storage prefix.
This is credential vending: the directory works as an IAM broker between the user and the cloud storage. The user does not have direct IAM access to S3/GCS - he receives time keys through Polaris, and these keys are limited only to the storage path, where the files of a particular table are located.
Now we project on the threat model - and here the wider context that gives is important full map of the threat of cloud imconfiguration. The IAM role Polaris has access to dozens of cars with production data because it serves the entire catalog. If the attacker controls the scope of the detected entities issued, he gets access not to one table, but to any storage path within the IAM-role of the service. Financial data, PII clients, analytics, ML-models - everything that service Polaris reaches, is available through one HTTP request. For organizing terabytes of sensitive data in data lakehouse is a complete compromising data tier.
Mechanics CVE-2026-42809: how Apache Polaris gives out credentials without validation
The vulnerability sits in the stage-created flow - the mechanism of creating "black" tables in Iceberg REST Catalog. Stage-create is a two-phase operation: first, the table is created as a staged (draw), receives storage credentials to record the initial data, and only then is fixed through commit as a full-fledged table.
According to NVD, the root problem: Polaris gives out temporary credentials to Location Validation and to checks for intersection with other tables (overlap checks). Postponing in steps:
1. Attacking sends request to the stage-create with an arbitrary value location- let's say, s3://finance-production-bucket/reports/.
2. Polaris accepts this location as a target for credential scoping.
3. Polaris constructs delegate storage credentials (STS tokens) tied to the specified location.
4. Credentials return to the attacker before the stage-create path performs the cost price or overlap checks.
5. The attacker uses the received STS tokens for direct access to S3/GCS - through aws cli, boto3, gsutil.
According to NVD, the stage-created flow also takes properties write.data.path and write.metadata.path in the body of the request. This is a secondary vector: the fields are substituted in the effective table location set for credential vending and also do not validate before issuing credentials. From advisory: "those fields are secondary to the main custom-location exploit, but they are still attacker-inluenced cost-positives worth that be validated before any credentials are issued"“These fields are secondary to the main vulnerability associated with setting up the location, but they are still input-entered location data that an attacker can affect and should be checked before issuing any credentials.”.
Two CWEs - Two Aspects of Apache Polaris Vulture
According to the NVD (CNA: Apache Software Foundation), vulnerabilities are assigned two CWEs:
CWE-20 (IMproper Input Validation) - location, write.data.path and write.metadata.path are accepted from the user without checking for belonging to the permitted scope. According to the MITRE classification, the probability of operation is High. Consequences: reading and modifying data, potential DoS.
CWE-862 (Missing Authorization) - no authorization check for access to arbitrary storage path. Polaris checks the right to create a table, but not the right to receive credentials to a particular bakette. By MITRE: the probability of High, the consequences are reading and modifying data, increasing privileges.
The bundle is indicative: the problem is not only that the input is not filtered, but also in the absence of an authorization barrier between the “right to create a table” and “the right to get credentials to any tank within the IAM-role of the service”. Two different defects, one point of entry. Please note: the classic privilege escalation is not here. The attacker does not increase the privilege in Polaris - he uses the legitimate credential vending mechanism, substituting his location. The service voluntarily gives out the keys. By CISA-ADP Technical Impact - Total: complete compromising confidentiality, integrity and availability data tier.
A separate point of attention - Cloud Instantane Metadata API (T1552.005, Credential Access) If Polaris is deployed to EC2/GCE and receives IAM-credentials through the instance metadata, credential vending path potentially allows you to get to the credentials level of service credit the Polaris itself. Depends on the depot: with ANSA in EKS or Workload Identity in GKE, the risk decreases.
Also Relevant Cloud Accounts (T1078.004): stolen temporary credentials are suitable for persistence scope - if it is wide enough, the attacker is fixed in the storage layer, creating backdoor objects or modifying the metadata files of existing tables.
Predictions and limitations credential vending attack in Apache Polaris
Works if:
• The attacking authenticated in Polaris REST API (CVSS vector: PR:L - low privileges, not anonymous access; TheHackerWire mistakenly indicate PR:N - according to the verified CVSS vector from CNA Apache Software Foundation is exactly PR:L)
• Polaris tuned to credential vending for staged tables
• IAM role Polaris has access to targeted storage path
• Targeted storage path "reachable" - Polaris scope can create a credentials for it through the IAM provider delegation mechanism
Does not work if:
• Polaris does not use credential vending (customers turn to storage directly with their own IAM credentials - a rare but possible mapping of the delo).
• VPC Service Controls (GCP) or S3 bucket policies restricts access via source VPC/IP - vend credentials is useless outside the target network
• IAM-role Polaris is limited to the only bucket of reach with a minimum (princile of responsibility in practice - rare, but sometimes)
• Apache Polaris has been updated to version 1.4.1+ (vulnerable package: org.apache.polaris
olaris-runtime-service, all versions from 0 to 1.4.1)
EPSS-context: According to FIRST.org as of July 13, 2026, the EPSS is 0.0036 (0.36%), percenteile 27.69% - below the median of all CVE. The probability of operation in the next 30 days is estimated as low. According to CISA-ADP, the operation in the wild is not recorded (exploitation: none), attack is not automated (automatable: no) The solution CISA: Track.
The low EPSS is due to product niches, not the complexity of the attack. For organizations that Polaris spinning in production, the actual risk is an order of magnitude higher than statistical. EPSS considers the CVE population - and here is one request and full access to the data lake.
In Russian, this vulnerability is devoted only to NVD cards and aggregators - there is no technical analysis. Shut down the gap.
Business logic: why credential vending in data lakehouse is dangerous
Apache Polaris - REST catalog for Apache Iceberg, open-source data organization format in data lakehouse. In production-deeplops, Polaris manages hundreds of tables scattered across S3 (WS), GCS (GCP) or Azure Blob Storage. Every time a client (Spark, Trino, Flink) refers to the table, Polaris can give him temporary credentials - short-lived STS tokens limited to a specific delay storage prefix.
This is credential vending: the directory works as an IAM broker between the user and the cloud storage. The user does not have direct IAM access to S3/GCS - he receives time keys through Polaris, and these keys are limited only to the storage path, where the files of a particular table are located.
Now we project on the threat model - and here the wider context that gives is important full map of the threat of cloud imconfiguration. The IAM role Polaris has access to dozens of cars with production data because it serves the entire catalog. If the attacker controls the scope of the detected entities issued, he gets access not to one table, but to any storage path within the IAM-role of the service. Financial data, PII clients, analytics, ML-models - everything that service Polaris reaches, is available through one HTTP request. For organizing terabytes of sensitive data in data lakehouse is a complete compromising data tier.
Mechanics CVE-2026-42809: how Apache Polaris gives out credentials without validation
The vulnerability sits in the stage-created flow - the mechanism of creating "black" tables in Iceberg REST Catalog. Stage-create is a two-phase operation: first, the table is created as a staged (draw), receives storage credentials to record the initial data, and only then is fixed through commit as a full-fledged table.
According to NVD, the root problem: Polaris gives out temporary credentials to Location Validation and to checks for intersection with other tables (overlap checks). Postponing in steps:
1. Attacking sends request to the stage-create with an arbitrary value location- let's say, s3://finance-production-bucket/reports/.
2. Polaris accepts this location as a target for credential scoping.
3. Polaris constructs delegate storage credentials (STS tokens) tied to the specified location.
4. Credentials return to the attacker before the stage-create path performs the cost price or overlap checks.
5. The attacker uses the received STS tokens for direct access to S3/GCS - through aws cli, boto3, gsutil.
According to NVD, the stage-created flow also takes properties write.data.path and write.metadata.path in the body of the request. This is a secondary vector: the fields are substituted in the effective table location set for credential vending and also do not validate before issuing credentials. From advisory: "those fields are secondary to the main custom-location exploit, but they are still attacker-inluenced cost-positives worth that be validated before any credentials are issued"“These fields are secondary to the main vulnerability associated with setting up the location, but they are still input-entered location data that an attacker can affect and should be checked before issuing any credentials.”.
Two CWEs - Two Aspects of Apache Polaris Vulture
According to the NVD (CNA: Apache Software Foundation), vulnerabilities are assigned two CWEs:
CWE-20 (IMproper Input Validation) - location, write.data.path and write.metadata.path are accepted from the user without checking for belonging to the permitted scope. According to the MITRE classification, the probability of operation is High. Consequences: reading and modifying data, potential DoS.
CWE-862 (Missing Authorization) - no authorization check for access to arbitrary storage path. Polaris checks the right to create a table, but not the right to receive credentials to a particular bakette. By MITRE: the probability of High, the consequences are reading and modifying data, increasing privileges.
The bundle is indicative: the problem is not only that the input is not filtered, but also in the absence of an authorization barrier between the “right to create a table” and “the right to get credentials to any tank within the IAM-role of the service”. Two different defects, one point of entry. Please note: the classic privilege escalation is not here. The attacker does not increase the privilege in Polaris - he uses the legitimate credential vending mechanism, substituting his location. The service voluntarily gives out the keys. By CISA-ADP Technical Impact - Total: complete compromising confidentiality, integrity and availability data tier.
A separate point of attention - Cloud Instantane Metadata API (T1552.005, Credential Access) If Polaris is deployed to EC2/GCE and receives IAM-credentials through the instance metadata, credential vending path potentially allows you to get to the credentials level of service credit the Polaris itself. Depends on the depot: with ANSA in EKS or Workload Identity in GKE, the risk decreases.
Also Relevant Cloud Accounts (T1078.004): stolen temporary credentials are suitable for persistence scope - if it is wide enough, the attacker is fixed in the storage layer, creating backdoor objects or modifying the metadata files of existing tables.
Predictions and limitations credential vending attack in Apache Polaris
Works if:
• The attacking authenticated in Polaris REST API (CVSS vector: PR:L - low privileges, not anonymous access; TheHackerWire mistakenly indicate PR:N - according to the verified CVSS vector from CNA Apache Software Foundation is exactly PR:L)
• Polaris tuned to credential vending for staged tables
• IAM role Polaris has access to targeted storage path
• Targeted storage path "reachable" - Polaris scope can create a credentials for it through the IAM provider delegation mechanism
Does not work if:
• Polaris does not use credential vending (customers turn to storage directly with their own IAM credentials - a rare but possible mapping of the delo).
• VPC Service Controls (GCP) or S3 bucket policies restricts access via source VPC/IP - vend credentials is useless outside the target network
• IAM-role Polaris is limited to the only bucket of reach with a minimum (princile of responsibility in practice - rare, but sometimes)
• Apache Polaris has been updated to version 1.4.1+ (vulnerable package: org.apache.polaris
olaris-runtime-service, all versions from 0 to 1.4.1) EPSS-context: According to FIRST.org as of July 13, 2026, the EPSS is 0.0036 (0.36%), percenteile 27.69% - below the median of all CVE. The probability of operation in the next 30 days is estimated as low. According to CISA-ADP, the operation in the wild is not recorded (exploitation: none), attack is not automated (automatable: no) The solution CISA: Track.
The low EPSS is due to product niches, not the complexity of the attack. For organizations that Polaris spinning in production, the actual risk is an order of magnitude higher than statistical. EPSS considers the CVE population - and here is one request and full access to the data lake.
