- Products
- Learn
- Local User Groups
- Partners
- More
AI Security Masters E7:
How CPR Broke ChatGPT's Isolation and What It Means for You
Call For Papers
Your Expertise. Our Stage
Good, Better, Best:
Prioritizing Defenses Against Credential Abuse
Ink Dragon: A Major Nation-State Campaign
Watch HereCheckMates Go:
CheckMates Fest
Blast-RADIUS is a vulnerability that affects the RADIUS protocol. RADIUS is a very common protocol used for authentication, authorization, and accounting (AAA) for networked devices on enterprise and telecommunication networks.
The Blast-RADIUS attack allows a man-in-the-middle attacker between the RADIUS client and server to forge a valid protocol accept message in response to a failed authentication request. This forgery could give the attacker access to network devices and services without the attacker guessing or brute forcing passwords or shared secrets. The attacker does not learn user credentials.
Blast-RADIUS is a protocol vulnerability, and thus affects all RADIUS implementations using non-EAP authentication methods over UDP.
System administrators of networks using RADIUS should check with vendors for a patch against this vulnerability, and follow best practices for RADIUS configuration as discussed below. There is nothing that end users can do on their own to protect against this attack.
RADIUS is used in a wide variety of applications, including in enterprise networks to authenticate access to switches and other routing infrastructure, for VPN access, by ISPs for DSL and FTTH (Fiber to the Home), in 802.1X and Wi-Fi authentication, 2G and 3G cellular roaming and 5G DNN (Data Network Name) authentication, mobile Wi-Fi offload with SIM card-based authentication, private APN authentication, to authenticate access to critical infrastructure, and in the Eduroam and OpenRoaming wifi consortia.
The RADIUS protocol predates modern cryptographic guarantees and is typically unencrypted and unauthenticated. However, the protocol does attempt to authenticate server responses using an ad hoc construction based on the MD5 hash function and a fixed shared secret between a client and server.
Our attack combines a novel protocol vulnerability with an MD5 chosen-prefix collision attack and several new speed and space improvements. The attacker injects a malicious attribute into a request that causes a collision between the authentication information in the valid server response and the attacker’s desired forgery. This allows the attacker to turn a reject into an accept, and add arbitrary protocol attributes.
No update because our ticket is closed. We've upgraded the environment to take 65 and installed the custom hotfix. I would suggest to open a case yourself and ask for a portfix. I'm also missing the fix in the upcoming JHF release.
Can Spark appliance users also get the same support as others?
Is a fix also planned for version R81.10.10?
I assume we will also roll out fixes for Quantum Spark as well.
Any news for R81.10?
R81.10.15 is out.
https://support.checkpoint.com/results/sk/sk182438
this version already contains: "VPN Remote Access - RADIUS attribute to be ignored." and is set to ignore attribute 80
tested and works with fully updated NPS server.
I am uncertain whether R81.20 Take 89 fixes this issue for VPN connections, without ignoring attribute 80. The release notes state "Resolved CVE-2024-3596 - Blast-RADIUS attacks for Gaia Portal and Gaia Clish", but nothing in regards to VPN.
The official SK (Check Point response to CVE-2024-3596 - Blast-RADIUS attack) is also lagging on updates.
nope, upgraded my gateways to JHF 89, tried to revert the attribute 80 to the default 0 value, vpn login with radius DID NOT work for me! (but i did not have my managment on JHF 89, when doing the test, must try again when all is on JHF 89)
There's a few places where the effects of Blast RADIUS need to be fixed.
One of them is in Gaia OS itself (specifically for access to Gaia Portal and clish).
Why Remote Access VPN is not explicitly listed in this SK, I cannot say, but I believe it would correspond to Identity Awareness.
In any case, I'll see if we can get this explicitly mentioned in the SK.
R81.20 JHF 90 now supports Message Authenticator attributes in communication with RADIUS servers for all use cases (Gaia OS, Identity Awareness Portal, SmartConsole, Mobile Access Portal, Remote Access).
I assume similar fixes are also coming for other releases (R81, R81.10, and R82).
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 9 | |
| 8 | |
| 4 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 3 | |
| 2 |
Tue 21 Apr 2026 @ 05:00 PM (IDT)
AI Security Masters E7: How CPR Broke ChatGPT's Isolation and What It Means for YouTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 21 Apr 2026 @ 05:00 PM (IDT)
AI Security Masters E7: How CPR Broke ChatGPT's Isolation and What It Means for YouTue 28 Apr 2026 @ 06:00 PM (IDT)
Under the Hood: Securing your GenAI-enabled Web Applications with Check Point WAFTue 12 May 2026 @ 10:00 AM (CEST)
The Cloud Architects Series: Check Point Cloud Firewall delivered as a serviceThu 30 Apr 2026 @ 03:00 PM (PDT)
Hillsboro, OR: Securing The AI Transformation and Exposure ManagementAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY