LangChain Text Splitters CVE-2025-6985

Exploitation requires the hosting application to use the HTMLSectionSplitter class in langchain-text-splitters 0.3.8 AND to permit attacker-influenced custom XSLT stylesheets, which are processed by lxml.etree.parse()/lxml.etree.XSLT() without XSLTAccessControl hardening. Severity of the primitive depends on the lxml version: lxml up to 4.9.x resolves external entities by default (full XXE file read and outbound HTTP(S) fetch), while lxml 5.0+ disables entity expansion but still allows the XSLT document() function to read arbitrary URIs unless XSLTAccessControl is applied. The key limiting factor is deployment design: if the application never exposes custom/user-supplied XSLT to the splitter, the vulnerable path is not reachable. No authentication, special privileges, or user interaction are required once that path is exposed.

Signals are mostly aligned toward moderate, conditional risk rather than urgent priority. The CVSS 3.0 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5 High) describes a network-reachable, unauthenticated, low-complexity information-disclosure flaw with high confidentiality impact but no integrity or availability impact - consistent with an XXE file-read primitive. However, that score assumes the attacker can reach the vulnerable code path, which the description itself qualifies: exploitation applies to 'default deployments that enable custom XSLT,' meaning the hosting application must expose arbitrary attacker-controlled XSLT stylesheets to HTMLSectionSplitter. This is an important caveat the raw CVSS does not capture. The EPSS score is low (0.51%, 42nd percentile), the CVE is NOT in CISA KEV, and no exploit is explicitly flagged in the input, so there is no evidence of active or widespread exploitation. The single reference is a huntr.dev bug-bounty submission, which typically includes reproduction detail, but POC status is not confirmed in the provided data. Net: a genuine, verifiable confidentiality weakness in a popular library, but real-world risk is gated by whether a given application passes untrusted XSLT into the splitter - more a latent integration risk than a broadly wormable issue. Note also the CVSS 3.0 impact of C:H with I:N/A:N accurately reflects read-only file/SSRF access rather than code execution.

An application that uses langchain-text-splitters 0.3.8 and lets users supply or influence a custom XSLT stylesheet for HTMLSectionSplitter accepts an attacker-crafted stylesheet containing an external entity or a document() reference. When lxml.etree.parse()/XSLT() processes it without XSLTAccessControl hardening, the parser resolves the external URI, returning the contents of a local file (e.g. ~/.ssh/id_rsa, .env) or performing an outbound fetch to cloud metadata endpoints. No authentication or user interaction is required; the data is reflected back or exfiltrated to an attacker-controlled host. A huntr.dev bounty report exists, but a public weaponized exploit is not confirmed in the provided data.