CVE-2026-41066

What it actually does

Prior to lxml 6.1.0, XML/HTML parsing in the default configuration can resolve external entities from local file URIs when processing untrusted XML input. An unauthenticated remote attacker who can submit XML to an application may craft a document with a DOCTYPE and external entity reference that causes the Python process to read local files and include their contents in parsed output, application responses, logs, or downstream processing. The primary impact is confidentiality loss; the vulnerability does not inherently provide code execution, data modification, or denial of service.

Why it matters to the business

Applications that accept XML from users, partners, APIs, uploads, message queues, or integrations may leak sensitive local files such as configuration files, environment variables, service account tokens, SSH keys, or application secrets. Even though this is not currently listed in CISA KEV and has low EPSS activity, exploitation is simple where XML input reaches lxml defaults, and compromise of secrets can lead to broader account, cloud, or application access.

How an attack unfolds

An attacker first identifies an endpoint, upload workflow, API, webhook, background job, or integration that accepts XML or XML-like content and is processed by a vulnerable lxml version. They submit a crafted XML document containing a DOCTYPE declaration with an external entity that points to a local file using a file:// URI. When the application parses the document with entity resolution enabled, lxml/libxml2 attempts to read the referenced local file from the application host or container. The attacker then causes the entity to be expanded into a field that the application returns, stores, logs, transforms, validates, or forwards. If successful, the attacker receives or later retrieves the file contents. They may repeat the process for high-value files such as environment variables, cloud credentials, Kubernetes service account tokens, application configuration, private keys, or host metadata available to the process.

How to fix it

Upgrade lxml to version 6.1.0 or later wherever it is installed, including direct dependencies, transitive dependencies, containers, serverless packages, CI images, and bundled application artifacts. If immediate upgrade is not possible, explicitly disable unsafe entity resolution in all parser construction paths by setting resolve_entities=False or resolve_entities='internal' for lxml parsers that process untrusted input. Do not rely on network blocking alone, because the vulnerable behavior reads local files via file://. Prefer safe XML parsing patterns, avoid parsing untrusted XML where possible, reject documents containing DOCTYPE declarations when not required, and run XML-processing services with least-privilege filesystem access and no unnecessary secrets mounted into the runtime environment.

How to confirm the fix worked

Confirm all runtime environments use lxml 6.1.0 or later with package inventory tools, dependency lockfile review, container image scans, and runtime checks such as importing lxml.etree and printing the installed version. Search source code for lxml parser construction and verify any parser that handles untrusted input explicitly sets resolve_entities=False or resolve_entities='internal'. In a non-production test environment, submit a harmless XML document that references a temporary canary file and confirm the content is not expanded, returned, logged, stored, or forwarded. Also test that XML containing DOCTYPE/external entity declarations is rejected or safely parsed according to application requirements.

Typical attack path

1. Find an application feature that accepts XML, XHTML, SVG, SOAP, SAML-like, Office/XML-derived, or uploaded XML content.
2. Confirm that submitted XML is parsed server-side by observing validation errors, transformed output, or reflected XML fields.
3. Send a benign DOCTYPE/entity payload to determine whether entity expansion is enabled.
4. Reference a predictable local file with an external entity, such as /etc/passwd, /proc/self/environ, or Windows system files.
5. Place the entity reference in a field that is returned, logged, transformed, or stored by the application.
6. Retrieve exposed file contents from the HTTP response, generated document, application log, downstream queue, or later workflow output.
7. Use disclosed secrets or configuration data to attempt lateral movement, credential theft, cloud access, or further application compromise.

How to detect it

Review HTTP access logs, API gateway logs, WAF events, application request bodies, upload records, message queue payloads, and XML parser error logs for DOCTYPE declarations, external entity definitions, and file:// references. Focus on endpoints that accept XML, SOAP, SVG, XHTML, SAML-like content, document uploads, or partner integration payloads. Look for suspicious attempts to read common sensitive files such as /etc/passwd, /proc/self/environ, cloud credential files, Kubernetes service account tokens, SSH keys, application configuration files, and Windows system files. Check application responses, generated documents, stored records, audit logs, and downstream messages for leaked file contents. Use EDR or host telemetry to identify Python, uWSGI, Gunicorn, Celery, worker, or application processes unexpectedly opening sensitive local files during XML parsing. Because exploitation may leave no dedicated lxml log entry, detection is strongest when request payload logging, WAF body inspection, parser exception logs, and file-access telemetry are correlated by timestamp and source address.

• <!DOCTYPE
• <!ENTITY
• SYSTEM "file://
• SYSTEM 'file://
• file:///etc/passwd
• file:///etc/shadow
• file:///proc/self/environ
• file:///proc/self/cmdline
• file:///proc/version
• file:///var/run/secrets/kubernetes.io/serviceaccount/token
• file:///root/.ssh/id_rsa
• file:///home/
• file:///app/.env
• file:///run/secrets/
• file:///C:/Windows/win.ini
• file:///C:/Windows/System32/drivers/etc/hosts
• &xxe;
• %xxe;
• failed to load external entity
• Entity 'xxe' not defined
• DOCTYPE is disallowed
• StartTag: invalid element name

What your security team should do

• Prioritize upgrading all affected Python applications and images to lxml 6.1.0 or later, especially internet-facing XML APIs, file upload services, SOAP/SAML processors, partner integrations, and background jobs processing untrusted messages.
• Inventory where lxml is present directly or transitively using SCA, lockfiles, SBOMs, container scans, and runtime package inspection.
• Add secure parser configuration requirements to code review and static analysis: untrusted XML parsing must use resolve_entities=False or resolve_entities='internal'.
• Deploy WAF/API gateway and application-level detections for XML requests containing DOCTYPE, ENTITY, and file:// references where those constructs are not business-required.
• Review application, API, WAF, object storage, message queue, and EDR telemetry for evidence of XXE payloads and unusual local file reads by Python application processes.
• Reduce blast radius by removing unnecessary secrets from filesystems, restricting service account tokens, limiting container mounts, and enforcing least privilege for application processes.
• If evidence of exploitation is found, rotate exposed credentials and secrets that may have been readable by the affected process.