chore(deps): GDAL 3.9.2 deferred under documented exception - replace when a trusted 3.13+ wheel is available

[mgmachado]

Current state: documented dependency exception (deferred upgrade)

Rescoped 2026-08-20. This issue originally read as pending HIGH-severity
upgrade work. That is no longer accurate: the team formally deferred the
upgrade under a documented dependency exception and shipped compensating
controls (ADR-0004, spec/features/gdal-compensating-controls/). The issue
now tracks only the remaining work — replacing GDAL 3.9.2 once a trusted
3.13+ wheel exists. Original body preserved at the bottom for history.

Alerts: Dependabot 33, 34, 38 — all dismissed as "risk tolerable"
Component: hastelib/pyproject.toml, api/hastefuncapi/requirements.txt, api/hastefuncqueues/requirements.txt, docker/imageryprep/requirements.txt

Vulnerabilities

Alert	CVE	NIST severity	Affected GDAL driver
34	CVE-2026-8087	HIGH 7.8	Heap overflow in HDF4/EOS GDnentries
33	CVE-2026-8088	Medium 5.5	Out-of-bounds read in GDfieldinfo
38	CVE-2026-8212	Medium 5.5	Out-of-bounds read in SWSDfldsrch

All three are in the HDF4/HDF-EOS driver family.

Why this is deferred, not stalled

GDAL is not installable from PyPI for HASTE's runtime — the project consumes a
custom-built manylinux wheel. No trusted prebuilt wheel for the patched 3.13
line is currently available, so the upgrade is blocked on an external
dependency rather than on engineering effort.

See docs/known-vulnerabilities.md → Root Cause C.

Compensating controls — implemented ✅

Enforced in code and reviewed weekly. See
ADR-0004
(accepted 2026-06-26) and
spec/features/gdal-compensating-controls/
(approved).

• Pre-parse driver allowlist. gdal_security.harden_gdal() deregisters
  every driver outside raster GTiff, COG, VRT, JPEG, PNG, MEM and vector
  GPKG, GeoJSON, Memory, wired into every parse site. The vulnerable
  HDF4/HDF-EOS drivers are not registered at runtime.
• Subprocess coverage. GDAL_SKIP="HDF4 HDF4Image HDF5 HDF5Image netCDF"
  in docker/imageryprep/Dockerfile and docker/training/Dockerfile, so
  CLI tools (gdalwarp, gdal_translate) refuse them too.
• Authenticated, allowlisted providers. utils/url_allowlist.py;
  PutLayer rejects off-allowlist hosts at submission.
• Magic-byte pre-validation. gdal_security.sniff_file_type +
  core/processors/uploader.py verify the assembled file matches its
  declared format before GDAL sees it. (Extension/MIME checks alone are
  insufficient — GDAL sniffs content, per ADR-0004.)
• Size caps. HASTE_MAX_UPLOAD_BYTES, HASTE_MAX_IMAGERY_DOWNLOAD_BYTES.
• SSRF / redirect guards. core/utils/downloader.py and
  workflows/prepare_imagery.py refuse to follow redirects.
• ADR authored. ADR-0004.
• Weekly exception review. Per
  docs/triage-process.md.

Net effect: the specific code paths carrying these three CVEs are not
reachable from any HASTE runtime configuration.

Remaining work

Gated on external wheel availability — do not start until step 1 is satisfied.

