GeoServer CVE-2025-27511
HIGHSeverity by source
AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Admin-only web UI action over network (AV:N, PR:H), no victim interaction (UI:N), reliable JNDI/deserialization gadget yields full RCE on the GeoServer process (C/I/A:H).
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
2DescriptionGitHub Advisory
Summary
Administrator can perform JNDI attack through specially crafted DB2 jdbc url leading to Remote Code Execution (RCE).
Impact
If GeoServer has DB2 extension installed, this vulnerability can lead to executing arbitrary code.
Details
Authenticated users can access Vector Data Sources page to creating a new data store through db2 jdbc connection, performing JNDI attack due to unrestricted connection parameters, and then achieve RCE with deserialization of untrusted data.
Remediation
This issue has been fixed in this release: https://github.com/geoserver/geoserver/releases/tag/2.27.0.
References
- https://osgeo-org.atlassian.net/browse/GEOT-7725
- https://nvd.nist.gov/vuln/detail/cve-2023-27867
AnalysisAI
Remote code execution in GeoServer (versions prior to 2.27.0) with the DB2 extension installed allows authenticated administrators to perform a JNDI injection attack via a crafted DB2 JDBC connection URL submitted through the Vector Data Sources page, ultimately triggering Java deserialization of untrusted data and arbitrary code execution. No public exploit identified at time of analysis, and the vulnerability is not on CISA KEV, but the attack pattern follows well-known JNDI/Log4Shell-style RCE techniques. Risk is meaningful only where the DB2 extension is deployed and an administrative account is reachable.
Technical ContextAI
GeoServer is an open-source Java server (built on GeoTools) for publishing geospatial data via OGC standards (WMS, WFS, WCS, etc.). The DB2 DataStore extension (Maven artifact org.geoserver.extension:gs-db2) registers a Vector Data Source backed by an IBM DB2 JDBC connection. The flaw is a CWE-74 injection: the extension does not restrict dangerous JDBC connection parameters, so an attacker can include JNDI-related parameters (e.g., directing the driver to a remote LDAP/RMI URL) that cause the JDBC layer to perform a JNDI lookup. The returned object is deserialized by the Java runtime, enabling arbitrary code execution via known gadget chains - the same root cause class as CVE-2023-27867 referenced in the advisory.
RemediationAI
Upgrade to GeoServer 2.27.0 or later, which restricts the connection parameters accepted by the DB2 data store and is the vendor-released patch (https://github.com/geoserver/geoserver/releases/tag/2.27.0, GHSA-g628-r368-6vh7). Where immediate upgrade is not feasible, remove the gs-db2 extension JARs from the GeoServer WEB-INF/lib directory to eliminate the vulnerable code path - note this disables all DB2 data stores and any layers depending on them. As a compensating control, restrict access to the GeoServer admin web UI (typically /geoserver/web) to a management VLAN or VPN, enforce strong unique administrator credentials, and disable any unused administrator accounts so that the PR:H precondition cannot be trivially satisfied. Setting the JVM property com.sun.jndi.ldap.object.trustURLCodebase=false (and the rmi equivalent) on modern JDKs reduces JNDI gadget reachability but is not a complete fix because deserialization can still occur via other classpath gadgets.
More from same product – last 7 days
Two-factor authentication bypass in syracom AG Secure Login (2FA) plugin 3.4.0.x for Atlassian Jira, Confluence, and Bit
Arbitrary file write in GeoServer's Master Password Dump web page allows an authenticated administrator to write attacke
Server-Side Request Forgery in GeoServer's XML entity resolution allows unauthenticated remote attackers to cause the se
Share
External POC / Exploit Code
Leaving vuln.today
GHSA-g628-r368-6vh7