Skip to content

Fix KMLReader XML parser security hole - #1204

Merged
dr-jts merged 1 commit into
locationtech:masterfrom
dr-jts:fix-kmlreader-security
Jun 17, 2026
Merged

Fix KMLReader XML parser security hole#1204
dr-jts merged 1 commit into
locationtech:masterfrom
dr-jts:fix-kmlreader-security

Conversation

@dr-jts

@dr-jtsdr-jts commented Jun 17, 2026•
edited
Loading

Copy link
Copy Markdown
Contributor

Fixes teh KMLReader usage of XML parser to avoid exposure to the XXE security hole.

The original report said:

We discovered that there’s lack of hardening for XXE for the KMLReader (jts-core).

Problem: The class initialises its XMLInputFactory via XMLInputFactory.newInstance() at field declaration (modules/core/src/main/java/org/locationtech/jts/io/kml/KMLReader.java and never sets SUPPORT_DTD or IS_SUPPORTING_EXTERNAL_ENTITIES. None of the four public constructors accept a caller-supplied factory either, so a consumer cannot harden it from outside.

Impact: This leads to an XXE vulnerability in a project depending on the KMLReader.

Potential fix: KML geometry has no legitimate use for DTDs or external entities, so this should not change behaviour for valid input.

@dr-jts
dr-jts merged commit 7f7cb3f into locationtech:masterJun 17, 2026
2 checks passed
@dr-jts
dr-jts deleted the fix-kmlreader-security branch June 17, 2026 21:57
@dr-jtsdr-jts changed the title Fix KMLReader XMLParser security holeFix KMLReader XML parser security holeJun 17, 2026
@NexoryNexory mentioned this pull request Aug 6, 2026
Open
Nexory added a commit to Nexory/jts that referenced this pull request Aug 24, 2026
@Nexory
Harden GMLReader against XXE (disable DTDs and external entities)
aae7aa2
GMLReader configured the SAX parser with only namespace-awareness and
validation disabled, leaving DOCTYPE processing and external entity
resolution enabled. GML is commonly read from untrusted sources (files,
WFS responses, uploads), so a crafted document could disclose local
files or trigger SSRF via an external entity (XXE).
Enable JAXP secure processing and disable DTDs and external entities on
the SAXParserFactory. There is no behaviour change for valid GML, and no
signature change (setFeature only throws SAXException subclasses, which
are already declared). This mirrors the KMLReader hardening in locationtech#1204.
Adds GMLReaderXXETest: without the fix the external entity is resolved
and a DOCTYPE is accepted; with it both are rejected and benign GML
still parses.
Signed-off-by: Nexory <St4yl3r30@hotmail.de>
@ppkarwaszppkarwasz mentioned this pull request Sep 3, 2026
Draft
Nexory added a commit to Nexory/jts that referenced this pull request Sep 3, 2026
@Nexory
Harden GMLReader against XXE (disable DTDs and external entities)
f8d0bc1
GMLReader configured the SAX parser with only namespace-awareness and
validation disabled, leaving DOCTYPE processing and external entity
resolution enabled. GML is commonly read from untrusted sources (files,
WFS responses, uploads), so a crafted document could disclose local
files or trigger SSRF via an external entity (XXE).
Enable JAXP secure processing and disable DTDs and external entities on
the SAXParserFactory. There is no behaviour change for valid GML, and no
signature change (setFeature only throws SAXException subclasses, which
are already declared). This mirrors the KMLReader hardening in locationtech#1204.
Adds GMLReaderXXETest: without the fix the external entity is resolved
and a DOCTYPE is accepted; with it both are rejected and benign GML
still parses.
Signed-off-by: Nexory <St4yl3r30@hotmail.de>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

jts-coretype-improvement

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@dr-jts