OSGeo GDAL EUVD-2026-28435

Exploitation requires three specific conditions: (1) GDAL compiled and linked with HDF4 support enabled (non-default in some distributions); (2) Local file system access or ability to place/influence HDF4 files processed by GDAL; (3) An authenticated local user context (PR:L per CVSS vector) - the application processing the HDF4 file must execute with at least local user privileges. The vulnerability is triggered when GDAL processes HDF4 files with malformed DataFieldName entries, specifically those lacking proper quote delimiters that trigger the incorrect string length subtraction. The attack does not require user interaction (UI:N) beyond normal file processing. Non-default configurations (HDF4 driver disabled) and systems that do not process HDF4 files are not vulnerable.

CVSS score of 5.3 with vector AV:L/AC:L/PR:L indicates local-only access with low attack complexity and low privilege requirements, resulting in moderate impact (confidentiality, integrity, availability). However, the E:P (Exploit code Proof-of-Concept) rating and publicly available exploit code significantly elevate real-world risk. The EPSS score data is not provided, limiting probabilistic exploitation assessment, but the combination of accessible exploit code and straightforward attack prerequisites (local file opening with crafted HDF4 data) suggests reasonable exploitability in environments where GDAL processes untrusted HDF4 files. The primary limiting factor is the requirement for local access and authenticated context (PR:L), which restricts this to scenarios where attackers can either place malicious files on the system or interact with a GDAL processing pipeline. In server-side or automated geospatial data processing scenarios where GDAL processes user-supplied HDF4 files, this becomes a higher-impact issue despite the moderate CVSS score.

An attacker with local system access creates a malicious HDF4 file (issue_14363.he4) with a specially crafted DataFieldName parameter that lacks proper quote delimiters. When a GDAL application or script processes this file by calling GDnentries or opening the file with gdal.Open(), the vulnerable string length calculation allocates insufficient heap buffer space. Subsequent string operations write beyond the allocated buffer, corrupting heap metadata. With local code execution privileges and careful heap manipulation, this could potentially lead to information disclosure or privilege escalation, though arbitrary code execution is not guaranteed due to modern heap protections. Publicly available proof-of-concept code exists at https://github.com/biniamf/pocs/tree/main/gdal-gdinqfields_bof.