GHSA-mqjf-5f49-2fjh (CVSS 9.8): GeoServer PostGIS jsonArrayContains SQL Injection Enables Unauthenticated RCE — Hundreds of Exploitation Attempts Within Hours of Disclosure

On 12 August 2026 at 10:46 UTC, a security researcher posting as @q1uf3ng dropped a proof-of-concept for a critical SQL injection flaw in GeoServer, the world’s most widely deployed open-source geospatial platform. Within the same business day, watchTowr’s threat-intelligence sensors were recording hundreds of active probing attempts — attackers mapping vulnerable instances before the broader community had even finished reading the advisory. That is the modern timeline for critical infrastructure exploitation: hours, not weeks.

The flaw has been catalogued as GHSA-mqjf-5f49-2fjh with a CVSS base score of 9.8. No authentication is required. No user interaction is needed. A single crafted HTTP request is all it takes to inject arbitrary SQL into the underlying database and, from there, pivot to remote code execution on the server hosting your geospatial services.

For any organisation — government ministry, utility company, smart-city operator, urban planning department, or enterprise — that has a GeoServer instance reachable from the public internet, this is a drop-everything-right-now emergency.

What Is GeoServer and Why Is It Critical Infrastructure?

GeoServer is a Java-based, OGC-compliant server that publishes geospatial data as Web Feature Services (WFS), Web Map Services (WMS), and Web Coverage Services (WCS). It is the backbone of national mapping portals, environmental monitoring dashboards, flood-alert systems, disaster-relief coordination platforms, and municipal land-records applications worldwide.

In India specifically, GeoServer underpins an enormous slice of digital governance infrastructure:

• ISRO / National Remote Sensing Centre (NRSC) satellite-derived land-use portals
• Survey of India online map services
• State-level urban local body (ULB) GIS platforms used for property tax, building permits, and smart-city dashboards
• Flood Early Warning System (FEWS) layers published by the Central Water Commission
• Forest department and biodiversity registries

These are not trivial web applications. A compromised GeoServer can expose sensitive cadastral data, citizen records, infrastructure co-ordinates, and internal network pathways to downstream enterprise systems. The attack surface is both technically severe and strategically consequential.

Technical Breakdown: The jsonArrayContains SQL Injection

GeoServer implements the Open Geospatial Consortium (OGC) filter specification, allowing clients to query spatial datasets with expressive predicates — think “give me all buildings within 500 m of this point where material = ‘concrete’.” These filters are parsed server-side and translated into SQL for the backing database.

When GeoServer uses a PostGIS DataStore — the PostgreSQL extension for spatial data — one of the available filter functions is jsonArrayContains(<column>, <pointer>, <value>). The function is designed to check whether a JSON array column contains a given value at a given JSON Pointer path.

The vulnerability is simple but devastating: the <value> argument is written directly into the generated SQL without escaping or parameterisation. A malicious client can embed SQL metacharacters — quotes, semicolons, UNION clauses, stacked queries — inside the value argument of a perfectly ordinary WFS or WMS GetMap request. GeoServer dutifully hands that string to PostgreSQL with full database-user privileges.

Depending on the PostgreSQL user account under which GeoServer connects, attackers can:

• Dump the entire spatial and attribute database, including any personally identifiable information
• Write files to disk via PostgreSQL’s COPY TO/FROM mechanism
• Execute OS-level commands through COPY FROM PROGRAM (available when PostGIS is configured with a superuser or pg_execute_server_program role) — achieving full remote code execution

The condition for exploitation is PostGIS 12 or later with String or JSON field types present in the published layer schema. This covers the overwhelming majority of modern GeoServer/PostGIS deployments.

The Regression Dimension

What makes this finding particularly embarrassing is that it is a regression of CVE-2023-25158, an identical CVSS 9.8 SQL injection in the OGC filter evaluation engine that the GeoServer project patched in February 2023. The 2023 fix addressed the known vulnerable functions; the 2026 flaw shows that jsonArrayContains — added or modified after that remediation — was not subjected to the same escaping discipline. Every patch that touches filter evaluation logic must be regression-tested against SQL injection, not just the functions explicitly flagged in a prior advisory.

Detail	CVE-2023-25158 (Prior)	GHSA-mqjf-5f49-2fjh (Current)
CVSS Score	9.8 Critical	9.8 Critical
Attack Type	OGC filter SQL injection	OGC filter SQL injection (jsonArrayContains)
Auth Required	None	None
Impact	Data exfiltration, RCE	Data exfiltration, RCE
Patch Month	February 2023	August 2026
Active Exploitation	Yes (added to CISA KEV)	Yes — within hours of disclosure

