CVE-2026-42812

Apache Iceberg-də cədvəlin metadata faylları idarəetmə fayllarıdır: onlar oxuculara hansı məlumat fayllarının cədvələ aid olduğunu və cədvəlin hansı versiyasının oxunmalı olduğunu bildirir. `write.metadata.path` opsional bir cədvəl xüsusiyyətidir və Polaris-ə həmin metadata fayllarının hara yazılacağını bildirir. Polaris tərəfindən idarə olunan kataloqda artıq qeydiyyata alınmış cədvəl üçün yalnız bu xüsusiyyətin `ALTER TABLE` tipli parametrlər dəyişikliyi vasitəsilə dəyişdirilməsi (sətir səviyyəsində `INSERT`, `SELECT`, `UPDATE` və ya `DELETE` yox), saxlama yerlərini yenidən təsdiqləməli olan commit zamanı budaqdan (branch) yan keçir. Tam daimi / etibarnamə-təqdimat variantı üçün təsirə məruz qalan kataloqun `polaris.config.allow.unstructured.table.location=true` parametrinin olması və `allowedLocations` siyahısının hücum edən tərəf tərəfindən seçilmiş hədəfi əhatə edəcək qədər geniş olması tələb olunur. `allowedLocations` kataloqun istifadəsinə icazə verilən saxlama yollarının administrator tərəfindən konfiqurasiya edilmiş ağ siyahısıdır. İctimai layihə materialları göstərir ki, bu bayraq sadəcə laboratoriya şəraitindəki ön şərt deyil, real dəstəklənən uyğunluq / struktur rejimidir. Bu konfiqurasiyada, cədvəl parametrlərini dəyişə bilən istifadəçi, nəzərdə tutulmuş yer-doğrulama budağı işə düşməzdən əvvəl Apache Polaris-in özünün yeni cədvəl metadatasını hücum edən tərəfin seçdiyi əlçatan saxlama yerinə yazmasına səbəb ola bilər. Əgər sonrakı konkret yol doğrulaması da həmin yeri qəbul edərsə, Polaris nəticədə alınan metadata yolunu saxlanılan cədvəl vəziyyətinə daxil edir. Daha sonra cədvəlin yüklənməsi və etibarnamə API-ləri həmin yeri yenidən təsdiqləmədən eyni yer üçün müvəqqəti bulud saxlama etibarnamələri qaytara bilər. Sadə dillə desək, Polaris daha sonra hücum edən tərəfin seçdiyi eyni sahə üçün müvəqqəti saxlama girişini təqdim edə bilər. Hücum edən tərəfin seçdiyi bu sahə yalnız zəhərlənmiş cədvəlin öz faylları ilə məhdudlaşmamalıdır. Əgər bu, daha geniş saxlama prefiksi, başqa bir cədvəlin prefiksi və ya konfiqurasiyadan və ya provayder davranışından asılı olaraq hətta bucket/konteyner köküdürsə, nəticədə yaranan məlumat sızması və ya korlanma miqyası Polaris-in orada çatdığı hər hansı məlumata və metadataya genişlənə bilər. Buna görə də praktiki nəticələr artıq müzakirə edilmiş mərhələli-yaradılma etibarnamə-təqdimat problemi ilə oxşardır: həmin saxlama miqyasında əlçatan olan məlumatlar və metadatalar açıqlana bilər və gələcəkdə yazı imkanlı etibarnamələr verildikdə, dəyişdirilə, korlana və ya silinə bilər. Hətta həmin sonrakı etibarnamə mərhələsindən əvvəl, Polaris-in özü yoxlanılmayan yerə metadata yazma əməliyyatını yerinə yetirir. Beləliklə, əsas problem yalnız sonrakı etibarnamə təqdimatı deyil. Əsas qüsur ondan ibarətdir ki, yalnız `write.metadata.path` dəyişdikdə, Polaris təhlükəsizlik baxımından kritik olan metadata yazma əməliyyatını yerinə yetirməzdən əvvəl nəzərdə tutulmuş yer yoxlamalarını ötürür. `polaris.config.allow.unstructured.table.location=false` olduqda, mövcud kod analizi göstərir ki, sonrakı `updateTableLike(...)` doğrulaması adətən təhlükəsiz olmayan yol daimi edilməzdən əvvəl ağacdan kənar metadata yerlərini rədd edir. Bu, daimi / etibarnamə-təqdimat variantını azalda bilər, lakin altda yatan qüsuru aradan qaldırmır: yalnız `write.metadata.path` dəyişdikdə Polaris hələ də nəzərdə tutulmuş yazma-öncesi yer yoxlamasını ötürür.