Raw vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HSummary
CVE-2024-36401 is a critical-severity Eval Injection (CWE-95) vulnerability in Geotools Geotools. Its CVSS base score is 9.8 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique JavaScript (T1059.007); ranked in the top 0.0% of CVEs by exploit likelihood; CISA has added it to the Known Exploited Vulnerabilities catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SI-10 (Information Input Validation) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
GeoServer is an open source server for sharing and editing geospatial data that is affected by CVE-2024-36401 in all installations prior to versions 2.22.6, 2.23.6, 2.24.4, and 2.25.2. The root cause lies in the GeoTools library, which passes feature-type property names to the commons-jxpath component for XPath evaluation; this logic was intended only for complex feature types but is incorrectly applied to simple feature types as well, enabling remote code execution when attacker-controlled values are processed.
Unauthenticated remote attackers can supply crafted OGC request parameters over WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic, or WPS Execute endpoints. Because the server evaluates these inputs as XPath expressions without authentication or additional restrictions, successful exploitation yields arbitrary code execution on the underlying host with a CVSS score of 9.8.
Official advisories from the GeoServer and GeoTools projects recommend immediate upgrade to the listed patched releases. As a workaround, administrators may delete the gt-complex-x.y.jar file from the GeoServer installation, although this can disable required functionality or prevent startup when the module is needed. The associated EPSS score remains high, with a current value of 0.9443 and a recorded peak of 0.9618.
OWASP Top 10 for Web (2025)
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2024-2280
Vulnerability Data
GeoServer is an open source server that allows users to share and edit geospatial data. Prior to versions 2.22.6, 2.23.6, 2.24.4, and 2.25.2, multiple OGC request parameters allow Remote Code Execution (RCE) by unauthenticated users through specially crafted input against…
more
a default GeoServer installation due to unsafely evaluating property names as XPath expressions. The GeoTools library API that GeoServer calls evaluates property/attribute names for feature types in a way that unsafely passes them to the commons-jxpath library which can execute arbitrary code when evaluating XPath expressions. This XPath evaluation is intended to be used only by complex feature types (i.e., Application Schema data stores) but is incorrectly being applied to simple feature types as well which makes this vulnerability apply to **ALL** GeoServer instances. No public PoC is provided but this vulnerability has been confirmed to be exploitable through WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic and WPS Execute requests. This vulnerability can lead to executing arbitrary code. Versions 2.22.6, 2.23.6, 2.24.4, and 2.25.2 contain a patch for the issue. A workaround exists by removing the `gt-complex-x.y.jar` file from the GeoServer where `x.y` is the GeoTools version (e.g., `gt-complex-31.1.jar` if running GeoServer 2.25.1). This will remove the vulnerable code from GeoServer but may break some GeoServer functionality or prevent GeoServer from deploying if the gt-complex module is needed.
- CWE(s)
- KEV Date Added
- 15 July 2024
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Control response
—
—
—
V1.3.1V1.3.2
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and code analysis can discover eval-injection flaws but does not stop their introduction.
Input validation explicitly requires neutralizing untrusted data before it reaches dynamic evaluation constructs such as eval.
Least privilege limits the damage an injected code fragment can perform once executed.
Secure-development standards and tools can mandate safe coding patterns that avoid unsafe dynamic evaluation.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices directly require input neutralization and avoidance of unsafe dynamic evaluation.
PR.DS-10 protects runtime data confidentiality/integrity but has no bearing on neutralizing externally influenced input during code generation, so neither direction shows any preventive effect.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development can detect eval injection vulnerabilities before deployment.
Secure development life cycle mandates input validation and safe coding practices that directly prevent eval injection.
Application security requirements include rules against dynamic code execution of untrusted input.
Secure architecture principles discourage unsafe dynamic evaluation constructs.
Secure coding explicitly requires neutralization of input before dynamic evaluation, directly mitigating eval injection.
Separation of environments limits the blast radius if eval injection occurs in non-production.