CORRECTION — the 2026-W33 weekly told readers GeoServer's exploited SQL injection had no vendor fix and that taking endpoints off the internet was the whole remediation; the fix had shipped two days earlier
UPDATE · originally covered 2026-W33 vulnerability status roll-up — eight flaws crossed into confirmed exploitation or the federal catalogue this week, two of them within seventy-two hours of their own disclosure, against a critical tail led by two unauthenticated CVSS 10.0 flaws in industrial edge devices (2026-08-16)
the correction is to a remediation instruction, so it is worth stating before the reasoning. GeoServer's actively exploited jsonArrayContains SQL injection had a vendor fix at the time the 2026-W33 weekly published, and the weekly said it did not.
OSGeo released three versions on 2026-08-14, each announced separately and each paired with the GeoTools release carrying the fix: 3.0.1, which "is made in conjunction with GeoTools 35.1, and GeoWebCache 2.0.1" (GeoServer project, 2026-08-14); 2.28.5, made in conjunction with GeoTools 34.5 (GeoServer project, 2026-08-14); and 2.27.6, made in conjunction with GeoTools 33.6 (GeoServer project, 2026-08-14). The advisory's structured record gives the three fixed ranges precisely: the org.geotools.jdbc:gt-jdbc-postgis module is affected from 35.0 before 35.1, from 34.0 before 34.5, and from 30.5 before 33.6, and the flaw now carries the identifier CVE-2026-76904, assigned when the advisory published on 2026-08-21 (OSV, 2026-08-21). Three W33 entries — the vulnerability status roll-up, the outlook, and the disclosure-to-exploitation piece — each recorded the flaw as having no CVE and no vendor patch, and the outlook went further, telling readers that until OSGeo shipped something, taking query endpoints off the public internet was the remediation.
Two things went wrong, and only one of them is about GeoServer. The reporting the weekly relied on was a 2026-08-14 news article headlined around an unpatched zero-day, published the same day as the vendor's release and therefore already stale as it went out; and the national advisory the weekly also cited did not append the fixed-version links until 2026-08-17, the day after the weekly. So both of the weekly's sources said "no patch" while the vendor's own release channel said otherwise. Nobody checked the release channel. A claim that no fix exists is a negative claim with an expiry date, and the only source that can carry it is the party that would ship the fix.
There is a second, still-live trap in the advisory itself: its human-readable patch summary names a different set of GeoTools versions than its own structured ranges and its linked release tags. A defender following the prose upgrades to versions that are not the fixes. Take the versions from the vendor's release announcements or the advisory's machine-readable ranges, both cited above.
GeoServer 3.0.1 is made in conjunction with GeoTools 35.1, and GeoWebCache 2.0.1.
Defender actions
- If a GeoServer estate was triaged off the 2026-W33 weekly, re-triage it: upgrade to GeoServer 3.0.1, 2.28.5 or 2.27.6 on the matching branch rather than relying on network isolation, and disregard any internal note recording this flaw as having no vendor fix.
ATT&CK mapping
1 technique mapped from the cited reporting · MITRE ATT&CK v19.2
Initial Access TA0001
T1190Exploit Public-Facing Application
Adversaries may attempt to exploit a weakness in an Internet-facing host or system to initially access a network. The weakness in the system can be a software bug, a temporary glitch, or a misconfiguration.
Sources
Update chain
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.