Geonetwork CVEs
5 CVEs, 1 exploited, 1 protected by Waratek
Overview 5 matches · 1 protected · 1 exploited · 0 CISA KEV · 1 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
1
20.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
4
80.0%
blocked by ARMR today
1
20.0%
partly blocked
0
0.0%
not blocked
4
80.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
1
20.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
4
80.0%
split by
peak 2 / quarter
Q1 251
No exploit published1
Medium1
not blocked1
No public exploit1
Q2 251
Protected by Waratek1
Critical1
blocked by ARMR today1
Exploited1
Q3 250
Q4 250
Q1 260
Q2 260
Q3 261
No exploit published1
Medium1
not blocked1
No public exploit1
Q4 262
No exploit published2
High2
not blocked2
No public exploit2
Q1 25Q2 25Q3 25Q4 25Q1 26Q2 26Q3 26Q4 26
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-46487 | High | 2026-11-03 | No exploit published | No public exploit | GeoNetwork is a catalog application to manage spatially referenced resources. From 4.0.0-alpha.1 until 4.2.16 and 4.4.11, the Elasticsearch-backed search proxy can skip GeoNetwork's access-control filter injection when a client request has an omitted query field. The request is then forwarded to Elasticsearch without group visibility, draft exclusion, record ownership, or portal-specific filtering. An unauthenticated remote attacker can use the affected public search API to retrieve the full indexed contents of metadata records that should not be publicly visible. This issue is fixed in versions 4.2.16 and 4.4.11. |
| CVE-2026-39379 | High | 2026-11-03 | No exploit published | No public exploit | GeoNetwork is a catalog application to manage spatially referenced resources. From 3.0.0 until 4.2.15 and 4.4.10, requesting a nonexistent or unauthorized service URL can cause an error page to reflect attacker-controlled request content inside an AngularJS application without adequately neutralizing it for template evaluation. A remote attacker can induce a victim, including an administrator, to open a crafted link so the reflected value is evaluated as an AngularJS template expression. Combined with known AngularJS sandbox-escape techniques, this can execute arbitrary JavaScript in the victim's authenticated browser session, disclose information, or perform actions as the victim. This issue is fixed in versions 4.2.15 and 4.4.10. |
| CVE-2026-53573 | Medium | 2026-07-31 | No exploit published | No public exploit | GeoNetwork is a catalog application to manage spatially referenced resources. From 3.12.0 until 4.2.16 and 4.4.11, unsafe redirect validation in GeonetworkOAuth2LoginAuthenticationFilter and KeycloakAuthenticationProcessingFilter permits an attacker-controlled external redirect after login. This issue is fixed in versions 4.2.16 and 4.4.11. |
| CVE-2025-30220 | Critical | 2025-06-10 | Protected by Waratek | Exploited | GeoServer is an open source server that allows users to share and edit geospatial data. GeoTools Schema class use of Eclipse XSD library to represent schema data structure is vulnerable to XML External Entity (XXE) exploit. This impacts whoever exposes XML processing with gt-xsd-core involved in parsing, when the documents carry a reference to an external XML schema. The gt-xsd-core Schemas class is not using the EntityResolver provided by the ParserHandler (if any was configured). This also impacts users of gt-wfs-ng DataStore where the ENTITY_RESOLVER connection parameter was not being used as intended. This vulnerability is fixed in GeoTools 33.1, 32.3, 31.7, and 28.6.1, GeoServer 2.27.1, 2.26.3, and 2.25.7, and GeoNetwork 4.4.8 and 4.2.13. |
| CVE-2024-32037 | Medium | 2025-02-11 | No exploit published | No public exploit | GeoNetwork is a catalog application to manage spatially referenced resources. In versions prior to 4.2.10 and 4.4.5, the search end-point response headers contain information about Elasticsearch software in use. This information is valuable from a security point of view because it allows software used by the server to be easily identified. GeoNetwork 4.4.5 and 4.2.10 fix this issue. No known workarounds are available. |