TL;DR: RADIUS response forgery exploits MD5-based integrity checks in RADIUS so an attacker on-path can turn an Access-Reject into Access-Accept and gain unauthorized network access, according to JumpCloud. The issue is not just protocol weakness, it is a trust model that assumes response integrity can be inferred from a legacy authenticator.
At a glance
What this is: This is an analysis of RADIUS response forgery, a protocol attack that can flip access decisions by manipulating response integrity checks in transit.
Why it matters: It matters because IAM teams still rely on network access controls that assume response authenticity is trustworthy, and those assumptions break when protocol integrity is weak.
Context
RADIUS response forgery is a protocol-level integrity problem, not a password guessing problem. The attacker sits on-path between the RADIUS client and server, manipulates responses, and exploits weak cryptographic checks to alter an access decision.
For identity and access teams, the governance issue is trust in the response path itself. If a network access device accepts a forged Access-Accept, the control plane is validating the wrong thing at the wrong layer.
JumpCloud frames the issue around CVE-2024-3596 and the use of MD5 in the RADIUS response authenticator. That makes this a useful case for understanding how legacy AAA assumptions weaken modern access governance.
Key questions
Q: What breaks when RADIUS response integrity is not protected end to end?
A: When response integrity is not protected end to end, an attacker can rewrite the meaning of the authentication decision itself. That turns network access control into a forgery problem, where the device trusts a manipulated Access-Accept message instead of a genuine server decision.
Q: Why do legacy RADIUS deployments create access control risk?
A: Legacy RADIUS deployments create risk because authorization can depend on weak or outdated integrity checks, not just on user credentials. If an attacker can intercept traffic and forge a valid-looking response, the network access device may grant access even though the server never approved it.
Q: How do teams know whether RADIUS is failing securely?
A: Teams should look for deployments that reject responses missing Message-Authenticator, use RadSec for sensitive access paths, and log unexpected attribute changes in replies. If a client still accepts ambiguous or legacy-authenticated responses, the system is not failing securely. The signal is whether unauthorized response rewriting is technically possible, not whether it has been observed.
Q: When should organisations replace RADIUS with a stronger access design?
A: Organisations should prioritise replacement or hardening when the access path protects admin, VPN, or segmented internal environments and the current deployment still depends on MD5-era trust assumptions. If response integrity cannot be guaranteed end to end, the decision logic is too fragile for high-value access.
Technical breakdown
How RADIUS response forgery alters access decisions
RADIUS is a centralized Authentication, Authorization, and Accounting protocol used by network access devices such as VPNs, switches, and routers. In the attack described here, the attacker intercepts the Access-Request and forges the server response before the legitimate packet arrives. Because the client validates only the response authenticator, a manipulated Access-Reject can be made to look like a valid Access-Accept, which changes the authorization outcome without breaking the protocol exchange at the transport layer.
Practical implication: treat response integrity as a design requirement, not a packet-level assumption.
Why MD5 and chosen-prefix collisions matter here
The core weakness is not just that MD5 is old, but that RADIUS uses it in a way that can be predicted and manipulated. The article explains that chosen-prefix collision techniques let an attacker craft bytes that preserve a valid-looking authenticator while changing packet content, including attributes such as Proxy-State. That means the attacker does not need the shared secret if they can control the response structure closely enough to satisfy the legacy check.
Practical implication: replace integrity mechanisms that depend on predictable legacy hashing behavior.
Why RadSec and Message-Authenticator change the trust model
Message-Authenticator adds stronger packet validation by covering the full packet with HMAC-MD5, while RadSec moves RADIUS inside TLS over TCP. Those changes matter because they shift trust away from a fragile response authenticator and toward channel protection and stronger integrity checks. In other words, the defence is not only about harder math, but about removing the attacker’s ability to sit in the middle and rewrite the decision path.
Practical implication: prefer protected transport and full-packet integrity for any access path that still depends on RADIUS.
Threat narrative
Attacker objective: The attacker wants unauthorized network access by making the access device accept a forged approval response.
- Entry occurs when the attacker obtains on-path or man-in-the-middle positioning between the RADIUS client and server.
- Credential access is not the issue here because the attack does not require passwords or the shared secret; instead, the attacker exploits predictable response construction and MD5 weakness.
- Escalation happens when the forged response is accepted before the legitimate server response, converting denial into approval.
- Impact is unauthorized network access through a trusted access device that believes the forged Access-Accept is legitimate.
Breaches seen in the wild
- Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
RADIUS response integrity is the control, not the authenticator field by itself: This attack works because access governance often assumes the response authenticator proves trustworthiness. In reality, a legacy hash check is not the same thing as a trusted authorization decision, especially when an attacker can influence packet structure in transit. Practitioners should treat response validation and transport protection as a single control plane requirement.
Legacy AAA protocols create trust debt when they survive beyond their cryptographic assumptions: RADIUS was designed for centralized access decisions, but not for an environment where on-path manipulation and collision attacks are practical. That makes the weakness structural, not accidental. The implication is that network access governance cannot rely on protocol age as evidence of protocol adequacy.
Protocol trust gap: The specific failure mode here is the gap between access approval and access authenticity. The client thinks it is validating a server response, but it is really validating a weak surrogate for response integrity. That is exactly the kind of gap that identity governance teams miss when they focus on credentials alone instead of the trust model around the decision.
RadSec and full-packet validation are governance moves, not just transport changes: Moving RADIUS into TLS and enforcing Message-Authenticator changes the boundary of trust. They reduce the chance that an on-path actor can influence authorization outcomes without detection. For practitioners, the point is to govern the access path as a protected identity transaction, not as an ordinary network exchange.
What this signals
Protocol trust debt: RADIUS shows how a widely deployed access protocol can remain operational while its trust assumptions quietly age out of validity. Once response authenticity depends on fragile legacy checks, security teams are no longer governing access decisions, they are governing the likelihood that an attacker can rewrite them.
The practical boundary is not the RADIUS server itself but the integrity of the exchange between server, client, and transport. Where that boundary is weak, access control becomes a network positioning problem as much as an identity problem.
For practitioners
- Mandate stronger RADIUS response integrity Require Message-Authenticator wherever RADIUS remains in use, and verify that clients reject responses lacking it or failing validation.
- Move high-trust access paths to RadSec Use RADIUS over TLS for environments where access decisions protect sensitive network segments or privileged admin access.
- Reduce on-path exposure in the access path Segment network paths so RADIUS traffic is not exposed to unnecessary transit points, shared broadcast domains, or unmanaged intermediary devices.
- Review shared-secret hygiene and protocol dependencies Inventory every RADIUS deployment that still depends on MD5-based trust assumptions and identify where legacy peers constrain remediation.
Key takeaways
- RADIUS response forgery is a trust-model failure, not a credential theft story, because the attacker can alter an authorization outcome in transit.
- The article shows that MD5-based response validation can be manipulated, allowing a forged approval to override a legitimate denial.
- The control that matters most is end-to-end response integrity, with Message-Authenticator and RadSec reducing the chance that on-path manipulation can change access decisions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while 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 |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | RADIUS response forgery exploits a broken authentication trust check in a non-human access flow. |
| NHI-02 — Secret Leakage | The attack bypasses reliance on shared secrets by exploiting protocol trust, not secret theft. | |
| Recommendation — Treat RADIUS response validation as an authentication control and remove legacy trust assumptions. Reduce dependence on shared secrets by enforcing stronger packet integrity and transport protection. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator management applies to the shared secrets and integrity checks used by RADIUS deployments. |
| Recommendation — Apply IA-5 to harden authenticator handling and retire weak legacy validation paths. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack uses on-path position to manipulate authentication outcomes and expand network access. |
| Recommendation — Map this threat to credential access and lateral movement to prioritise network-path monitoring. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The vulnerability undermines the correctness of authorization decisions at the access boundary. |
| Recommendation — Use PR.AA-05 to verify that network access decisions depend on authenticated, integrity-checked responses. | ||
Key terms
- RADIUS response forgery: A protocol attack in which an attacker alters or fabricates a RADIUS reply so a network access device accepts a false authorization result. The weakness sits in the integrity of the response path, not in the user's password, which makes the attack especially dangerous for VPN and Wi-Fi access control.
- Message-Authenticator: A RADIUS attribute that strengthens packet validation by covering the contents of the message with a keyed hash. It is used to reduce the risk that an attacker can tamper with a response in transit and have it accepted as genuine by the client or network access device.
- On-Path Attacker: An on-path attacker is a party positioned to observe, alter, or inject traffic between two endpoints. In protocol abuse scenarios, that placement matters because the attacker can manipulate handshake traffic, forge state, or influence redirects without needing direct control of the destination system itself.
- RadSec: RADIUS over TLS, usually carried over TCP, which protects authentication traffic with transport-layer encryption and stronger integrity guarantees. For identity teams, it changes RADIUS from a packet that can be manipulated on path into a session that is much harder to intercept or forge.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 12, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org