GDAL

Skip to content What this pays This project runs no bounty of its own. sorona.xyz pays you directly on qualified, reproduced findings. Severity │ sorona.xyz pays Critical │ $1,500+ High │ $700+ Medium │ $300+ Low │ $100 / 1 month Claude Max Submit a vulnerability Latest advisories Loading the feed Overview GDAL is the translation layer every geospatial pipeline runs on. QGIS, PostGIS raster, rasterio and fiona, GRASS, MapServer, GeoServer, Esri interop paths and Google Earth Engine ingest all push files through it, and it carries several hundred format drivers written mostly in C and C++. A GeoTIFF, a NITF or a GeoPackage arriving from outside reaches parser code written for correctness on well-formed data. The maintainers say as much in their own policy, describing GDAL as a permanent OSS-Fuzz target and telling users to treat data from untrusted sources with caution. Nothing about that policy offers a reward. sorona.xyz pays you directly on qualified, reproduced findings. In scope The published policy accepts security issues through the public issue tracker and draws no boundary narrower than the GDAL tree itself. Everything the library ships sits inside that The raster driver surface in full, all several hundred of them: GeoTIFF, NITF, JPEG2000, HDF4 and HDF5, NetCDF, PDF, PNG and JPEG, MrSID, ECW and every long-tail format nobody has looked at in years The vector driver surface: shapefile, GeoPackage and the SQLite paths under it, GeoJSON, GML, KML, FileGDB, DXF, MapInfo and the rest of the OGR set The virtual filesystem layer: /vsicurl/ , /vsis3/ , /vsizip/ , /vsitar/ , /vsigzip/ , /vsimem/ and every other handler, including path parsing and the chained forms Every network-fetching path, covering HTTP range requests, cloud object-store access, credential handling and redirect following The GDAL and OGR core: dataset and band abstractions, block caching, the RAT and metadata model, and the overview machinery The algorithm and warping code, including reprojection, resampling, rasterisation and polygonisation The command-line utilities the project ships, such as gdal_translate , gdalwarp , ogr2ogr and gdalinfo , and the newer unified gdal tool The Python, Java and C# bindings and the ownership and lifetime handling across those boundaries SQL handling in the OGR SQL dialect and in the SQLite dialect that GeoPackage and Spatialite paths use The XML, JSON and WKT parsing that appears throughout the metadata, configuration and service-description paths Out of scope PROJ, libtiff, libgeotiff, GEOS, SQLite, libcurl and the other upstream libraries GDAL links, unless GDAL's own use of them is what makes the bug reachable QGIS, PostGIS, rasterio, GRASS, MapServer and other consumers of GDAL: a bug in how they call it belongs to them Duplicates of open OSS-Fuzz findings, which the maintainers already track continuously Distribution packaging and conda or OSGeo4W build choices rather than upstream GDAL An application deliberately handing GDAL a network path or a driver it should not have enabled, which is a configuration decision by the caller Most-valued findings Heap overflows and out-of-bounds writes in a driver reachable from an ordinary open, since GDAL is routinely invoked on files that arrived from the internet through a web map service or an upload form Memory-safety bugs in the widely wired formats first: GeoTIFF, GeoPackage, shapefile, NetCDF, HDF and JPEG2000 sit in almost every deployment, so a finding there reaches QGIS, PostGIS and rasterio at once Anything in the long-tail drivers that a distribution still builds by default, where nobody has looked and the parser predates the current fuzzing effort Server-side request forgery and credential leakage through /vsicurl/ , /vsis3/ and the other network virtual filesystems, particularly where a filename inside a dataset chooses the destination Path traversal in /vsizip/ and /vsitar/ , where an archive entry escapes the location the caller intended to extract into Type confusion or integer handling in the block cache and band abstraction, which every driver funnels through and where one bug covers hundreds of formats SQL injection through the OGR SQL and SQLite dialects, on GeoPackage and Spatialite datasets that carry their own queries and virtual tables Amplification and resource-exhaustion bugs that a tiny file triggers, since GDAL frequently runs unattended on a tile server with a request timeout and no memory limit Program rules Submit through sorona.xyz. This project runs no bounty of its own; we validate, coordinate disclosure with the maintainers, and pay you directly. Read the policy before filing. GDAL asks reporters to use the PUBLIC issue tracker, which is the opposite of the norm in this category and is deliberate The one restriction the policy states is to refrain from publicly posting exploits with harmful consequences such as data destruction. A crash reproducer is fine in public; a destructive one is not Only Project Steering Committee members, or people they explicitly allow, may ask you privately for a dangerous reproducer. Treat a private request from anyone else as suspect GitHub private vulnerability reporting is disabled on OSGeo/gdal , so the advisory button is not an option here Name the driver and give the file. Almost everything on this codebase is reachable only through a specific format, and a bare stack trace without the input is not actionable Say whether the input is a plain file or a network path. /vsicurl/ , /vsis3/ and the other virtual filesystems change the threat model entirely Check the OSS-Fuzz record first. The maintainers already run continuous fuzzing and a duplicate of an open fuzzer finding is worth nothing to anyone There is no reward in this policy and no bounty programme anywhere for GDAL. There is nothing to negotiate Disclosure Public by default. GDAL's policy routes reports to the open issue tracker and asks only that harmful exploits stay out of public view, with the Project Steering Committee handling dangerous reproducers privately when one is needed. Fixes land in the tree and ship in the next release, and CVEs are assigned for the more serious ones. There is no embargo to observe on an ordinary finding, and a destructive proof of concept is the one thing to hold back until the PSC asks for it. Safe harbor Sorona will not pursue legal action against you for good-faith research submitted to us in line with this policy. We cannot speak for the upstream project, its vendor, or any third party, and we do not grant authorization on their behalf. You are responsible for understanding and following the laws that apply to you, wherever you are, and for staying within any scope the project has defined. Submit a vulnerability