Vulnerability blast radius is the scope of systems, data, and code a flaw can reach once exploited. Endor Labs measures it with reachability analysis across your code and its dependencies.
The term has gotten extra attention lately thanks to BlastRADIUS (CVE-2024-3596), a critical protocol flaw in RADIUS authentication disclosed in July 2024. This article covers both that specific vulnerability and the broader concept of measuring and reducing blast radius for any security finding across your application stack.
What is blast radius in cybersecurity
Blast radius describes the total scope of systems, data, and users that could be affected if a single vulnerability gets exploited. Picture it like the shockwave from an explosion—the vulnerability is ground zero, and the blast radius is everything within range of the damage.
Right now, the term shows up in two different contexts, which can get confusing:
- Blast-RADIUS (CVE-2024-3596): A specific protocol vulnerability in RADIUS authentication disclosed in July 2024
- Vulnerability blast radius (general concept): A way to measure potential impact from any security vulnerability across your application stack
If you landed here because of the CVE, the next section covers it. If you're thinking about blast radius as a prioritization concept for vulnerability management, keep reading—we'll get there.
The BlastRADIUS vulnerability explained
BlastRADIUS (CVE-2024-3596) is a 30-year-old design flaw in the RADIUS protocol that researchers disclosed in July 2024. It carries a critical severity rating (9.0+) and affects nearly all RADIUS implementations using non-EAP authentication over UDP.
The flaw exists in the protocol itself, not in any particular vendor's implementation. Patching a single product won't fix it—the RADIUS design is the problem.
How the Blast-RADIUS attack works
The attack exploits a weakness in how RADIUS validates response packets using MD5 hashes. An attacker positions themselves between a RADIUS client (like a VPN concentrator) and the RADIUS server. When a user attempts authentication with any username and an incorrect password, the RADIUS server sends back an Access-Reject response.
Here's where it gets interesting. The attacker intercepts that response and uses a chosen-prefix MD5 collision attack to forge a valid Access-Accept response. The RADIUS client accepts the forged response and grants network access.
The attacker doesn't need to know the user's credentials or the shared secret between client and server. They just need network access to intercept and modify traffic.
Who is affected by BlastRADIUS
The vulnerability affects any system using RADIUS over UDP with non-EAP authentication methods like PAP or CHAP:
- VPN gateways and concentrators
- Enterprise firewalls (Palo Alto, Cisco, Fortinet, SonicWall)
- Network switches and routers using RADIUS for admin access
- Wireless access points authenticating against RADIUS
- ISP and telecom infrastructure
If your organization uses RADIUS for network access control—and most enterprises do—you're likely affected.
How to mitigate BlastRADIUS
The primary mitigation is upgrading RADIUS servers and clients to versions that enforce the Message-Authenticator attribute on all packets. This attribute provides cryptographic integrity that defeats the forgery attack.
Mitigation StepEffortEffectivenessApply vendor patchesMediumHighEnable Message-AuthenticatorLowHighSegment RADIUS traffic to management VLANsMediumMediumMigrate to RADIUS/TLS (RadSec)HighVery High
For FreeRADIUS, set require_message_authenticator = auto
in your configuration. For commercial products, check your vendor's CVE-2024-3596 advisory—Cisco, Palo Alto, and others have published specific guidance.
Tip: Network segmentation provides defense-in-depth here. Even after patching, isolating RADIUS traffic to secure management VLANs limits an attacker's ability to reach the man-in-the-middle position the attack requires.
How to measure vulnerability blast radius
Beyond the specific CVE, understanding blast radius helps teams prioritize which vulnerabilities to fix first. With CVE submissions up 263% since 2020, a vulnerability with a large blast radius—many reachable paths, critical systems affected—warrants faster remediation than one with limited exposure.
The challenge? Most vulnerability scanners don't tell you blast radius. They tell you a CVE exists. That's not the same thing.
Map reachability across code and dependencies
Blast radius depends on whether vulnerable code is actually executed. A CVE in a library you've imported but never call has a blast radius of zero in your application.
Measuring reachability involves:
- Static analysis: Tracing call graphs to determine if vulnerable functions are invoked from your code
- Dependency mapping: Identifying both direct and transitive dependencies that expose the vulnerability
- Full-stack reachability: Following the path from first-party code through dependencies into container layers
Tools that provide full-stack reachability analysis can distinguish between vulnerabilities that are theoretically present versus actually exploitable. This distinction typically reduces actionable findings by 90% or more.
Assess container and base image exposure
Vulnerabilities in base images compound blast radius in ways that aren't immediately obvious. A single vulnerable package in a base image might propagate to dozens of derived images across your container fleet.
Container layer analysis reveals which components are actually loaded at runtime. Base-to-derived image mapping identifies total exposure across deployments. And deduplication between SCA findings and container scan findings matters because the same CVE often appears in both.
Without this visibility, teams often remediate the same vulnerability multiple times in different contexts—or miss it entirely because it's buried in a base image they didn't realize they were using.
Evaluate runtime versus static exposure
Static reachability analysis identifies all theoretically possible code paths. Runtime analysis shows which paths are actually executed in production.
- Static analysis catches vulnerabilities before deployment and doesn't require instrumentation
- Runtime analysis provides higher confidence but only covers code paths that have been exercised
For blast radius measurement, static analysis is usually sufficient—you want to know what could be reached, not just what has been reached so far.
What increases vulnerability blast radius
Certain patterns in your codebase and infrastructure amplify blast radius. Recognizing them helps identify where to focus hardening efforts.
Deep transitive dependency chains
A vulnerability several layers deep in your dependency tree can still have a massive blast radius if many applications depend on that chain. The Log4Shell vulnerability (CVE-2021-44228) demonstrated this—Log4j was a transitive dependency in thousands of applications that didn't directly import it, and vulnerable versions still represent 13% of downloads years later.
Direct dependencies are visible in your package manifest. Transitive ones—64% of open-source components according to Black Duck's OSSRA report—often aren't, which is why SCA tools that only scan direct dependencies miss significant exposure.
Shared libraries and common base images
Widely-used libraries create concentration risk. A vulnerability in a logging framework, HTTP client, or serialization library affects every application using it. The same applies to container base images—if your organization standardizes on a particular base image, a vulnerability in that image affects your entire containerized application fleet.
Privileged access and credential exposure
Vulnerabilities affecting authentication or authorization systems have inherently larger blast radius. BlastRADIUS is a perfect example—compromising RADIUS authentication grants access to everything RADIUS protects. Similarly, vulnerabilities that expose credentials have blast radius proportional to what those credentials can access.
Flat network architecture
Network segmentation limits blast radius by containing lateral movement. Without it, a single compromised system can reach everything on the network. This is why the BlastRADIUS mitigation guidance emphasizes isolating RADIUS traffic.
How to reduce vulnerability blast radius
Measuring blast radius is useful. Reducing it is the goal.
1. Prioritize vulnerabilities that are reachable and exploitable
Focus remediation on vulnerabilities where the code path is actually exercised. Most SCA tools flag every CVE in your dependency tree without reachability context, which leads to alert fatigue. Teams either ignore findings entirely or waste cycles on vulnerabilities that can't actually be exploited in their environment.
Tools that verify reachability—tracing from your code through dependencies to the vulnerable function—reduce noise and help teams focus on what matters.
2. Apply patches without full version upgrades
Major version upgrades introduce breaking changes. When a vulnerability exists in a dependency you can't easily upgrade, you're stuck choosing between security risk and stability risk.
Backported security patches offer a third option: apply only the security fix to your current version, without the breaking changes from a full upgrade.
This allows faster remediation without destabilizing production.
3. Segment networks to contain potential damage
Network segmentation limits how far an attacker can move after exploiting a vulnerability. Even if a vulnerability has a large theoretical blast radius, segmentation constrains the practical impact.
4. Remove unused dependencies and packages
Every dependency is potential attack surface. Removing unused packages—especially from container images—directly reduces blast radius by eliminating code paths entirely.
5. Enforce least privilege across services
Limit what each service can access. Even if a vulnerability is exploited, the blast radius is contained to what that service's permissions allow.
Partial mitigations when full remediation is delayed
Not every vulnerability can be fixed immediately. Compatibility concerns, engineering bandwidth, and change management processes all create delays.
Compensating controls and monitoring
When patching isn't immediately possible, web application firewalls can block known exploit patterns for specific CVEs. Enhanced logging and alerting on affected systems provides early warning. Network-level restrictions can limit traffic to vulnerable services.
These aren't substitutes for remediation, but they reduce blast radius while you work toward a permanent fix.
Risk acceptance and documentation
Some organizations formally accept risk for low-blast-radius vulnerabilities. This is reasonable when the vulnerability is unreachable, the affected system is isolated, or the remediation cost exceeds the risk. Document the decision, including your blast radius assessment—this matters for compliance audits and for revisiting the decision if circumstances change.
How to communicate blast radius to stakeholders
Technical teams understand reachability and dependency graphs. Executives understand business impact. Translating between the two is often the hardest part of vulnerability management.
Quantify potential business impact
Translate blast radius into terms stakeholders care about: number of users or customers potentially affected, systems or services that would be unavailable, data types at risk (PII, financial data, credentials), and regulatory implications.
Blast Radius FactorBusiness TranslationAffected dependenciesApplications at riskReachable code pathsLikelihood of exploitationNetwork exposureLateral movement potentialData access scopeRegulatory and compliance impact
Visualize dependency graphs and exposure paths
Visual representations of call graphs and dependency trees help non-technical stakeholders understand why certain vulnerabilities are high priority. A diagram showing "this CVE in this library is called by these 47 services" communicates blast radius more effectively than a CVSS score.
Reduce blast radius with full-stack visibility
Measuring and reducing blast radius requires visibility across the entire application stack—first-party code, open source dependencies, and container images. AURI, the security intelligence layer for agentic software development from Endor Labs, builds a complete call graph across all three layers and verifies which findings are actually reachable.
Book a demo to see how Endor Labs maps blast radius across your application stack.
FAQs about vulnerability blast radius
What is the difference between blast radius and CVSS score?
CVSS measures the theoretical severity of a vulnerability in isolation. Blast radius measures the actual scope of systems and data that could be affected in your specific environment based on reachability and architecture. A critical CVSS vulnerability might have zero blast radius if the vulnerable code is never called.
How does blast radius apply to software supply chain vulnerabilities?
A vulnerability in a widely-used transitive dependency can have a massive blast radius because it affects every application in the dependency chain, even if those applications don't directly import the vulnerable package.
Can vulnerability blast radius be calculated automatically?
Tools that perform reachability analysis across code, dependencies, and containers can automatically determine which vulnerabilities have exploitable paths and map the affected scope.
Is the BlastRADIUS vulnerability the same as general blast radius in security?
No. BlastRADIUS (CVE-2024-3596) is a specific protocol flaw in RADIUS authentication. "Blast radius" as a general security concept refers to measuring the potential impact scope of any vulnerability.
What's next?
When you're ready to take the next step in securing your software supply chain, here are 3 ways Endor Labs can help: