CVE-2026-4738: Verify GDAL’s Bundled zlib Correction

CVE-2026-4738 concerns code bundled inside GDAL at frmts/zlib/contrib/infback9/inftree9.c. The CNA record identifies GDAL before 3.11.0 as affected and describes a memory-bounds issue. The correction task belongs to the GDAL build and the application consuming it. An updated operating-system zlib package alone does not prove this bundled source was replaced.

What the official patch actually changes

En official GDAL pull request 12244 removes an offset-pointer optimization in the bundled table-building code. In the old LENS branch, base y extra were moved back by 257 before symbols were used as indexes. The patch keeps the pointers at the tables and explicitly subtracts the matching threshold from the symbol index. It also changes the threshold variable from signed end to unsigned match.

/* Simplified excerpt of the official source change */
/* Before: pointer moved before the table */
base = lbase;
base -= 257;
/* Later: base[work[sym]] */

/* After: pointer remains at the table */
base = lbase;
match = 257;
/* Later: base[work[sym] - match] */

The same explicit-index approach applies to the extra-bit table. The final revision casts work[sym] to unsigned in the comparison (unsigned)(work[sym]) + 1 < match. Those are observable source changes. They do not, by themselves, demonstrate a working exploit, identify a universal malicious raster format or establish reachability in a specific GIS service.

Find the copy the application uses

Begin with the application’s packaging path: supplier desktop bundle, system package, Python environment, container or internally compiled GDAL. A workstation can contain more than one GDAL installation. The version printed by a shell executable is evidence about that executable, not automatically about a desktop application or a worker running in another environment.

For example, updating the host package while a conversion worker still runs an older container leaves two different software states. Record the image digest and package evidence from the worker’s actual execution environment. If a desktop supplier ships GDAL privately, use that supplier’s release or patch evidence rather than replacing a DLL outside its supported update mechanism.

Verify a backport without guessing from the version string

A vendor can retain an older upstream version while backporting a correction. Request a package advisory or source revision linking the shipped artifact to this CVE or the official patch. For a source build, review the relevant file and the complete change, including the final comparison adjustment. A local text match is a clue; build provenance is what connects that source to the binary.

Preserve the source revision or supplier advisory, build identifier, artifact hash or image digest, deployment time and observed consumer. Rebuild and redeploy the consuming application when required by its packaging model. Check long-running workers and restart them through the supported process. Update build caches and recovery artifacts that could reintroduce an older library.

Use benign regression data and state the limits

Test normal supported import or conversion workflows in an owned environment after the correction. Record the GDAL build used, representative non-malicious input, expected output and resource behavior. This checks that the update has not broken the business task. It does not prove memory safety for all input or reproduce the vulnerability.

The CNA supplies a CVSS v4.0 score of 9.4 and a vector containing E:A. Attribute that assessment to the CNA. This review did not independently reproduce exploitation or establish an incident campaign. The CISA catalog snapshot checked on November 12, 2026 did not contain this ID; absence from KEV is not evidence that a deployment is safe.

Close the finding when the corrected GDAL source or supplier package is tied to the active consumer, with unresolved copies explicitly tracked. A generic “zlib updated” ticket cannot substitute for that component-specific evidence.

The following official Penligent 3.0 video demonstrates the general product workflow. It does not demonstrate exploitation or certify remediation of the vulnerabilities discussed here.

Source review: November 12, 2026. This analysis uses public primary records and configuration or source-code reasoning; no exploit reproduction is claimed.