CVE-2022-24818

8.2 HIGH

📋 TL;DR

CVE-2022-24818 is a JNDI injection vulnerability in GeoTools that allows remote code execution when user-controlled JNDI strings are processed. Similar to Log4Shell, it enables attackers to load malicious classes via LDAP/RMI protocols. Affected are applications using vulnerable GeoTools versions that accept external JNDI input, particularly those with admin interfaces.

💻 Affected Systems

Products:
  • GeoTools Java library
Versions: All versions before 26.4, 25.6, and 24.6
Operating Systems: All platforms running Java
Default Config Vulnerable: ⚠️ Yes
Notes: Vulnerability requires JNDI lookup functionality to be accessible and user-provided JNDI strings to be processed.

📦 What is this software?

⚠️ Risk & Real-World Impact

🔴

Worst Case

Full server compromise with arbitrary code execution leading to data theft, lateral movement, and complete system control.

🟠

Likely Case

Limited code execution within application context due to admin authentication requirement, potentially allowing data access or further privilege escalation.

🟢

If Mitigated

No impact if JNDI input is properly validated or restricted, or if vulnerable components aren't exposed.

🌐 Internet-Facing: MEDIUM - Requires admin authentication but could be exploited if credentials are compromised or through other vulnerabilities.
🏢 Internal Only: MEDIUM - Internal attackers with admin access could exploit, but requires specific JNDI input capability.

🎯 Exploit Status

Public PoC: ⚠️ Yes
Weaponized: LIKELY
Unauthenticated Exploit: ✅ No
Complexity: MEDIUM

Exploitation requires admin authentication but follows similar patterns to Log4Shell. Public advisories include technical details.

🛠️ Fix & Mitigation

✅ Official Fix

Patch Version: GeoTools 26.4, 25.6, or 24.6

Vendor Advisory: https://github.com/geotools/geotools/security/advisories/GHSA-jvh2-668r-g75x

Restart Required: Yes

Instructions:

1. Identify GeoTools version in your application. 2. Upgrade to patched version (26.4, 25.6, or 24.6). 3. Rebuild and redeploy application. 4. Restart application server.

🔧 Temporary Workarounds

Restrict JNDI Input

all

Configure applications to reject or sanitize user-provided JNDI strings

Application-specific configuration - no universal command

Network Segmentation

linux

Block outbound LDAP/RMI from application servers to prevent JNDI callbacks

iptables -A OUTPUT -p tcp --dport 389 -j DROP
iptables -A OUTPUT -p tcp --dport 1099 -j DROP

🧯 If You Can't Patch

  • Implement strict input validation to reject any user-provided JNDI strings
  • Disable or remove JNDI lookup functionality in application configuration

🔍 How to Verify

Check if Vulnerable:

Check pom.xml or build.gradle for GeoTools dependency version below 26.4, 25.6, or 24.6

Check Version:

grep -i geotools pom.xml || grep -i geotools build.gradle

Verify Fix Applied:

Confirm GeoTools version is 26.4+, 25.6+, or 24.6+ in dependency files

📡 Detection & Monitoring

Log Indicators:

  • Unusual JNDI lookup patterns
  • LDAP/RMI connections from application process
  • Class loading errors for unexpected classes

Network Indicators:

  • Outbound LDAP (389/tcp) or RMI (1099/tcp) from application servers
  • DNS requests for suspicious JNDI URLs

SIEM Query:

source="application.logs" AND ("JNDI" OR "InitialContext" OR "lookup")

🔗 References

📤 Share & Export