CVE-2026-64640 — Apache Polaris: register में लोकेशन सत्यापन से पहले क्रेडेंशियल वितरण

CVE-2026-64640 के लिए एक स्व-निहित, एक-कमांड रीप्रोड्यूसर: Apache Polaris में Iceberg REST register एंडपॉइंट, कॉलर द्वारा दिए गए पाथ के लिए क्लाउड स्टोरेज क्रेडेंशियल जारी करते हैं और उस पाथ को कैटलॉग की allowedLocations के विरुद्ध जाँचने से पहले सर्वर-साइड पढ़ लेते हैं।

एक प्रिंसिपल जिसका एकमात्र विशेषाधिकार अपने स्वयं के कैटलॉग में टेबल बनाना है, वह Polaris को कैटलॉग के स्टोरेज क्रेडेंशियल्स का उपयोग करके उन ऑब्जेक्ट्स को पढ़ने के लिए मजबूर कर सकता है जिन्हें छूने की अनुमति कैटलॉग को कभी नहीं थी — किसी अन्य टेनेंट का प्रीफिक्स, कोई अन्य बकेट, वह सब कुछ जिस तक स्टोरेज प्रिंसिपल पहुँच सकता है।

CVE	CVE-2026-64640
घटक	polaris-runtime-service — IcebergCatalog / LocalIcebergCatalog: registerTable, registerView
एंडपॉइंट्स	POST /api/catalog/v1/{prefix}/namespaces/{namespace}/register POST /api/catalog/v1/{prefix}/namespaces/{namespace}/register-view (1.6.0+)
CWE	CWE-441 (confused deputy), CWE-639 (authorization bypass through user-controlled key), CWE-918 (SSRF)
गंभीरता	उच्च — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N (8.1)
प्रभावित	≤ 1.6.0 (1.3.0-incubating, 1.4.0, 1.4.1, 1.5.0, 1.6.0 पर सत्यापित)
फिक्स किया गया	1.7.0 — 1.6.0 केवल टेबल पाथ को ठीक करता है और नए व्यू पाथ पर त्रुटि को पुनः प्रस्तुत करता है
आवश्यक विशेषाधिकार	किसी भी कैटलॉग पर TABLE_CREATE / CATALOG_MANAGE_CONTENT वाला एक प्रमाणित प्रिंसिपल — कोई एडमिन नहीं

1.6.0 कोई फिक्स नहीं है। यह register को ठीक करता है (संयोगवश, एक फीचर PR के भीतर) और बिल्कुल नए register-view एंडपॉइंट को उसी क्रम-त्रुटि के साथ जारी करता है। रीप्रोड्यूसर दोनों हिस्सों को सिद्ध करता है। 1.7.0 पर अपग्रेड करें।

इसे चलाएँ

आवश्यकताएँ: Compose v2 प्लगइन के साथ Docker, curl, python3, bash। और कुछ नहीं — पर्यावरण प्रकाशित इमेजेस से बनाया जाता है और बाद में हटा दिया जाता है।

./exploit.sh                 # default: apache/polaris:1.4.1  -> reproduces via register
./exploit.sh --tag 1.6.0     # partially fixed               -> reproduces via register-view
./exploit.sh --tag 1.7.0     # comprehensively fixed         -> refuses cleanly on both
./scripts/version-matrix.sh  # every release, side by side

एग्ज़िट कोड 0 का अर्थ है भेद्यता दोहराई गई, 1 का अर्थ है नहीं दोहराई गई, 2 का अर्थ है पर्यावरण शुरू नहीं हो सका। हर अनुरोध और प्रतिक्रिया evidence/<timestamp>-polaris-<tag>/ में लिखी जाती है।

