CVE-2026-40682 in OpenNLP
Summary
by MITRE • 05/04/2026
XML External Entity (XXE) via Unsanitized Dictionary Parsing in Apache OpenNLP DictionaryEntryPersistor
Versions Affected: before 2.5.9, before 3.0.0-M3
Description: The DictionaryEntryPersistor class initializes a static SAXParserFactory at class-load time without enabling FEATURE_SECURE_PROCESSING or disabling DTD processing. When create(InputStream, EntryInserter) is invoked, the only feature set on the XMLReader is namespace support — external entity resolution and DOCTYPE declarations remain fully enabled. An attacker who can supply a crafted dictionary file (e.g., a stop-word list or domain dictionary) containing a malicious DOCTYPE declaration can trigger local file disclosure via file:// entity references or server-side request forgery via http:// entity references during SAX parsing, before the application processes a single dictionary entry. This is inconsistent with the project's own XmlUtil.createSaxParser() helper, which correctly sets FEATURE_SECURE_PROCESSING and disallow-doctype-decl and is used by all other XML parsing paths in the codebase. The public Dictionary(InputStream) constructor delegates directly to this method and is the documented API for loading user-supplied dictionaries, making untrusted input a realistic scenario.
Mitigation: 2.x users should upgrade to 2.5.9. 3.x users should upgrade to 3.0.0-M3. Users who cannot upgrade immediately should ensure that all dictionary files are sourced from trusted origins and should consider wrapping the Dictionary(InputStream) constructor with input validation that rejects any XML containing a DOCTYPE declaration before it reaches the parser.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 06/29/2026
The vulnerability described represents a critical XML External Entity processing flaw in Apache OpenNLP's DictionaryEntryPersistor class, which falls under the category of CWE-611 Information Exposure Through Improperly Constructed XML Entities. This issue manifests when the application processes user-supplied dictionary files through the Dictionary(InputStream) constructor, creating a pathway for attackers to exploit XML parsing configurations that fail to properly restrict external entity resolution. The flaw occurs at the class initialization phase where a static SAXParserFactory is configured without security hardening measures, specifically omitting the FEATURE_SECURE_PROCESSING flag and proper DTD handling.
The technical implementation of this vulnerability stems from the DictionaryEntryPersistor's initialization pattern that establishes a SAXParserFactory with default security settings, allowing full processing of external entities and DOCTYPE declarations. When the create method executes with user-provided input, the XMLReader inherits these insecure configurations, enabling attackers to craft malicious dictionary files containing crafted DOCTYPE declarations that reference local files via file:// protocols or external resources through http:// protocols. This creates a vector for local file inclusion attacks where sensitive system files can be read and exfiltrated, or for server-side request forgery attacks that can be used to probe internal networks or exfiltrate data through outbound connections.
The operational impact of this vulnerability extends beyond simple information disclosure, as it represents a persistent attack surface that can be exploited by any user who can provide dictionary input to the application. The vulnerability affects both Apache OpenNLP 2.x and 3.x versions, with the specific versions 2.5.9 and 3.0.0-M3 being the first to include the necessary security fixes. This issue is particularly concerning because dictionary files are commonly used in natural language processing applications for stop-word lists, domain-specific terminology, and other linguistic resources, making untrusted input a realistic and common scenario in production environments. The attack vector is particularly dangerous because it requires no special privileges beyond the ability to provide dictionary files, and the exploitation occurs during the parsing phase before any application logic processes the dictionary entries.
The mitigation strategy addresses the core configuration issue by ensuring that the SAXParserFactory is properly configured with secure processing enabled, which aligns with ATT&CK technique T1213.002 for Data from Information Repositories. Organizations should prioritize upgrading to the patched versions as the primary remediation approach, as this addresses the root cause of the insecure XML processing configuration. For environments where immediate upgrades are not feasible, defensive measures include implementing input validation to reject XML documents containing DOCTYPE declarations before they reach the vulnerable parser, and ensuring all dictionary sources are trusted to prevent malicious input from entering the system. The fix implemented in the patched versions demonstrates proper security hardening practices that should serve as a model for similar XML processing components in other applications, particularly those handling user-supplied data through XML parsing mechanisms.