CVE-2026-42812
Full vulnerability record from the local CVENow database.
Description
In Apache Iceberg, the table's metadata files are control files: they tell readers which data files belong to the table and which table version to read. `write.metadata.path` is an optional table property that tells Polaris where to write those metadata files. For a table already registered in a Polaris-managed catalog, changing only that property through an `ALTER TABLE`-style settings change (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses the commit-time branch that is supposed to revalidate storage locations. The full persisted / credential-vending variant requires the affected catalog to have `polaris.config.allow.unstructured.table.location=true`, with `allowedLocations` broad enough to include the attacker-chosen target. `allowedLocations` is the admin-configured allowlist of storage paths that the catalog is allowed to use. Public project materials suggest that this flag is a real supported compatibility / layout mode, not just a contrived lab-only prerequisite. In that configuration, a user who can change table settings can cause Apache Polaris itself to write new table metadata to an attacker-chosen reachable storage location before the intended location-validation branch runs. If the later concrete-path validation also accepts that location, Polaris persists the resulting metadata path into stored table state. Later table-load and credential APIs can then return temporary cloud-storage credentials for the same location without revalidating it. In plain terms, Polaris can later hand out temporary storage access for the same attacker-chosen area. That attacker-chosen area does not need to be limited to the poisoned table's own files. If it is a broader storage prefix, another table's prefix, or, depending on configuration or provider behavior, even a bucket/container root, the resulting disclosure or corruption scope can extend to any data and metadata Polaris can reach there. The practical consequences are therefore similar to the staged-create credential-vending issue already discussed: data and metadata reachable in that storage scope can be exposed and, if write-capable credentials are later issued, modified, corrupted, or removed. Even before that later credential step, Polaris itself performs the metadata write to the unchecked location. So the core issue is not only later credential vending. The primary defect is that Polaris skips its intended location checks before performing a security- sensitive metadata write when only `write.metadata.path` changes. When `polaris.config.allow.unstructured.table.location=false`, current code review suggests the later `updateTableLike(...)` validation usually rejects out-of-tree metadata locations before the unsafe path is persisted. That may reduce the persisted / credential-vending variant, but it does not prevent the underlying defect: Polaris still skips the intended pre-write location check when only `write.metadata.path` changes.
View original CVE JSON
{
"id": "CVE-2026-42812",
"sourceIdentifier": "[email protected]",
"published": "2026-05-04T17:16:26.887",
"lastModified": "2026-10-26T19:10:00.163",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "In Apache Iceberg, the table's metadata files are control files: they tell readers\nwhich data files belong to the table and which table version to read.\n\n\n\n`write.metadata.path` is an optional table property that tells Polaris\nwhere to\nwrite those metadata files. \nFor a table already registered in a\nPolaris-managed\ncatalog, changing only that property through an `ALTER TABLE`-style settings\nchange (not a row-level `INSERT`, `SELECT`, `UPDATE`, or `DELETE`) bypasses\nthe commit-time branch that is supposed to revalidate storage locations.\n\nThe full persisted / credential-vending variant requires the affected\ncatalog\nto have `polaris.config.allow.unstructured.table.location=true`, with\n`allowedLocations` broad enough to include the attacker-chosen target.\n\n\n`allowedLocations` is the admin-configured allowlist of storage paths that\nthe\ncatalog is allowed to use. Public project materials suggest that this flag\nis a\nreal supported compatibility / layout mode, not just a contrived lab-only\nprerequisite.\n\n\nIn that configuration, a user who can change table settings can cause Apache Polaris\nitself to write new table metadata to an attacker-chosen reachable storage\nlocation before the intended location-validation branch runs.\n\nIf the later concrete-path validation also accepts that location, Polaris\npersists the resulting metadata path into stored table state. Later\ntable-load\nand credential APIs can then return temporary cloud-storage credentials for\nthe\nsame location without revalidating it. In plain terms, Polaris can later\nhand\nout temporary storage access for the same attacker-chosen area.\n\nThat attacker-chosen area does not need to be limited to the poisoned\ntable's\nown files. If it is a broader storage prefix, another table's prefix, or,\ndepending on configuration or provider behavior, even a bucket/container\nroot,\nthe resulting disclosure or corruption scope can extend to any data and\nmetadata Polaris can reach there.\n\n\n\nThe practical consequences are therefore similar to the staged-create\ncredential-vending issue already discussed: data and metadata reachable in\nthat\nstorage scope can be exposed and, if write-capable credentials are later\nissued, modified, corrupted, or removed. Even before that later credential\nstep, Polaris itself performs the metadata write to the unchecked location.\n\nSo the core issue is not only later credential vending. \n\nThe primary defect\nis\nthat Polaris skips its intended location checks before performing a\nsecurity-\nsensitive metadata write when only `write.metadata.path` changes.\n\n\n\nWhen `polaris.config.allow.unstructured.table.location=false`, current code\nreview suggests the later `updateTableLike(...)` validation usually rejects\nout-of-tree metadata locations before the unsafe path is persisted. That may\nreduce the persisted / credential-vending variant, but it does not prevent\nthe\nunderlying defect: Polaris still skips the intended pre-write location check\nwhen only `write.metadata.path` changes."
},
{
"lang": "es",
"value": "En Apache Iceberg, los archivos de metadatos de la tabla son archivos de control: le dicen a los lectores qué archivos de datos pertenecen a la tabla y qué versión de la tabla leer.\n\n’write.metadata.path’ es una propiedad de tabla opcional que le dice a Polaris dónde escribir esos archivos de metadatos. Para una tabla ya registrada en un catálogo gestionado por Polaris, cambiar solo esa propiedad a través de un cambio de configuración al estilo ’ALTER TABLE’ (no un ’INSERT’, ’SELECT’, ’UPDATE’ o ’DELETE’ a nivel de fila) omite la rama de tiempo de confirmación que se supone que revalida las ubicaciones de almacenamiento.\n\nLa variante completa persistida / de emisión de credenciales requiere que el catálogo afectado tenga ’polaris.config.allow.unstructured.table.location=true’, con ’allowedLocations’ lo suficientemente amplio como para incluir el objetivo elegido por el atacante.\n\n’allowedLocations’ es la lista de permitidos configurada por el administrador de rutas de almacenamiento que el catálogo tiene permitido usar. Los materiales de proyectos públicos sugieren que esta bandera es un modo de compatibilidad / diseño real y soportado, no solo un prerrequisito artificial solo para laboratorio.\n\nEn esa configuración, un usuario que puede cambiar la configuración de la tabla puede hacer que el propio Apache Polaris escriba nuevos metadatos de la tabla en una ubicación de almacenamiento alcanzable elegida por el atacante antes de que se ejecute la rama de validación de ubicación prevista.\n\nSi la validación posterior de la ruta concreta también acepta esa ubicación, Polaris persiste la ruta de metadatos resultante en el estado de tabla almacenado. Las API posteriores de carga de tablas y credenciales pueden entonces devolver credenciales temporales de almacenamiento en la nube para la misma ubicación sin revalidarla. En términos sencillos, Polaris puede más tarde entregar acceso temporal al almacenamiento para la misma área elegida por el atacante.\n\nEsa área elegida por el atacante no necesita limitarse a los propios archivos de la tabla envenenada. Si es un prefijo de almacenamiento más amplio, el prefijo de otra tabla, o, dependiendo de la configuración o el comportamiento del proveedor, incluso una raíz de bucket/contenedor, el alcance de divulgación o corrupción resultante puede extenderse a cualquier dato y metadato que Polaris pueda alcanzar allí.\n\nLas consecuencias prácticas son, por lo tanto, similares al problema de emisión de credenciales de creación por etapas ya discutido: los datos y metadatos alcanzables en ese alcance de almacenamiento pueden ser expuestos y, si se emiten credenciales con capacidad de escritura más tarde, modificados, corrompidos o eliminados. Incluso antes de ese paso posterior de credenciales, el propio Polaris realiza la escritura de metadatos a la ubicación no verificada.\n\nAsí que el problema central no es solo la emisión posterior de credenciales. El defecto principal es que Polaris omite sus comprobaciones de ubicación previstas antes de realizar una escritura de metadatos sensible a la seguridad cuando solo cambia ’write.metadata.path’.\n\nCuando ’polaris.config.allow.unstructured.table.location=false’, la revisión de código actual sugiere que la validación posterior de ’updateTableLike(...)’ usualmente rechaza ubicaciones de metadatos fuera del árbol antes de que la ruta insegura sea persistida. Eso puede reducir la variante persistida / de emisión de credenciales, pero no previene el defecto subyacente: Polaris aún omite la comprobación de ubicación previa a la escritura prevista cuando solo cambia ’write.metadata.path’."
}
],
"affected": [
{
"source": "[email protected]",
"affectedData": [
{
"vendor": "Apache Software Foundation",
"product": "Apache Polaris",
"defaultStatus": "unaffected",
"versions": [
{
"version": "0",
"lessThan": "1.4.1",
"versionType": "semver",
"status": "affected"
}
]
}
]
}
],
"metrics": {
"cvssMetricV40": [
{
"source": "[email protected]",
"type": "Secondary",
"cvssData": {
"version": "4.0",
"vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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:X/AU:X/R:X/V:X/RE:X/U:X",
"baseScore": 9.4,
"baseSeverity": "CRITICAL",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"attackRequirements": "NONE",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"vulnConfidentialityImpact": "HIGH",
"vulnIntegrityImpact": "HIGH",
"vulnAvailabilityImpact": "HIGH",
"subConfidentialityImpact": "HIGH",
"subIntegrityImpact": "HIGH",
"subAvailabilityImpact": "HIGH",
"exploitMaturity": "NOT_DEFINED",
"confidentialityRequirement": "NOT_DEFINED",
"integrityRequirement": "NOT_DEFINED",
"availabilityRequirement": "NOT_DEFINED",
"modifiedAttackVector": "NOT_DEFINED",
"modifiedAttackComplexity": "NOT_DEFINED",
"modifiedAttackRequirements": "NOT_DEFINED",
"modifiedPrivilegesRequired": "NOT_DEFINED",
"modifiedUserInteraction": "NOT_DEFINED",
"modifiedVulnConfidentialityImpact": "NOT_DEFINED",
"modifiedVulnIntegrityImpact": "NOT_DEFINED",
"modifiedVulnAvailabilityImpact": "NOT_DEFINED",
"modifiedSubConfidentialityImpact": "NOT_DEFINED",
"modifiedSubIntegrityImpact": "NOT_DEFINED",
"modifiedSubAvailabilityImpact": "NOT_DEFINED",
"Safety": "NOT_DEFINED",
"Automatable": "NOT_DEFINED",
"Recovery": "NOT_DEFINED",
"valueDensity": "NOT_DEFINED",
"vulnerabilityResponseEffort": "NOT_DEFINED",
"providerUrgency": "NOT_DEFINED"
}
}
],
"cvssMetricV31": [
{
"source": "[email protected]",
"type": "Secondary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"baseScore": 9.9,
"baseSeverity": "CRITICAL",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "NONE",
"scope": "CHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 3.1,
"impactScore": 6.0
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2026-05-04T16:31:28.354079Z",
"id": "CVE-2026-42812",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"version": "2.0.3"
}
}
]
},
"weaknesses": [
{
"source": "[email protected]",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-20"
},
{
"lang": "en",
"value": "CWE-284"
},
{
"lang": "en",
"value": "CWE-732"
},
{
"lang": "en",
"value": "CWE-863"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:apache:polaris:*:*:*:*:*:*:*:*",
"versionEndExcluding": "1.4.1",
"matchCriteriaId": "D5093587-E178-48D3-A30B-04433BC6D047"
}
]
}
]
}
],
"references": [
{
"url": "https://lists.apache.org/thread/wxd2wj3p0smvrk84msv317wg5tp3jtw9",
"source": "[email protected]",
"tags": [
"Mailing List",
"Vendor Advisory"
]
},
{
"url": "http://www.openwall.com/lists/oss-security/2026/05/02/13",
"source": "af854a3a-2127-422b-91ae-364da2661108",
"tags": [
"Mailing List",
"Third Party Advisory"
]
}
]
}