libspatialite EUVD-2026-103510

Exploitation requires the target application to parse an attacker-controlled geometry BLOB through ParseWkbPolygon - specifically by opening a malicious SpatiaLite database or by passing crafted WKB to the ST_GeomFromWKB function. The crafted polygon declares an interior-ring count that is not validated against the actual BLOB contents. Limiting factors: the CVSS vector is local (AV:L) and requires passive user interaction (UI:P), meaning a victim must load the malicious data; memory corruption beyond a crash is restricted to 32-bit builds, while 64-bit builds are expected to only experience a denial-of-service crash. Impact is confined to applications that expose SpatiaLite geometry parsing to untrusted input.

This is a moderate-priority issue, not a top-tier emergency. The CVSS 4.0 base score of 6.9 (Medium) is driven by a local attack vector (AV:L) requiring passive user interaction (UI:P) - the victim must load a malicious SpatiaLite database or feed attacker-controlled WKB into ST_GeomFromWKB. The dominant impact is availability (VA:H, process crash/DoS) with only low integrity impact (VI:L) and no confidentiality impact (VC:N), consistent with CWE-789 (memory allocation with excessive/uncontrolled size). No EPSS score was provided, there is no CISA KEV listing, and no confirmed public exploit code - the hackmd reference is a technical write-up, not verified weaponized PoC. A key nuance: the description uses the word 'attackers' and mentions input via ST_GeomFromWKB, which could suggest a remote data path, but the authoritative CVSS vector is AV:L, so exploitation depends on the application processing attacker-supplied geometry locally - verify the actual data-exposure path in your deployment. Heap corruption (and thus any memory-safety escalation beyond DoS) is explicitly limited to 32-bit builds; on 64-bit builds the realistic outcome is a crash. Net: real and worth patching, but closer to a reliability/DoS concern than a mass-exploitation RCE threat.

An attacker crafts a polygon geometry BLOB with a declared interior-ring count far exceeding what the data actually contains, then distributes it as a malicious SpatiaLite database file or submits it as WKB to an application exposing ST_GeomFromWKB. When the victim application parses the geometry via ParseWkbPolygon, the unvalidated ring count drives an uncontrolled allocation, crashing the process or corrupting the heap on 32-bit builds. No confirmed public exploit code exists, though a technical write-up describing the flaw is published.