Yes. CISA added CVE-2025-48384 to its Known Exploited Vulnerabilities catalogue on 25 August 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Git contains a link following vulnerability that stems from Git’s inconsistent handling of carriage return characters in configuration files. Any organisation running the affected product should treat remediation as urgent.
How to confirm whether Git Link Following is being exploited
CISA’s KEV listing is the fastest practical signal here: if a CVE appears in that catalogue, you should assume active exploitation is credible and treat exposure as real, not theoretical. For Git Link Following, the immediate question is whether your Git estate includes the affected configuration pattern, whether any reachable repositories or build jobs process untrusted content, and whether defenders have already seen unusual repository access or config changes.
Git-side abuse is often easiest to miss in mixed developer and CI environments because the vulnerable behavior can be triggered through ordinary repository workflows, configuration handling, or automation paths that teams do not monitor as closely as production services. That is why exposed repositories, mirrored forks, build runners, and internal tooling that parse Git configuration deserve the same triage priority as externally exposed applications.
When a vulnerability is already in KEV, the right posture is to verify exposure first and then assume exploitation pressure may exist even if you have not seen an obvious alert yet. Organisations should not wait for public proof-of-concept traffic before searching for signs of abnormal Git activity, repository tampering, or unintended file or link resolution in the paths that handle source control data.
What remediation should look like while exploitation is active
Because CISA has marked the issue as actively exploited, remediation is urgent rather than routine. The first step is to identify every Git instance, appliance, container image, developer workstation, and automation runner that could process the vulnerable configuration behavior, then apply the vendor’s fix or approved mitigation as soon as it is available for that exact product version.
Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for authoritative version and remediation details instead of relying on secondary summaries. If patching requires coordination, isolate the most exposed Git services first, reduce write access where possible, and remove or disable any workflow that lets untrusted content reach the vulnerable path.
For teams with build pipelines or developer tooling wired directly to Git, remediation should include the surrounding automation, not just the server package. A fix that leaves cloned repositories, credentialed runners, or custom hooks untouched can still leave a practical attack path open even after the binary or package is updated.
How to assess blast radius and possible compromise
Once exposure is confirmed, check whether repository content, configuration files, or automation logs show signs of unexpected modification. If the vulnerable behavior could have been used to influence what a Git process reads or follows, examine whether that access was used to reach secrets, alter pipelines, or change the execution context of any build or deployment job.
The most useful hunting questions are simple: did anything change that should not have changed, did any job execute with a different trust boundary than expected, and did any automation inherit permissions from content that should have been treated as untrusted? That review should include recent commits, hook changes, runner activity, credential use, and unusual repository traversal or configuration lookups.
If you find evidence that the flaw may have exposed credentials, sessions, or deployment material, rotate those secrets quickly and invalidate any tokens or service credentials that could have been reachable from the affected Git path. NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is useful here because the post-patch question is not only whether the CVE is fixed, but whether anything adjacent was already compromised.
Risk and Threat Considerations
Actively exploited Git flaws are dangerous because they sit at the boundary between source control, automation, and secret-bearing workflows. Even when the direct vulnerability seems narrow, the downstream impact can spread into build systems, deployment pipelines, and developer trust chains very quickly.
Failure mechanism: A link following or configuration-handling flaw can let an attacker influence what Git reads or resolves, turning trusted repository processing into an access path to files, secrets, or execution context.
Impact: That can expose credentials, alter CI/CD behavior, or create persistent compromise if attackers plant changes that survive normal patching or are reintroduced by automation.
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-16 — Application Software Security | Git exploitation often reaches build and source-control workflows that need secure handling. |
| Recommendation — Harden source-control and build workflows so vulnerable Git paths cannot be abused to influence execution. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This is an exploited vulnerability that requires urgent remediation and verification. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation and ongoing hunting depend on scanning and vulnerability visibility. | |
| Recommendation — Apply the fix promptly and verify remediation across all Git instances and dependent automation. Identify affected Git assets, scan for exposure, and monitor for residual vulnerable instances. | ||
| NIST CSF 2.0 | DE.CM-09 — Monitoring for Unauthorized Personnel, Connections, Devices, Software, and Malicious Code | Active exploitation warrants monitoring for abnormal repository and automation behavior. |
| RS.MI-01 — Incidents are contained | If exploitation is suspected, containment actions must limit spread through source control and automation. | |
| Recommendation — Monitor Git and CI/CD activity for unauthorized changes and suspicious repository processing. Contain affected Git services and automation before attacker-controlled repository content can spread further. | ||
Practitioner Guidance
What to prioritise: Triage every Git service, runner, and developer environment that can process untrusted repository content before you spend time on broad hunting. If the vulnerable path is reachable from automation, treat the blast radius as larger than the Git server alone.
What to verify: Confirm whether any secrets, deploy keys, or pipeline credentials were accessible through the affected path, then validate whether those credentials were used after the exposure window. If you cannot prove they were not reachable, rotate them.
Decision rule: If patching is delayed, reduce exposure by restricting repository inputs, disabling high-risk workflows, and tightening access to automation accounts. If you already see unusual repository mutations or runner activity, move immediately to compromise assessment rather than waiting for a full patch cycle.
Practitioner takeaway: For an exploited Git flaw, remediation is only half the job; the real decision is whether the repository ecosystem, not just the software package, must be treated as potentially compromised.