Infinite-loop denial of service in Okta RADIUS Agent

The Okta RADIUS Agent does not validate the sub-attribute length when parsing a Vendor-Specific attribute. A sub-attribute length of zero causes the parser to loop indefinitely, resulting in worker-thread exhaustion and denial of new RADIUS authentication requests.

• Okta RADIUS Agent on Windows: affected from version 2.17.5 through versions less than 2.28.0, corresponding to 2.17.5 through 2.27.0 in the vendor advisory.
• Resolved release: Okta states that the vulnerability is resolved in version 2.28.0 and recommends upgrading to version 2.28.0 or greater.
• The supplied affected facts set the default status to unaffected outside the declared affected range; no additional platform or release branch is identified.

The flaw is a CWE-835 infinite loop in the RADIUS packet parser. While processing a Vendor-Specific attribute, the agent does not validate the length of a sub-attribute. If the attacker-controlled sub-attribute length is zero, the parser can loop indefinitely, consume worker threads, and stop accepting new RADIUS authentication requests. Exploitation requires a client device with network access to the agent's RADIUS UDP port to send one or more Access-Request packets containing the malformed attribute. The structured attack conditions indicate that no authentication and no user interaction are required; reachability is network-adjacent, not a claim that every Internet-exposed deployment is reachable. The advisory does not identify the exact parser function or provide evidence that other platforms or non-RADIUS interfaces are affected.

An attacker needs network access to the Okta RADIUS Agent's RADIUS UDP port and can send an Access-Request containing a Vendor-Specific attribute with a zero-length sub-attribute. No privileges or user interaction are required, and the attack conditions have low complexity. The supplied record marks public exploit as false and does not identify known exploitation; the CISA enrichment returned with the record also reports exploitation as none at the time of that enrichment. These status fields do not guarantee that exploitation cannot occur in the future.

The primary technical outcome is availability loss because the agent's worker threads can remain in an infinite loop, causing new RADIUS authentication requests to be denied. The impact remains within the affected agent's service context, with no established confidentiality or integrity impact and no evidence of privilege gain. Dependent systems may experience authentication disruption if they rely on the affected agent and lack an effective fallback. The available evidence does not establish data disclosure, data modification, code execution, or takeover.

Successful triggering can exhaust the agent's worker threads and deny new RADIUS authentication requests. Services that depend on the agent for authentication may experience login failures or authentication delays, depending on their fallback design. The evidence supports an availability disruption, not unauthorized data access or modification. The record does not establish a breach, persistence, privilege escalation, or impact to already completed sessions.

1. Upgrade every Okta RADIUS Agent instance on Windows in the affected range to version 2.28.0 or greater, following Okta's supported deployment procedure.
2. Inventory all agent installations and verify the installed version after upgrading; do not assume that updating one agent updates other hosts.
3. Until upgrade, limit network access to the agent's RADIUS UDP port to trusted adjacent systems where operationally feasible. This is defense in depth based on the documented precondition, not a vendor-confirmed substitute for patching.
4. Review authentication service health and test new RADIUS authentication requests after remediation.

1. Inventory Windows hosts running Okta RADIUS Agent and compare each installed version with the affected and fixed boundaries published by Okta.
2. Identify hosts that receive traffic on the agent's RADIUS UDP port and the systems that have network access to that port.
3. Review RADIUS authentication failures or timeouts and agent worker or resource exhaustion, particularly when unusual Access-Request traffic contains Vendor-Specific attributes. These are precautionary telemetry checks, not vendor-confirmed indicators of compromise.
4. After upgrading, verify that new RADIUS authentication requests are processed normally. The absence of suspicious log evidence does not prove that the system is safe.