The Exploitation Timeline: Hours, Not Weeks

The pace of weaponisation in 2026 demands a different mental model from the old “30-day patch window.” Here is what happened after @q1uf3ng’s disclosure:

• Hour 0 (10:46 UTC, 12 Aug 2026): Researcher posts proof-of-concept on X.
• Hours 1–4: watchTowr’s global honeypot network begins recording structured probes targeting the jsonArrayContains endpoint. Requests arrive from a small cluster of IP addresses — consistent with organised attacker infrastructure, not random scanning.
• Hours 4–8: The probing volume climbs to hundreds of attempts. Attackers appear to be in the reconnaissance phase — triggering errors to confirm vulnerability, enumerating layer names, and mapping the database schema.
• Same day: GeoServer releases patched versions 3.0.1, 2.28.5, and 2.27.6.

The current attacker posture — error-triggering and schema reconnaissance without large-scale data exfiltration — suggests adversaries are building target lists for deeper follow-on exploitation. This is the window organisations have to act. It will not stay open long.

GeoServer’s history with the CISA Known Exploited Vulnerabilities (KEV) catalog — including the predecessor CVE-2023-25158 and CVE-2024-36401, a 2024 RCE bug that was mass-exploited within days — makes it near-certain that GHSA-mqjf-5f49-2fjh will land on the KEV list once a CVE number is formally assigned.

What You Should Do Right Now — Sanjay Seth’s Expert Perspective

I have spent three decades securing enterprise and government networks across India. The instinct to wait for a change window, wait for the CVE number, or wait for the vendor’s PSIRT email is understandable — but it is the wrong instinct here. A CVSS 9.8, no-auth, actively-probed flaw in internet-exposed infrastructure demands an emergency response cadence, not a scheduled maintenance cadence.

Here are the concrete actions your team should execute in priority order:

1. Inventory every GeoServer instance in your environment. Check cloud VMs, on-premises servers, containerised deployments, and shared hosting. Run find / -name geoserver.war 2>/dev/null or query your CMDB. If you do not know what you have, you cannot protect it.
2. Take internet-facing GeoServer instances offline or behind a WAF immediately. If you cannot patch within the hour, place the service behind a Web Application Firewall that can block OGC filter payloads containing SQL metacharacters, or restrict access to known IP ranges. Zero-trust architecture principle: no internal service should be directly internet-reachable without a controlled access layer in front of it.
3. Patch to GeoServer 3.0.1, 2.28.5, or 2.27.6 (matching your branch). Also update the underlying GeoTools library: org.geotools:gt-jdbc-postgis to version 33.6, 34.5, or 35.1. Confirm both components are updated — the vulnerability exists in the GeoTools layer, not just the GeoServer layer.
4. Review your PostgreSQL connection credentials. GeoServer should connect as a read-only database user scoped only to the schemas it needs to publish. If your GeoServer connects as a superuser or as a user with pg_execute_server_program, revoke that privilege immediately and re-scope it. This is the principle of least privilege in practice, and it is the difference between a data-read incident and a full RCE incident.
5. Hunt for exploitation indicators. Examine your GeoServer access logs for requests containing jsonArrayContains in filter parameters alongside SQL metacharacters. Cross-reference with the watchTowr-published attacker IPs: review any traffic from unfamiliar IP ranges, especially Tor exit nodes or VPN egress addresses.
6. Validate your patch against SQL injection, not just feature parity. Before signing off any GeoServer upgrade, run a structured SQLi test against the jsonArrayContains filter function. The regression nature of this flaw proves that functional testing alone is insufficient.

If your organisation runs GeoServer as part of a smart-city platform, a national mapping service, or a critical-sector monitoring system, this vulnerability should be escalated to your CISO and IT leadership today. The Indian Computer Emergency Response Team (CERT-In) is likely to issue an advisory; do not wait for it to act.

For organisations managing NOC/SOC operations: add detection rules for jsonArrayContains in HTTP request bodies and URI query strings, with pattern matching for SQL injection metacharacters. Alert on any 500-class errors from GeoServer endpoints, which indicate error-triggering reconnaissance. Also correlate ransomware lateral movement patterns — compromised geospatial servers sitting on internal networks are attractive pivot points into data-rich environments.

