Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessReach PostGIS query endpoint
-
DeliverySubmit non-numeric featureId/qstring value
-
ExploitBreak out of unquoted numeric predicate
-
ExecutionRun boolean/time-based blind SQLi
-
ImpactEnumerate unintended database records
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V1 - Encoding and Sanitization Parameterized queries, prepared statements
MITRE ATT&CK
2 techniques across 2 tactics: Initial Access, Persistence The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Requires a MapServer LAYER with CONNECTIONTYPE POSTGIS whose filter/ID item is configured as numeric via metadata (e.g. gml_<item>_type=Integer), and that layer must be reachable through a query endpoint that accepts attacker-controlled input - either the CGI qstring filter or an OGC API Features featureId path segment. Exploitation is unauthenticated (PR:N) and needs no user interaction, but is gated to affected versions 8.4.0 through 8.6.3; layers using non-numeric items, non-PostGIS connections, or without the numeric metadata are not affected by this specific unquoted-concatenation path. Full data extraction relies on blind (boolean/time-based) inference since the flaw does not itself enable database modification. |
| Impact | This is a genuine, higher-priority issue rather than a paper-tiger high-CVSS. The vendor CVSS 8.2 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L) describes a network-reachable, unauthenticated, low-complexity SQL injection (CWE-89) - the most weaponizable class of web flaw - and I largely agree with it. The impact profile is honest: C:H reflects full data exfiltration achievable via boolean/time-based blind injection, I:N correctly captures that the vendor states no database modification is established, and A:L reflects increased DB load rather than a full outage. No EPSS/KEV/POC/SSVC signals were provided: exploitation status is 'no public exploit identified at time of analysis,' so this is not confirmed in-the-wild activity. The one material caveat the raw CVSS score hides is a configuration gate - exploitation requires a PostGIS-backed layer with numeric-type metadata (e.g. gml_<item>_type=Integer) exposed on a query endpoint - which narrows the real-world attack surface below what an unqualified 8.2 implies. Net: treat as a real priority for anyone running MapServer PostGIS layers behind CGI/OGC API Features, patch promptly, but recognize exploitation is conditional on that specific layer configuration. |
| Exploit ScenarioDerived | An unauthenticated attacker locates a MapServer OGC API Features (or classic CGI) endpoint backed by a CONNECTIONTYPE POSTGIS layer whose ID/filter item is declared numeric (gml_gid_type=Integer). Instead of a numeric featureId or qstring value, they supply a non-numeric SQL fragment, which is concatenated unquoted into the generated PostgreSQL predicate, enabling predicate bypass and boolean-/time-based blind SQL injection to enumerate unintended records. No public exploit code was provided in the intelligence, though the fixing PR (#7516) ships a regression test demonstrating the invalid-input path. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 17, 2026
Unauthenticated SQL injection in MapServer 8.4.0 through 8.6.3 lets remote attackers who can reach a PostGIS-backed query endpoint inject arbitrary SQL fragments into the generated PostgreSQL predicate, bypassing record-level filters and enumerating data they should not see. The flaw is reachable via the CGI qstring filter or an OGC API Features featureId path segment when a layer is configured with CONNECTIONTYPE POSTGIS and numeric item metadata such as gml_<item>_type=Integer; the unquoted value is concatenated straight into the SQL statement. Per the assessed CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L vector, confidentiality impact is high while integrity is unaffected, meaning successful exploitation yields predicate bypass, unintended-record enumeration, and blind boolean- or time-based extraction rather than database modification, with a modest availability cost from increased database load; no public exploit code and no confirmed active exploitation were identified at time of analysis, and version 8.6.4 fixes the issue.
RemediationAI
Upgrade to MapServer 8.6.4, which is the vendor-released patch; the fix is documented in the GitHub security advisory GHSA-xp29-8wp5-wc3p, delivered via pull request #7516 and commits 65f1b53c258df2abdf6ce1f437c29e75e9976247 and bd59d49779d2ecc64ca8dc1281c53231a50b698e, and shipped in release tag rel-8-6-4 (changelog at mapserver.org/development/changelog/changelog-8-6.html). If an immediate upgrade is not possible, the most effective compensating control is to stop exposing attacker-controlled input to the vulnerable translation branch: remove or change numeric type metadata for any filter or feature-ID item on PostGIS layers that are reachable from untrusted clients - reclassifying gml_<item>_type from Integer to a string type forces the driver down the quoted path and neutralizes the injection, at the cost of losing numeric comparison semantics and possibly breaking client-side sort/filter behavior that depends on numeric typing. Additionally, disable or firewall the CGI qstring filter parameter and any OGC API Features endpoint on PostGIS layers until patched (this removes the attack surface entirely but may break legitimate GIS clients), and run the MapServer database connection under a least-privilege PostgreSQL role limited to SELECT on the intended tables so that even a successful injection cannot widen data access or touch the schema; note that least privilege reduces the impact of enumeration but does not prevent blind injection or the added database load. Because this is a blind, read-only-class defect with no confirmed exploitation in the wild, upgrading remains the recommended primary action and the compensating controls are transitional only.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MapServer's PostGIS driver builds SQL predicates in src/mappostgis.cpp through the msPostGISLayerTranslateFilter() function. To translate a MapServer filter expression into PostgreSQL, the driver inspects layer metadata to decide how a given filteritem should be rendered: when the layer uses CONNECTIONTYPE POSTGIS and metadata such as gml_<item>_type=Integer is present, the item is classified as numeric and its literal is emitted without surrounding quotes. The pre-fix code trusted that classification and concatenated the runtime value verbatim, never validating that the incoming value actually parses as a numeric literal. Because CGI query strings and OGC API Features featureId path segments are attacker-controlled and flow into the same translation path, a string such as a SQL fragment appended to the expected integer is merged directly into the PostgreSQL/PostGIS WHERE clause. This is a classic CWE-89 improper neutralization of special elements used in an SQL command, and specifically the 'unquoted numeric context' variant: quoting would normally neutralize injected characters, but the numeric branch deliberately removes that protection. The published fix adds a std::strtod() parse whose endptr is required to have consumed the whole string, returning MS_FAILURE for any value containing trailing or embedded non-numeric content - so non-numeric input is rejected rather than interpolated. The upstream test case (msautotest/api/ogcapi_postgis_numeric_id.map plus the expected ogcapi_postgis_numeric_id_invalid_id.json 'Invalid API path' response) demonstrates the intended behavior for an invalid featureId. The vulnerability only manifests on layers that combine a PostGIS connection, a numeric-typed filter or feature-ID item, and a query endpoint that exposes attacker-controlled input; conversely, any layer whose item is tagged as a string type is quoted and does not traverse this vulnerable branch.
Know when Mapserver gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:L
Unauthenticated network SQLi over an exposed query endpoint (AV:N/PR:N/UI:N); blind injection yields full read (C:H), no modification stated (I:N), and only added DB load (A:L).
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
MapServer is a system for developing web-based GIS applications. Prior to 8.6.4, MapServer's PostGIS runtime filter translation in src/mappostgis.cpp and msPostGISLayerTranslateFilter() treats a filteritem as numeric when CONNECTIONTYPE POSTGIS and metadata such as gml_<item>_type=Integer are configured, but it does not verify that attacker-controlled CGI qstring or OGC API Features featureId input is a numeric literal. The unquoted input is concatenated into the generated PostgreSQL/PostGIS predicate, allowing an unauthenticated remote attacker with access to an affected query endpoint to bypass predicates, enumerate unintended records, perform boolean-based or time-based SQL injection, and increase database load. The issue does not by itself establish database modification capabilities. This issue is fixed in version 8.6.4.
Articles & Coverage 1
Technical POC Analysis
CWE-89 (Improper Neutralization of Special Elements used in an SQL Command).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
MapServer versions 8.4.0 through 8.6.3 contain an unauthenticated SQL injection flaw that enables remote attackers to bypass record-level filters on PostGIS-backed layers and enumerate sensitive geospatial data without authentication. This high-severity vulnerability affects any organization that exposes these MapServer instances, potentially leading to unauthorized disclosure of proprietary or regulated information and compliance violations. Leadership should prioritize immediate mitigation and assess whether data exposure has already occurred.
Apply vendor patch.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
SQL injection exploits the way applications construct database queries by mixing user input directly into SQL statements.
MapServer is a system for developing web-based GIS applications. Rated high severity (CVSS 8.9), this vulnerability is r
Stack-based buffer overflow in MapServer before 6.0.6, 6.2.x before 6.2.4, 6.4.x before 6.4.5, and 7.0.x before 7.0.4 al
In MapServer before 7.0.3, OGR driver error messages are too verbose and may leak sensitive information if data connecti
Denial of service in MapServer 6.4.0 through 8.6.2 allows remote unauthenticated attackers to crash the server by submit
SQL injection vulnerability in the msPostGISLayerSetTimeFilter function in mappostgis.c in MapServer before 6.4.1, when
Reflected XSS in MapServer 6.0 through 8.6.1 allows unauthenticated remote attackers to inject arbitrary HTML and JavaSc
Reflected cross-site scripting (CWE-79) in MapServer's OpenLayers HTML output affects versions 6.0 through 8.6.3 and is
MapServer versions 4.2 through 8.6.0 are vulnerable to a heap buffer overflow in the SLD (Styled Layer Descriptor) parse
MapServer before 7.0.8, 7.1.x and 7.2.x before 7.2.3, 7.3.x and 7.4.x before 7.4.5, and 7.5.x and 7.6.x before 7.6.3 doe
EUVD-2026-82431
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB