CVE-2025-4949

What it actually does

Eclipse JGit 7.2.0.202503040940-r and earlier parse XML in two code paths without safely disabling external entity resolution: the repo command ManifestParser and the experimental amazons3 Git transport AmazonS3 implementation. If an attacker can cause an affected application, CI system, Git service, or automation component to parse a malicious XML manifest or related amazons3 transport XML, the XML parser may resolve attacker-defined external entities. This can disclose local files or environment-derived data accessible to the JGit process, trigger outbound network requests for blind data exfiltration or internal network probing, and potentially cause denial of service through expensive XML entity expansion or blocking external resource retrieval.

Why it matters to the business

Organizations using JGit in source-code management, build automation, developer tooling, or services that process repository manifests may expose sensitive files, credentials, metadata, or internal network details if untrusted XML is parsed. Operationally, exploitation could disrupt CI/CD jobs or repository operations through XML parsing failures or resource exhaustion. The issue is not currently in CISA KEV, has low EPSS probability, and has no reported mature public exploit in the provided data, but it has been public for an extended period and should be remediated as part of dependency hygiene, especially where JGit processes externally supplied repositories or manifests.

How an attack unfolds

An attacker first identifies a workflow where affected JGit code parses XML they can influence, such as a repository manifest consumed by the repo command integration or an experimental amazons3 Git transport configuration. They craft XML containing a DOCTYPE declaration with an external entity that references a local file, cloud metadata endpoint, internal URL, or attacker-controlled callback server. When the vulnerable JGit parser processes the XML, it attempts to resolve the external entity. Depending on how parsed data is surfaced, the attacker may receive file contents through application output, parser errors, generated requests to their server, or secondary application behavior. If direct data return is not available, the attacker may still use blind XXE techniques to force DNS or HTTP callbacks, confirm access to internal resources, or cause parsing delays and resource consumption. Successful impact depends heavily on whether untrusted XML reaches these JGit parsing paths and on the privileges, filesystem access, network egress, and runtime environment of the JGit process.

How to fix it

Upgrade Eclipse JGit to a release that contains the upstream fix, or build from a version including commit 4de5c79bcd1af1c5b0282d559d1a011f178893de. Treat 7.2.0.202503040940-r and older as affected. Where dependency managers are used, update all direct and transitive org.eclipse.jgit artifacts and rebuild applications, plugins, CI images, and developer tooling that package JGit. If immediate upgrade is not possible, mitigate by disabling or restricting workflows that parse untrusted repo manifests or use the experimental amazons3 transport, rejecting XML containing DOCTYPE or ENTITY declarations before it reaches JGit, running affected processing in a low-privilege sandbox, blocking unnecessary egress from build and SCM systems, and disabling XML external entity resolution in any surrounding custom XML parsing code.

How to confirm the fix worked

Inventory affected software with SBOM, dependency scanning, build manifests, JAR inspection, and runtime classpath checks for org.eclipse.jgit versions at or below 7.2.0.202503040940-r. Confirm the remediated artifact includes upstream commit 4de5c79bcd1af1c5b0282d559d1a011f178893de or a later official release containing it. In test environments, process a benign XML canary containing a DOCTYPE and an external entity pointing to an internal test callback endpoint; the fixed system should reject the XML or process it without making outbound DNS/HTTP requests and without expanding the entity. Validate that repo manifest workflows and amazons3 transport usage still function after upgrade. Also verify network controls by confirming JGit-based build or SCM workers cannot make unnecessary outbound requests to arbitrary destinations.

Typical attack path

1. Find an application, CI/CD job, Git service, or developer tool that embeds Eclipse JGit 7.2.0.202503040940-r or older.
2. Identify whether the target uses JGit repo manifest parsing or the experimental amazons3 Git transport XML parsing path.
3. Submit or cause ingestion of a malicious XML manifest/configuration containing a DOCTYPE and external entity declaration.
4. Reference sensitive local files, environment paths, cloud metadata services, internal URLs, or an attacker-controlled HTTP/DNS endpoint in the entity definition.
5. Wait for the affected JGit parser to resolve the entity during repository or transport processing.
6. Collect leaked data from application output, error messages, generated files, logs, or attacker-controlled callback infrastructure, or use callbacks to infer internal access.
7. Optionally repeat with larger entity payloads or slow external resources to degrade service availability.

How to detect it

To assess prior exploitation, review application, SCM, CI/CD, build-worker, and developer-tool logs for XML parsing activity involving repo manifests or amazons3 transport configuration that contains DOCTYPE or ENTITY declarations. Inspect repository submissions, pull requests, imported manifests, workspace files, and build artifacts for XML external entity payloads. Check DNS, proxy, firewall, and EDR telemetry for unexpected outbound requests from Git, Java, build, or CI processes to unfamiliar domains immediately after repository synchronization or manifest parsing. Look for attempted access to sensitive local paths such as /etc/passwd, /proc/self/environ, cloud credential files, SSH keys, or cloud metadata endpoints. Java logs may show SAXParseException, XML parser errors, external entity resolution failures, blocked outbound connections, or file-not-found messages referencing entity targets. Because XXE exploitation can be blind and may only produce outbound DNS/HTTP callbacks, absence of application errors does not prove absence of exploitation; correlate suspicious XML inputs with egress telemetry and process/file access records.

• <!DOCTYPE
• <!ENTITY
• SYSTEM "file://
• SYSTEM 'file://
• PUBLIC "-//
• file:///etc/passwd
• file:///etc/shadow
• file:///proc/self/environ
• file:///proc/self/cmdline
• file:///root/.ssh/id_rsa
• file:///home/
• file:///var/run/secrets/
• http://169.254.169.254/latest/meta-data/
• http://169.254.169.254/latest/user-data/
• http://metadata.google.internal/
• http://169.254.169.254/metadata/instance
• %xxe;
• &xxe;
• SAXParseException
• External Entity
• DOCTYPE is disallowed
• accessExternalDTD
• repo manifest
• ManifestParser
• amazons3://
• AmazonS3

What your security team should do

• Prioritize patching systems that process repository content, manifests, or Git transport inputs from external contributors, vendors, public repositories, or other untrusted sources.
• Update all embedded Eclipse JGit copies, including those shaded into applications, plugins, CI/CD runners, IDE tooling, build containers, and self-hosted Git services.
• Search code and configuration for use of JGit repo ManifestParser and the experimental amazons3 transport; disable the amazons3 transport if it is not required.
• Add XML input validation for repository manifests and transport configuration files to reject DOCTYPE, ENTITY, SYSTEM, and PUBLIC declarations where they are not explicitly required.
• Restrict outbound DNS and HTTP/HTTPS egress from SCM, CI/CD, and build workers to approved destinations to reduce blind XXE exfiltration impact.
• Run affected JGit workloads with least privilege and avoid exposing secrets, cloud credentials, and sensitive host files to repository-processing processes.
• Review recent logs and repository submissions for malicious XML patterns and unexplained outbound requests from systems that used vulnerable JGit versions.
• Track this as a dependency remediation item rather than an emergency KEV response unless local exposure includes untrusted XML parsing in sensitive or internet-facing workflows.