पर्यावरण कैसा दिखता है

  catalog  tenant_a_catalog        allowedLocations = [ s3://bucket123 ]
  actor    low_priv_user           CATALOG_MANAGE_CONTENT on that catalog, nothing else
  target   s3://tenant-b-private   another tenant's bucket:
                                     no allowedLocations entry, no grant, no relation
                                     to the attacker's catalog — but reachable by the
                                     credentials that back it

वह अंतिम पंक्ति यथार्थवादी हिस्सा है। ऑपरेटर कैटलॉग को allowedLocations से सीमित करते हैं; नीचे की IAM भूमिका लगभग हमेशा एक प्रीफिक्स से व्यापक होती है। allowedLocations ही दीवार है। यह बग उसे बायपास कर देता है।

यह क्या सिद्ध करता है

टेस्ट 0 — दीवार वास्तविक है। s3://tenant-b-private में स्पष्ट लोकेशन के साथ टेबल बनाना, कुछ भी पढ़े जाने से पहले 403 ForbiddenException के साथ अस्वीकार कर दिया जाता है। Polaris भली-भाँति जानता है कि लोकेशन सीमा से बाहर है।

टेस्ट 1 — register फिर भी उसे पढ़ लेता है। वही प्रिंसिपल register को s3://tenant-b-private/sales/metadata/00007-tenant-b-sales.metadata.json पर इंगित करता है। प्रतिक्रिया भी 403 है — लेकिन वह s3://tenant-b-private/warehouse/CANARY-64640-4f1c9e2a-tenant-b-sales को उद्धृत करती है, एक स्ट्रिंग जो केवल उस ऑब्जेक्ट के बॉडी के भीतर मौजूद है:

{"error":{"message":"Invalid locations '[s3://tenant-b-private/warehouse/sales/data,
s3://tenant-b-private/warehouse/CANARY-64640-4f1c9e2a-tenant-b-sales]' for identifier
'tenant_a_ns.pwn_canary': s3://tenant-b-private/warehouse/sales/data is not in the list
of allowed locations: [s3://bucket123/tenant_a_ns]","type":"ForbiddenException","code":403}}

अनुरोध warehouse/ का कभी उल्लेख नहीं करता। Polaris उन स्ट्रिंग्स को केवल कैटलॉग के क्रेडेंशियल्स के साथ ऑब्जेक्ट को लाकर और पार्स करके ही उत्पन्न कर सकता था। 403 Polaris द्वारा उस रीड के एक कदम बाद उल्लंघन को पकड़ना है, जिसे उसे रोकना था।

टेस्ट 2 — क्या वापस मिलता है। पीड़ित दस्तावेज़ से पार्स किए गए दो अलग-अलग फ़ील्ड कॉलर को प्रतिध्वनित किए जाते हैं: टेबल की घोषित location और उसकी write.data.path प्रॉपर्टी।

टेस्ट 3 — एक स्टोरेज एन्यूमरेशन ओरेकल। allowedLocations के बाहर के लक्ष्य की हर अवस्था के लिए वही कॉल अलग-अलग उत्तर देती है:

प्रोब (सभी allowedLocations के बाहर)	1.4.1 प्रतिक्रिया
मान्य Iceberg मेटाडेटा, मौजूद है	403 ForbiddenException + पार्स की गई लोकेशन्स प्रतिध्वनित
कुंजी अनुपस्थित	400 NotFoundException — Location does not exist: …
बकेट मौजूद नहीं है	400 NoSuchBucketException — कच्ची S3 SDK त्रुटि
मौजूद है परंतु Iceberg मेटाडेटा नहीं है	503 RuntimeIOException — Failed to read file: …

चार विभेद्य उत्तरों का अर्थ है स्टोरेज के बारे में चार ऐसे तथ्य जिन्हें सीखने का कॉलर को कोई अधिकार नहीं है। वास्तविक AWS पर बकेट-अस्तित्व प्रोब कैटलॉग के क्रेडेंशियल्स का उपयोग करके वैश्विक S3 बकेट नेमस्पेस तक पहुँचती है।

फिक्स्ड बिल्ड पर उस तालिका की हर पंक्ति वही 403 होती है जो केवल अनुरोधित पाथ का नाम लेती है, और ऑब्जेक्ट के अंदर से कुछ भी वापस नहीं आता — स्क्रिप्ट उस हस्ताक्षर का पता लगाती है और NOT VULNERABLE — pre-validation observed रिपोर्ट करती है।

टेस्ट 4 — register-view पर वही त्रुटि। Polaris 1.6.0 ने POST .../namespaces/{ns}/register-view जोड़ा, जो registerView तक पहुँचता है, जो बिना किसी पूर्व सत्यापन के FileIO लोड करता है और कॉलर के दस्तावेज़ को पार्स करता है — ठीक वही जो registerTable ने अभी-अभी करना बंद किया था। 1.6.0 पर व्यू कैनरी यह लौटाती है:

{"error":{"message":"Invalid locations '[s3://tenant-b-private/warehouse/CANARY-64640-VIEW-8d3b7a15-tenant-b]'
for identifier 'tenant_a_ns.pwn_view': … is not in the list of allowed locations:
[s3://bucket123/tenant_a_ns]","type":"ForbiddenException","code":403}}

अतः 1.6.0 परिनियोजन अभी भी एक अलग एंडपॉइंट के माध्यम से उसी प्रिमिटिव के संपर्क में है। 1.4.1 और पुराने पर एंडपॉइंट मौजूद नहीं है और स्क्रिप्ट यही बताती है।

मूल कारण

IcebergCatalog.registerTable (1.6.0 से LocalIcebergCatalog), फिक्स से पहले — registerView की संरचना समान है:

String locationDir = metadataFileLocation.substring(0, lastSlashIndex);   // attacker-controlled
...
FileIO fileIO =
    loadFileIOForTableLike(
        identifier,
        Set.of(locationDir),                                              // credentials minted here
        resolvedParent,
        new HashMap<>(tableDefaultProperties),
        Set.of(PolarisStorageActions.READ, PolarisStorageActions.LIST));

InputFile metadataFile = fileIO.newInputFile(metadataFileLocation);       // server-side GET
TableMetadata metadata = TableMetadataParser.read(metadataFile);          // server-side parse
ops.commit(null, metadata);                                               // allowedLocations checked HERE

वितरण श्रृंखला (loadFileIOForTableLike → StorageAccessConfigProvider.getStorageAccessConfig → *StorageIntegration.getSubscopedCreds) अपनी ओर से कोई allowedLocations जाँच नहीं करती, इसलिए एकमात्र प्रवर्तन कमिट-समय वाला है — और तब तक विशेषाधिकार प्राप्त रीड हो चुकी होती है और उसका परिणाम प्रतिक्रिया में होता है।

उसी फ़ाइल में सहयोगी पाथ सही क्रम रखते हैं: व्यू निर्माण और sendNotificationForTableLike दोनों FileIO लोड करने से पहले सत्यापन करते हैं। registerTable ही असंगत था। पूरी विस्तृत समीक्षा docs/ANALYSIS.md में।

फिक्स, दो भागों में