Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Java: `java/xxe` doesn't cover public XML helper methods that parse caller-provided input

Open
#21,774 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
java
Domain
security

Research direction

Start with the java/xxe query and its existing parser-construction sink and safe-configuration modeling. Check coverage for public helpers that pass InputStream, String, Reader, or URL values to DocumentBuilderFactory.parse, then compare similar SAXParserFactory and XMLInputFactory entry points. Done means tests demonstrate findings for the described helper shape and trivial wrappers without losing existing results.

Written by the indexing model from the issue text.

Description

This looks like a gap in java/xxe around library-style XML helpers. If a public helper takes caller-provided XML as an InputStream, String, Reader, or URL, builds a DocumentBuilderFactory without XXE hardening, and then calls newDocumentBuilder().parse(...), I wouldn't expect that to fall out of coverage.

CodeQL already seems to model the parser sink and the usual safe configs here, and it still finds other java/xxe results in the same codebase, so this doesn't look like a missing sink or a failed analysis. It looks more like these public parsing entry points are not treated as strong enough sources for this query. That's a pretty normal pattern in SDK helpers, XML utility classes, metadata loaders, and config parsers, where the trust boundary is the method parameter rather than a controller or request object.

The aws-sdk-android fix for CVE-2022-4725 is a good example: both RegionMetadataParser.parse(InputStream) and XpathUtils.documentFrom(...) were fixed by adding the standard DocumentBuilderFactory hardening.

Semgrep's documentbuilderfactory-disallow-doctype-decl-missing rule catches the same shape by reusing the existing parser-construction sink and checking for missing hardening, which makes this seem like a fairly local modeling issue.

My guess is that java/xxe could cover this by recognizing public parse helpers that feed caller-controlled XML directly, or through trivial wrappers, into the existing XXE sinks. I would expect the same hole to show up for similar helper methods built around SAXParserFactory and XMLInputFactory too.

import java.io.InputStream;
import javax.xml.parsers.DocumentBuilderFactory;

class XmlHelper {
    public static void parse(InputStream in) throws Exception {
        DocumentBuilderFactory f = DocumentBuilderFactory.newInstance();
        var b = f.newDocumentBuilder();
        b.parse(in);
    }
}
Dominant language
CodeQL
Stars
10.1k
Forks
2.1k
Avg merge
2d 16h
Merged PRs (30d)
143

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from github/codeql

All issues in github/codeql

Similar issues

More Security issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.