How do you patch or mitigate CVE-2025-48384 (Git Link Following)?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

CISA's required action for CVE-2025-48384 is to apply mitigations per vendor instructions, follow applicable BOD 22-01 guidance for cloud services, or discontinue use of the product if mitigations are unavailable. In practice, find every instance of Git Git in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service.

What “patch or mitigate” means for CVE-2025-48384

For a KEV-listed flaw like this, the practical order is exposure first, remediation second, and compensating controls if remediation cannot happen immediately. Start by locating every Git Git instance, then confirm whether it is internet-facing, remotely reachable, or embedded in a cloud service that inherits the same exposure. The vendor security update or documented mitigation is the preferred fix path.

For CVE-driven response, the vendor advisory and the KEV record are the authoritative sources for the exact fix and any product-specific workarounds. If a documented mitigation exists, it should be treated as temporary risk reduction, not a substitute for the patch, especially when the vulnerable system is exposed to untrusted networks.

If the product cannot be remediated, the control objective changes from “patch it” to “remove the attack path.” That usually means taking the service out of internet reach, tightening access to trusted administrative paths only, or discontinuing use of the product until a fix can be applied. The NIST Cybersecurity Framework 2.0 and the NIST SP 800-207 Zero Trust Architecture both support that shift from implicit trust to verified, constrained access.

Because this is a Git exposure issue, the most useful outcome is not just “patched” but “no longer reachable in a way that lets the flaw matter.” In practice that means reviewing how repositories, mirrors, developer tooling, and automation servers are published, because a partially fixed system that remains broadly exposed still leaves room for exploitation or follow-on abuse. The CISA Known Exploited Vulnerabilities Catalog is the right place to confirm the remediation urgency and required action.

How to validate that the mitigation actually worked

After applying the update or mitigation, re-scan the estate and verify that every instance of the product has either been fixed or placed behind a compensating control. Validation should include the asset record, the network exposure state, and the administrative path, because a vulnerability that is still deployed but no longer visible is only partially addressed.

Where the product supports it, test from the same access paths an attacker would use, not only from a trusted internal segment. That is the fastest way to confirm whether the mitigation is real or only documented. The NIST National Vulnerability Database helps with record-level confirmation, while the FIRST EPSS can support prioritisation when multiple vulnerable assets compete for attention.

If you have cloud-hosted or managed Git services in scope, check whether the provider has already applied the vendor mitigation or whether you still own the exposure through configuration, tenancy, or access control. In cloud environments, the decision to rely on a provider control is only sound if you have positively verified that the service version, network policy, and tenant exposure all match the expected mitigated state.

When the patch is in place, keep a short record of what was changed, what was verified, and what remains exceptional. That evidence matters if you later need to show why the product stayed online during the response window, or why it was removed from service instead of being left exposed.

When you need to wait for a fix

If patching must wait, use the waiting period to reduce blast radius, not to delay decision-making. The safest temporary posture is to limit who can reach the service, segment it from broader administrative networks, and remove any unnecessary public exposure. If the product is customer-facing or externally reachable, treat that as an exception requiring explicit risk acceptance.

Mitigation only works if it is operationally enforced. That means the access restriction must survive restarts, scaling events, image rebuilds, and cloud redeployments. Temporary firewall rules or ad hoc changes are weak compensations unless they are tracked, time-bounded, and reviewed.

For broader vulnerability response discipline, the Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide are useful reference points for emergency prioritisation, compensating controls, and post-patch verification.

Risk and Threat Considerations

Git-related flaws are especially dangerous when the service is exposed to untrusted networks, because the same weakness can move from a targeted issue to an estate-wide risk very quickly. The main danger is not only code execution or improper access, but the chance that repository data, credentials, or administrative functions become reachable before defenders can intervene.

Failure mechanism: Attackers exploit the reachable Git service before a patch is available, or they abuse the window where the product remains deployed but only partially mitigated. If the service is internet-facing, the attack path is usually simpler and the time to compromise is shorter.

Impact: Compromise can expose source code, configuration data, secrets, or downstream systems that trust the Git service. Even when the initial flaw is contained, attackers may use the resulting access to pivot into CI/CD, repositories, or other internal systems tied to the same workflow.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	PR.AA-05 — Least Privilege Access Permissions	Git exposure mitigation depends on narrowing who can reach and administer the service.
	PR.DS-01 — Data-at-Rest Protection	Git services often store repository content and sensitive configuration that must be protected if exposed.
	DE.CM-01 — Networks and Systems Monitored to Detect Cybersecurity Events	Exposed Git instances need monitoring to confirm whether the flaw has been probed or abused.
Recommendation — Restrict Git service access to the minimum required administrative and user paths. Protect repository data so exposure does not translate into immediate credential or source loss. Monitor Git-facing assets for suspicious access, scanning, and exploitation attempts.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is specifically about patching or mitigating a known exploited vulnerability.
	AC-4 — Information Flow Enforcement	Removing internet exposure or constraining access is an information-flow control decision.
Recommendation — Apply the vendor fix or compensating mitigation and track remediation to closure. Enforce network and service-flow restrictions around the vulnerable Git deployment.

Practitioner Guidance

What to prioritise: Find every live instance, then rank them by exposure. Internet-facing or remotely reachable systems come first, followed by any Git deployment that supports automation, deployment pipelines, or shared administrative access.

Decision rule: If you can apply the vendor update, do so immediately and verify from the exposed path. If you cannot patch in time, remove internet exposure or suspend use until a supported mitigation exists. Do not keep an unpatchable instance online just because it is “currently stable.”

What to verify: Confirm the mitigated state on the actual asset, not just in a change ticket. The asset should no longer be reachable in the risky configuration, and the response record should show who approved any exception and when it expires.

Practitioner takeaway: For a KEV-listed Git flaw, the real objective is to eliminate reachable exposure fast, then prove the service is either patched or out of the attack path.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org