The built-in catalog introduced by JDK-8306055 can result in the same instance of CatalogImpl being used by multiple threads. Since catalog resolution involves mutating catalog instances, this is a thread-safety issue.

This small program serves to illustrate this issue:

    static final String DOC = """
        <?xml version="1.0" encoding="UTF-8"?>
        <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd">
        <properties>
        <entry key="foo">bar</entry>
        </properties>
        """;

    public static void main(String[] args) throws Exception {
        InputStream is = new ByteArrayInputStream(DOC.getBytes(StandardCharsets.UTF_8));
        Document doc = DocumentBuilderFactory.newInstance()
                                             .newDocumentBuilder()
                                             .parse(is);
    }

If multiple threads were to invoke this code, they'd use separate factory, parser, entity manager, and catalog resolver instances. However, they will end up sharing a single instance of the CatalogImpl that represents the built-in JDK catalog.

The single instance is obtained via the expression

    JdkXmlConfig.getInstance(false).getJdkCatalog()

in the getJDKCatalogResolver() method of XMLSecurityManager.java, around line 325. Multiple operations on this instance are performed by the resolve() method of Util.java, lines 77-83. Each of the reset(), resolve(), and markAsSearched() methods potentially mutates state of the catalog.

The state being mutated is relative to a resolution operation being performed, not the catalog itself. A potential solution is thus to refactor the state out of the catalog, rendering it immutable, and thus sharable across threads.