• A trusted prebuilt GDAL 3.13+ cp311 manylinux wheel becomes available
  (or HASTE's deployment model changes to make one buildable/verifiable)
• Publish it to the haste-binaries GitHub release tag
  (https://github.com/microsoft/haste/releases/download/haste-binaries/)
  — currently holds only GDAL-3.9.2-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl
• Update the wheel URL in api/hastefuncapi/requirements.txt,
  api/hastefuncqueues/requirements.txt, docker/imageryprep/requirements.txt
• Update "gdal==3.9.2" in hastelib/pyproject.toml
• Full geospatial regression (imagery read/write, COG generation,
  reprojection, damage assessment pipeline)
• Re-evaluate whether the ADR-0004 driver allowlist should stay (recommend
  yes — it is defence-in-depth independent of GDAL version)
• Update docs/known-vulnerabilities.md Root Cause C and close the exception

Corrections to the original body

• Upload to researchlabwuopendata.blob.core.windows.net/haste-binaries/ —
  stale. Since chore(build): host GDAL and hastegeo wheels on GitHub Releases #75, binaries are hosted in the haste-binaries GitHub
  release tag.
• Author an ADR — done, ADR-0004.
• Interim mitigation: authenticated known-good providers — done,
  url_allowlist.py.
• Interim mitigation: magic-byte pre-validation — done,
  gdal_security.sniff_file_type.
• Referenced triage report path was docs/security-triage-2026-06-23.md; the
  file in the repo is docs/security-triage:2026- 06-23.md.

Follow-up worth splitting out

docker/training/env/env.yml:6 pins gdal<3.9 via conda-forge — a
different and older constraint than the 3.9.2 wheel, and it is not listed
in the Root Cause C affected-files inventory. The GDAL_SKIP control in
docker/training/Dockerfile does cover it at runtime, but whether that conda
build falls in the advisories' affected ranges has not been verified. Suggest a
separate issue to confirm and to add it to the inventory.

Owner: GIS Agent + Backend Dev Agent
Review cadence: weekly, per the dependency exception process

References

• NVD CVE-2026-8087 · NVD CVE-2026-8088 · NVD CVE-2026-8212
• docs/known-vulnerabilities.md — Root Cause C
• ADR-0004 — GDAL/OGR driver allowlist
• spec/features/gdal-compensating-controls/

---

Original issue body (pre-rescope, 2026-06-24)

Current State: Dependency exception

Description

Alerts: Dependabot alerts 33, 34, 38
Severity: HIGH 7.8 (NIST NVD, CVE-2026-8087) / Medium for others — Dependabot rates all three LOW, but NIST disagrees on CVE-2026-8087
Component: hastelib/pyproject.toml, docker/imageryprep/requirements.txt

Vulnerabilities

Three memory-safety bugs in GDAL 3.9.2:

Alert	CVE	NIST Severity	Description
34	CVE-2026-8087	HIGH 7.8	Heap-based buffer overflow in HDF4/EOS GDnentries
33	CVE-2026-8088	Medium 5.5	Out-of-bounds read in GDfieldinfo
38	CVE-2026-8212	Medium 5.5	Out-of-bounds read in SWSDfldsrch

All three are file-parsing vulnerabilities. HASTE uses GDAL throughout hastelib to read satellite imagery (GeoTIFF, COG, HDF4-EOS) sourced from external providers. A malicious file delivered via imagery provider API could trigger these in the imageryprep pipeline or Azure Functions.

Fix

Upgrade GDAL from 3.9.2 to 3.13.x.

⚠️ HASTE uses a custom-built manylinux wheel

GDAL is not installable from PyPI — HASTE builds and hosts its own wheel at an Azure Blob URL. This is not a simple version bump.

Required steps:

• Build GDAL-3.13.x-cp311-cp311-manylinux_2_17_x86_64.whl (see existing build process)
• Upload new wheel to the HASTE binaries blob container (researchlabwuopendata.blob.core.windows.net/haste-binaries/)
• Update the wheel URL in docker/imageryprep/requirements.txt
• Update the pin in hastelib/pyproject.toml
• Run full geospatial regression tests (imagery read/write, COG generation, reprojection, damage assessment pipeline)
• Author an ADR in spec/architecture/decisions/ documenting the wheel build process

Owner: GIS Agent + Backend Dev Agent

Interim mitigations (until upgrade is complete)

• Ensure all imagery input is received from authenticated, known-good provider APIs only
• Consider adding magic-byte pre-validation before passing files to GDAL

References

• NVD CVE-2026-8087
• NVD CVE-2026-8088
• NVD CVE-2026-8212
• Triage report: docs/security-triage-2026-06-23.md

[mgmachado]

Upgrade constraint: HASTE depends on externally hosted Linux pip wheels for GDAL. A trusted prebuilt pip wheel source for the patched GDAL 3.13 line is not currently available for HASTE runtime constraints. Thus, keeping alerts #33, #34, and #38 in a documented dependency exception state here.

Implementation of compensating controls is in progress.