Lukas Johannes Moeller reported a bug in libradius related to the processing of RADIUS attributes that can lead to an infinite loop or an out-of-bounds read that may cause a crash.
Integer Underflow When Handling RADIUS Attributes
The libradius library doesn't correctly check the length field in the header of RADIUS attributes, which can cause an integer underflow that may lead to an infinite loop or an out-of-bounds read. The latter may cause a crash. Affected are all strongSwan versions since 4.2.14.
CVE-2026-35333 has been assigned for this vulnerability.
Missing Check for Undersized Attributes in libradius
The libradius library contains code related to the RADIUS protocol, which can be used to delegate EAP authentication to a RADIUS server during IKEv2. In particular, the parsing of RADIUS messages and attributes is implemented in the library.
The header of such attributes consists of a single byte for the attribute type, followed by a single byte for the complete length of the attribute, which is then followed by the attribute data. So a valid attribute should have a length of at least 2.
Because this wasn't checked, a length of 0 or 1 caused an integer underflow when the size of the header itself was subtracted during the enumeration of the attributes:
*type = this->next->type;
data->ptr = this->next->value;
data->len = this->next->length - sizeof(rattr_t);
this->left -= this->next->length;
this->next = ((void*)this->next) + this->next->length;With a length of 1, the caller would read way beyond the end of the attribute/message, which most likely causes a segmentation fault. What can also be seen in the above snippet is that this->left and this->next are not modified if the length is 0, causing an infinite loop.
To trigger the latter and to avoid the crash, a crafted attribute with length 0 and a type other than RAT_MESSAGE_AUTHENTICATOR (80) can be put in the message. This will cause verify(), which enumerates the attributes to find the Message-Authenticator attribute, to get stuck infinitely.
Because no authentication is required, crafted messages may be injected as response to RADIUS requests sent by the eap-radius plugin during a client's authentication attempt. If the Dynamic Authorization Extension (DAE) is enabled, which is not the default, attackers may also send unsolicited RADIUS messages to the configured port. Similarly, if the tnc-pdp plugin is enabled, which acts as a RADIUS server.
Remote code execution is not possible due to this issue.
As mentioned in the introduction, credit to Lukas Johannes Moeller for finding this vulnerability. It was independently found by Haruto Kimura (Stella). Thanks to both of them for finding it and reporting it responsibly.
Mitigation
Servers that don't use the eap-radius or tnc-pdp plugins are not vulnerable. If the former is enabled but DAE is not, the exposure is significantly lowered. Also, always make sure the ports these plugins are listening on are not publicly reachable.
The just released strongSwan 6.0.6 fixes this vulnerability. For older releases, we provide a patch that fixes the vulnerability and should apply with appropriate hunk offsets. Please note that we don't provide a patch for versions older than 4.6.3, where libradius was extracted from the eap-radius plugin.