This vulnerability also illustrates why zero-trust network architecture must extend to “trusted” internal services like GeoServer. No service — however inward-facing it feels — should have unfettered database access and no network controls. Segment GeoServer on a dedicated network zone, enforce mTLS between GeoServer and its PostgreSQL/PostGIS backend, and require API gateway authentication even for OGC standard endpoints. Had these controls been in place, the jsonArrayContains flaw would be a contained database-layer incident rather than a direct path to the host OS.

I previously wrote about a similar pattern with Apache Tomcat’s unauthenticated RCE (CVE-2026-34486) — open-source Java infrastructure that is trusted by default and exposed to the internet without adequate access controls. GeoServer follows the same risk profile. If you manage Java-stack infrastructure, now is the time to audit every service’s network exposure and database permissions.

Affected Versions and Patch Reference

The vulnerability affects the GeoTools library component org.geotools:gt-jdbc-postgis, which GeoServer bundles:

• GeoTools ≥33.1 and <33.6 → upgrade to 33.6; corresponding GeoServer fix: 2.27.6
• GeoTools ≥34.0 and <34.5 → upgrade to 34.5; corresponding GeoServer fix: 2.28.5
• GeoTools 35.0 → upgrade to 35.1; corresponding GeoServer fix: 3.0.1

Prerequisite for exploitation: The GeoServer instance must use a PostGIS 12+ DataStore and have at least one layer with String or JSON field types published. This is the default configuration for the vast majority of production deployments.

Official sources: GeoTools Security Advisory GHSA-mqjf-5f49-2fjh | The Hacker News Coverage | SecurityWeek Analysis | Field Effect Threat Intelligence

Frequently Asked Questions

Do I need to use JSON fields for my GeoServer instance to be vulnerable?

Not necessarily. The requirement is that the PostGIS DataStore exposes at least one layer containing String or JSON field types — which covers the majority of real-world PostGIS schemas. If your layers contain only numeric or geometry fields with no string attributes, the risk is reduced, but you should still patch; future schema changes could re-expose the attack surface.

We use GeoServer behind a reverse proxy — are we protected?

A plain reverse proxy that forwards HTTP traffic transparently provides no protection. You need a Web Application Firewall with specific OGC-filter inspection rules, or an API gateway that validates filter parameters before forwarding to GeoServer. If your reverse proxy merely handles TLS termination and load balancing, assume you are vulnerable.

My organisation uses a GeoServer-as-a-Service cloud offering. Do I need to act?

Contact your cloud provider immediately and ask for written confirmation of the patched version running in your tenancy. Hosted GeoServer services should be auto-patching, but do not assume — verify. Ask for logs showing upgrade completion and test the patch by confirming the version string in the GeoServer web admin interface reflects 3.0.1, 2.28.5, or 2.27.6.

Is CERT-In expected to issue an advisory on this?

Given CERT-In’s track record of issuing advisories on CVSS 9.x vulnerabilities in widely deployed open-source infrastructure — typically within 72 hours of public disclosure — an official advisory is likely by the time you read this post. The fact that significant Indian government GIS infrastructure runs on GeoServer elevates this to a national-level concern. Do not wait for the official advisory; treat this as a critical incident now.

The Bigger Picture: Geospatial Infrastructure as an Attack Target

Geospatial platforms have historically received less security scrutiny than web applications or enterprise software — partly because they are seen as “read-only” data services, and partly because their user bases are specialist audiences who tend to prioritise feature completeness over security hardening. The result is a category of infrastructure that is frequently internet-facing, running outdated versions, connected to privileged database accounts, and managed by teams without dedicated security operations expertise.

Threat actors know this. The rapid weaponisation of GHSA-mqjf-5f49-2fjh — within hours of a public PoC — reflects organised attacker groups running continuous scans for exactly these high-value, low-hardening targets. The same speed-to-exploitation pattern played out with Kemp LoadMaster’s pre-auth RCE earlier this month. The attackers have automated pipelines. Your response needs to match that pace.

The zero-trust principle applies here with full force: no geospatial service should be trusted by virtue of its position inside the network perimeter. Every GeoServer instance should require authenticated access, connect to its database with least-privilege credentials, and be monitored at the application layer for anomalous filter queries. That hardening posture would have turned this critical vulnerability into a contained, low-severity incident.

---

Is your GIS infrastructure — or any other Java-stack service — exposed to the internet without adequate access controls? If you are not certain, the answer is probably yes. At P J Networks, we conduct structured security assessments of geospatial platforms, OGC-compliant services, and enterprise network architecture across India. We will map your exposure, validate your patch status, and recommend a zero-trust hardening roadmap tailored to your environment.

Book a Security Assessment →