Vulnerability-Lookup

PYSEC-2026-3623

Vulnerability from pysec - Published: 2026-08-06 09:16 - Updated: 2026-08-07 09:08

Details

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.

Severity

5.3 (Medium)


                  
                    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/S:N/U:Clear

Impacted products

Name	purl
apache-polaris	pkg:pypi/apache-polaris

Aliases

CVE-2026-64640

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {},
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-polaris",
        "purl": "pkg:pypi/apache-polaris"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.7.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.4.0",
        "1.5.0",
        "1.6.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-64640"
  ],
  "details": "Apache Polaris did not consistently validate storage locations supplied during table and view registration.\n\nAn 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\u0027s storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog\u0027s allowed storage locations.\n\nIf the catalog\u0027s underlying credentials could read an object outside\u00a0that boundary, this could disclose limited information from the object.\n\n\nPolaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary.\n\nThis second condition did not itself cause Polaris to read the\u00a0referenced external locations during registration.\n\n\nThe demonstrated impact is limited to confidentiality.\n\nNo unauthorized data\u00a0modification or availability impact has been demonstrated.\n\n\nThe server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog\u0027s underlying storage credentials can read.\n\nExploitation requires an authenticated principal with\u00a0table- or view-registration privileges.",
  "id": "PYSEC-2026-3623",
  "modified": "2026-08-07T09:08:00.236214Z",
  "published": "2026-08-06T09:16:36.797Z",
  "references": [
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2026/08/06/7"
    },
    {
      "type": "ADVISORY",
      "url": "https://lists.apache.org/thread/scd8p9wy8b9j3om5wohbotpfycnmmjl4"
    }
  ],
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ]
}

CVE-2026-64640 (GCVE-0-2026-64640)

Vulnerability from cvelistv5 – Published: 2026-08-06 09:08 – Updated: 2026-08-06 21:56

Title

Apache Polaris: register endpoint reads attacker-controlled storage location before allowed-locations validation

Summary

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.

Severity

5.3 (Medium)


                        
                          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/S:N/U:Clear

6.5 (Medium)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

SSVC

Exploitation: none Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-08-06 15:12 UTC

CWE

CWE-863 - Incorrect Authorization

Assigner

apache CNA under the mitre root

CNA scorecard B 76/100 over 1276 records in the last 180 days details

References

2 references

URL	Tags
https://lists.apache.org/thread/scd8p9wy8b9j3om5w…	vendor-advisory
http://www.openwall.com/lists/oss-security/2026/08/06/7

Impacted products

1 product

Vendor	Product	Version
Apache Software Foundation	Apache Polaris	Affected: 0 , ≤ 1.6.0 (semver)

Credits

Andrea Cosentino

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "cvssV3_1": {
              "attackComplexity": "LOW",
              "attackVector": "NETWORK",
              "availabilityImpact": "NONE",
              "baseScore": 6.5,
              "baseSeverity": "MEDIUM",
              "confidentialityImpact": "HIGH",
              "integrityImpact": "NONE",
              "privilegesRequired": "LOW",
              "scope": "UNCHANGED",
              "userInteraction": "NONE",
              "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
              "version": "3.1"
            }
          },
          {
            "other": {
              "content": {
                "id": "CVE-2026-64640",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-06T15:12:23.821798Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-06T15:13:04.986Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      },
      {
        "providerMetadata": {
          "dateUpdated": "2026-08-06T21:56:16.978Z",
          "orgId": "af854a3a-2127-422b-91ae-364da2661108",
          "shortName": "CVE"
        },
        "references": [
          {
            "url": "http://www.openwall.com/lists/oss-security/2026/08/06/7"
          }
        ],
        "title": "CVE Program Container"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageName": "org.apache.polaris:polaris-runtime-service",
          "product": "Apache Polaris",
          "vendor": "Apache Software Foundation",
          "versions": [
            {
              "lessThanOrEqual": "1.6.0",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Andrea Cosentino"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "supportingMedia": [
            {
              "base64": false,
              "type": "text/html",
              "value": "Apache Polaris did not consistently validate storage locations supplied during table and view registration.\u003cbr\u003e\u003cbr\u003e\u003cdiv\u003eAn 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\u0027s storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog\u0027s allowed storage locations.\u003c/div\u003e\u003cdiv\u003eIf the catalog\u0027s underlying credentials could read an object outside\u0026nbsp;that boundary, this could disclose limited information from the object.\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003ePolaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary.\u003c/div\u003e\u003cdiv\u003eThis second condition did not itself cause Polaris to read the\u0026nbsp;referenced external locations during registration.\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eThe demonstrated impact is limited to confidentiality.\u003c/div\u003e\u003cdiv\u003eNo unauthorized data\u0026nbsp;modification or availability impact has been demonstrated.\u003c/div\u003e\u003cbr\u003e\u003cdiv\u003eThe server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog\u0027s underlying storage credentials can read.\u003c/div\u003e\u003cdiv\u003eExploitation requires an authenticated principal with\u0026nbsp;table- or view-registration privileges.\u003c/div\u003e"
            }
          ],
          "value": "Apache Polaris did not consistently validate storage locations supplied during table and view registration.\n\nAn 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\u0027s storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog\u0027s allowed storage locations.\n\nIf the catalog\u0027s underlying credentials could read an object outside\u00a0that boundary, this could disclose limited information from the object.\n\n\nPolaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary.\n\nThis second condition did not itself cause Polaris to read the\u00a0referenced external locations during registration.\n\n\nThe demonstrated impact is limited to confidentiality.\n\nNo unauthorized data\u00a0modification or availability impact has been demonstrated.\n\n\nThe server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog\u0027s underlying storage credentials can read.\n\nExploitation requires an authenticated principal with\u00a0table- or view-registration privileges."
        }
      ],
      "metrics": [
        {
          "other": {
            "content": {
              "text": "low"
            },
            "type": "Textual description of severity"
          }
        },
        {
          "cvssV4_0": {
            "Automatable": "NOT_DEFINED",
            "Recovery": "NOT_DEFINED",
            "Safety": "NEGLIGIBLE",
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 5.3,
            "baseSeverity": "MEDIUM",
            "privilegesRequired": "LOW",
            "providerUrgency": "CLEAR",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "valueDensity": "NOT_DEFINED",
            "vectorString": "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/S:N/U:Clear",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "LOW",
            "vulnIntegrityImpact": "NONE",
            "vulnerabilityResponseEffort": "NOT_DEFINED"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "GENERAL"
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-863",
              "description": "CWE-863 Incorrect Authorization",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-06T09:08:06.534Z",
        "orgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
        "shortName": "apache"
      },
      "references": [
        {
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://lists.apache.org/thread/scd8p9wy8b9j3om5wohbotpfycnmmjl4"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "Apache Polaris: register endpoint reads attacker-controlled storage location before allowed-locations validation",
      "x_generator": {
        "engine": "Vulnogram 0.2.0"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f0158376-9dc2-43b6-827c-5f631a4d8d09",
    "assignerShortName": "apache",
    "cveId": "CVE-2026-64640",
    "datePublished": "2026-08-06T09:08:06.534Z",
    "dateReserved": "2026-07-20T16:49:22.785Z",
    "dateUpdated": "2026-08-06T21:56:16.978Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted