CVE-2025-48384 is a link following vulnerability in Git Git. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 August 2025, which means attackers have used it in real attacks. Git contains a link following vulnerability that stems from Git’s inconsistent handling of carriage return characters in configuration files.
How Git Link Following Vulnerabilities Work
A link following flaw in Git means the software can be tricked into resolving a path it should have treated as data, not as an instruction. In this CVE, the danger comes from inconsistent handling of carriage return characters in configuration files, which can change how a path is interpreted.
That matters because Git is often used in automated build, review and deployment workflows, so a parsing flaw in repository handling can become a trust-boundary problem rather than a local annoyance. If the tool follows an unexpected link, attackers may influence what gets read, written or executed during normal developer activity.
Why This Vulnerability Is Dangerous in Git
Git sits close to source code, build logic and developer credentials, so a parsing weakness can have outsized consequences. A malformed configuration path can lead Git to access attacker-chosen locations, exposing files, steering automation, or creating a foothold in systems that process untrusted repositories.
The practical risk is not only incorrect file handling, but also the possibility that repository content becomes a vehicle for broader compromise. When a source-control tool misreads paths, the impact can extend into CI/CD systems, developer workstations and adjacent secrets if those environments trust Git output or repository metadata.
How Organisations Check Exposure and Reduce It
Exposure checks should start with asset inventory, especially where Git is embedded in developer endpoints, build runners, container images and self-hosted automation. Teams should also identify where repositories are sourced from untrusted or external parties, because the attack surface grows when Git processes content that was not curated internally.
For version and patch details, readers should consult the vendor advisory and the NIST National Vulnerability Database or the CVE Program rather than relying on secondary summaries. Where patching is delayed, restrict untrusted repository handling, isolate build and review jobs, and limit the blast radius of any process that parses repository configuration.
Detection, Review and Follow-Up Actions
Detection should focus on abnormal Git activity around repository checkout, configuration parsing, unexpected file access and any workflow that reads from locations it should not normally reach. If exploitation is suspected, review recent repository interactions, automation logs and endpoint telemetry for evidence that Git processed attacker-controlled content.
Post-patch review matters because a fixed parser does not prove the environment was not already abused. If an attacker used the flaw to influence file access or automation, organisations may need to inspect related credentials, tokens, sessions or other secrets that could have been exposed during the window of compromise.
Risk and Threat Considerations
This kind of Git flaw is risky because source control tools are deeply trusted and often run with access to valuable code, secrets and automation context. A successful exploit can turn ordinary repository processing into a path for data exposure, workflow manipulation or downstream compromise.
Failure mechanism: Inconsistent parsing of carriage return characters can cause Git to follow a link or path it should not have accepted, letting attacker-controlled repository content influence file resolution.
Impact: Attackers may read sensitive files, redirect automation, or reach credentials and other secret material stored in developer and build environments.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Git parsing flaws are reduced by hardened software and workflow configuration. |
| CIS-10 — Malware Defenses | Compromised repositories can deliver malicious content through build and review workflows. | |
| Recommendation — Harden Git runners and developer endpoints to limit untrusted repository processing. Scan untrusted repositories and related artifacts for malicious content before execution. | ||
| NIST SP 800-53 Rev 5 | CM-6 — Configuration Settings | Carriage-return parsing weaknesses are controlled through secure configuration management. |
| SI-10 — Information Input Validation | The flaw stems from unsafe interpretation of repository input and path data. | |
| Recommendation — Enforce approved configuration settings for Git clients and build systems. Validate repository content before Git processes attacker-controlled paths. | ||
| NIST CSF 2.0 | PR.DS-1 — Data-at-rest is protected | Git repositories often contain source, secrets and other stored data that need protection. |
| Recommendation — Protect repository data and any stored secrets with appropriate access controls and encryption. | ||
Practitioner Guidance
What to watch for: Treat any repository fetched from an untrusted source, or any build job that processes unusual configuration content, as a higher-risk path. The key judgement is whether the Git instance is operating on content that could have been crafted to influence path handling rather than just source code.
Practitioner takeaway: For Git parsing flaws, the safest response is to combine rapid patching with environmental containment and a compromise review, because the likely harm is often broader than the parser bug itself.