Live › vulnerability › CVE-2026-112048
Go to dashboardlibspatialite through 5.1.0 does not validate the ring count when parsing WKB polygons, so a crafted geometry BLOB triggers uncontrolled interior-ring allocation. An attacker who supplies such a polygon to a SpatiaLite database or ST_GeomFromWKB can crash the process or corrupt heap memory on 32-bit builds.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Applications that load SpatiaLite databases or parse WKB geometry from untrusted sources are exposed, and the memory corruption described is stated for 32-bit builds. Systems using libspatialite only on trusted local data, or without accepting external geometry, are less exposed. The sources do not state which 64-bit builds are affected.
No product ranges from the sources yet.
spatialite --version or check the installed libspatialite version in your package manager, and compare it to 5.1.0.5.1.0 to a release that contains the fix (unknown exact version in sources).Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
libspatialite through 5.1.0 fails to validate the polygon ring count in ParseWkbPolygon, allowing attackers to trigger uncontrolled interior-ring allocation via crafted geometry BLOBs. Attackers can supply a crafted polygon in a SpatiaLite database or ST_GeomFromWKB input to crash the process or corrupt heap memory on 32-bit builds.
This page as .md · .json · in your agent: get_signal("CVE-2026-112048")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.