The GeoServer zero-day is an unauthenticated SQL injection reachable through the jsonArrayContains filter expression in a standard OGC filter. Under some database configurations it escalates to remote code execution. It was disclosed publicly on August 12, 2026, with no CVE and no patch, and drew exploitation attempts within hours.
Strip away the specifics and what is left is the oldest flaw class on the OWASP list, arriving with none of the things a scanner usually keys on. No CVE number. No vulnerable version string. No detection template. That absence is the whole story.
Key takeaways
- The flaw is unauthenticated SQL injection through an OGC filter, and under certain database configurations it reaches command execution.
- At disclosure there was no CVE identifier and no patch. Signature and version matching had nothing to recognize.
- SQL injection is a behavioral class. You find it by sending crafted input to the running endpoint and reading how it answers, not by matching a fingerprint.
- The same
jsonArrayContainsfunction carried an injection in 2023. Closing one payload shape does not close the class. - Whatever runs your GeoServer, the endpoint is reachable to an attacker the same way it is reachable to you: over the wire, without a login.
What was disclosed
On August 12, 2026, a researcher published details of a SQL injection flaw in GeoServer, the open-source platform for publishing and querying geospatial data used across government, agriculture, telecoms, and transit. Reporting from The Hacker News and SecurityWeek put the shape of it plainly: the vulnerability is in the jsonArrayContains function, requires no authentication, and under certain configurations can lead to remote code execution.
Exploitation did not wait. Hundreds of attempts were observed within hours of disclosure, from a small pool of addresses probing for vulnerable instances. At the time of writing the flaw remains unpatched and has no CVE assigned, and the standing guidance is to restrict public access to GeoServer instances and watch for an official fix.
How the injection reaches SQL
GeoServer answers queries through OGC filters. A caller sends a filter expression, GeoServer translates it into SQL, and the backing datastore runs it. That translation is the exposed seam.
The jsonArrayContains expression checks whether a JSON array field holds a given value, and it is supported against PostGIS and Oracle datastores. When its arguments are concatenated into the generated SQL without adequate escaping, a caller who controls those arguments controls part of the query. The public write-ups attribute the flaw to exactly that, user-supplied input reaching the database query improperly sanitized.
This is not the first time the function has been here. GeoServer's 2023 OGC filter injection advisory and the accompanying security advisory (GHSA-7g5f-wrx8-5ccf) covered CVE-2023-25157, an injection through the same jsonArrayContains filter. A patch closed the payloads known then. The class it belonged to did not go anywhere, and the 2026 flaw is a fresh way into it.
Day zero is the signature gap
Here is the part worth sitting with, because it generalizes past GeoServer.
A large share of automated detection works by recognition. A scanner checks a version banner against a list of vulnerable releases, or matches a response against a template written for a known CVE. That machinery is genuinely useful, and it is fast, but it can only recognize what has already been named. On the day a zero-day drops there is no CVE number to look up, no patched-version boundary to compare against, and no template to run. The recognition half of scanning has nothing to recognize.
The gap is not a defect in that approach. It is the definition of a zero-day. And it is the interval attackers move fastest in, precisely because so much defensive tooling is waiting for a name that does not exist yet.
What does not wait for a name is behavior. SQL injection announces itself in how an application responds to input: a boolean condition that flips the result set, a database error that spills structure, a deliberate delay that proves the query ran. Those signals are present the moment the flaw is, whether or not anyone has filed a CVE. Testing that reads them is testing that does not depend on the calendar.
Testing it the way it is attacked
An attacker probing GeoServer right now is not consulting a CVE database. They are sending filter expressions to a live endpoint and watching what comes back. That is dynamic testing, run without permission and pointed at other people's systems.
The defensive version is the same method aimed at your own running application first. Dynamic application security testing sends crafted input to the endpoints an application actually serves and classifies the responses for injection, the same behavioral evidence, gathered before an attacker gathers it. Because the signal is the application's behavior and not a version string, this is the kind of check that has something to say on day zero, when the recognition-based checks are still empty-handed.
NightVision runs SQL injection among its behavioral check classes, alongside the known-CVE template checks that matter once a vulnerability does have a name. The point is not that any single tool magically knows an unnamed endpoint on its own; it is that injection testing is behavioral by nature, so it does not sit idle waiting for a CVE to be minted. For a flaw like this one, that difference is the difference between finding it this week and reading about it next week.
| Detection approach | What it keys on | On day zero |
|---|---|---|
| Version and banner matching | A known-vulnerable release string | Nothing to match. No boundary is published yet. |
| Known-CVE template checks | A signature for a named CVE | Nothing to run. The template does not exist yet. |
| Behavioral injection testing | How the running app answers crafted input | Works. The signal is present the moment the flaw is. |
Once GeoServer ships a fix and the flaw earns a CVE, the recognition-based checks catch up and become the efficient way to confirm exposure at scale. Both halves matter. They just do not both work at the same time, and the order they come online in is the thing worth planning around.
A zero-day is, by definition, the window before there is anything to match. What still works in that window is asking the running application a question and reading its answer.
Related readingOn why running-application evidence outranks a version guess, see source-linked DAST. For a worked example of a fix that closed one payload and left the class open, read Patched Twice, Bypassed Twice. Both sit under What You Should Know About Application Security Testing.
Frequently asked questions
What is the GeoServer jsonArrayContains zero-day?
An unauthenticated SQL injection flaw in GeoServer, reachable through the jsonArrayContains filter expression in a standard OGC filter. A remote attacker with no credentials can inject SQL through a query parameter, and under certain database configurations the injection can escalate to remote code execution. It was disclosed on August 12, 2026, and drew active exploitation attempts within hours.
Is there a CVE or patch?
At disclosure there was neither. No CVE identifier had been assigned and no vendor fix was available, which is what made the window dangerous: exploitation began before there was anything to patch or any signature to match. Confirm the current CVE and patch status, and your affected version, against the official GeoServer and OSGeo advisories rather than any secondary summary, because that state changes quickly after a zero-day goes public.
How does the SQL injection work?
GeoServer translates an OGC filter into a SQL query against the backing datastore. When the jsonArrayContains expression is used against a String or JSON field on a PostGIS or Oracle datastore, attacker-controlled arguments are concatenated into that SQL without adequate escaping. The same function carried an earlier injection, CVE-2023-25157, in 2023. A fix that closes one payload shape does not close the class, and the 2026 flaw is a fresh instance of it.
Why can't signature-based scanning catch a zero-day like this?
Signature and version matching work by recognizing something already known: a CVE identifier, a vulnerable version string, a published detection template. On day zero none of those exist yet, so there is nothing to match. That is not a failing of scanning in general, it is a property of the timeline. The half of testing that recognizes known fingerprints has no fingerprint to recognize until after the fact.
Does this affect me if I run GeoServer?
If you operate an internet-reachable GeoServer instance backed by PostGIS or Oracle, treat it as exposed until you have confirmed your version against the vendor advisory and applied whatever mitigation is current. In the interim the standard guidance for an unpatched zero-day applies: restrict public network access and monitor for an official fix. The endpoint is reachable to an attacker the same way it is reachable to you, over the wire and without authentication.
How do you test for SQL injection without a known signature?
By behavior rather than by fingerprint. A dynamic test sends crafted input to a live endpoint and classifies how the application responds: a boolean condition that changes the result set, a database error that leaks structure, a deliberate time delay. None of that depends on a CVE or a version string existing. It is the same evidence an attacker relies on, gathered against your own running application first.