Okta RADIUS Agent and Windows Credential Provider Fixes, Oct 2026

On 13 October 2026 Okta published three advisories for two on-premises components that enforce MFA outside the browser: the Okta RADIUS Agent and the Okta Credential Provider for Windows, which adds MFA to Windows and RDP logons. Okta says it found these issues by scanning its own code with frontier AI models, that all are Medium severity, and that its telemetry shows no evidence of exploitation.

Medium doesn't mean ignorable here. One bug lets any local Windows service read the RADIUS Agent's encrypted Okta API token and the key that decrypts it. Another lets a single packet stop VPN logins.

What's affected

CVE-2026-78632. The RADIUS Agent's Windows installer gave write permissions to NT SERVICE\ALL SERVICES and CREATOR OWNER on the directories holding the agent configuration, its AES encryption key and its logs. Any local service account, even a low-privilege one, could read the AES key and the encrypted Okta API token. Put those two together and the token is no longer protected.

CVE-2026-78633. The agent didn't check sub-attribute lengths inside RADIUS Vendor-Specific attributes. A zero-length sub-attribute sent the parser into an infinite loop, exhausting worker threads and blocking new authentication requests. The precondition is being able to reach the agent's RADIUS UDP port and send Access-Request packets. Okta scores it with an adjacent network attack vector.

CVE-2026-78628. The Credential Provider parsed a serialized credential buffer as a Kerberos logon structure without checking buffer size or string offsets. A local user with crafted input through the logon or unlock path could crash the process or cause out-of-bounds reads and writes, which may leak process memory into local logs.

How to check if you're exposed

Okta's advisory summary gives two quick checks in the Admin Console:

• RADIUS Agent: Dashboard, then Integration Agents. A RADIUS tab means you run the agent.
• Credential Provider: Applications, then search for "Microsoft RDP (MFA)."

On each RADIUS Agent host, check the installed version and the directory permissions:

Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*,
  HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* |
  Where-Object { $_.DisplayName -like "*Okta*" } |
  Select-Object DisplayName, DisplayVersion

# Then inspect ACLs on the agent's install directory
$AgentDir = "D:\path\to\okta-radius-agent"   # set to your install location
icacls $AgentDir /T | findstr /I /C:"ALL SERVICES" /C:"CREATOR OWNER"

Set the path to wherever the agent is installed on that host. Any write grant to ALL SERVICES or CREATOR OWNER on the config or key folders matches the advisory.

For the Credential Provider, check the version on every server where RDP MFA is enforced. Any version below 1.4.6.0 needs the update.

What to do now

1. Upgrade the RADIUS Agent to 2.28.0 or later on every host. If you run several agents behind a load balancer, roll through them one at a time.
2. Rotate the RADIUS Agent's Okta API token if any other service ran on the same host while you were on an affected version. The upgrade fixes the permissions, but it can't tell you whether the key and token were already read.
3. Restrict who can reach UDP 1812 (or your configured RADIUS port) on agent hosts. Only your VPN concentrators, wireless controllers and other RADIUS clients should be able to send packets.
4. Upgrade the Credential Provider to 1.4.6.0 or later on every server and workstation where it's installed. Prioritise jump hosts and servers where many users log on interactively.
5. Dedicate the hosts. A RADIUS Agent holds an Okta API token. Don't co-locate it with general-purpose services.
6. Monitor agent health. A RADIUS Agent that stops answering is a VPN outage. Alert on it so a denial of service is noticed in minutes.

Why it matters

MFA for VPNs and Windows logons usually runs through small agents like these, installed once by a network or infrastructure team and then left alone. They sit in the authentication path for your most sensitive access, and they hold credentials back to the identity provider. That makes them worth the same patch attention as the IdP itself.

The file permissions bug shows how encryption at rest can be undone by an access control. An encrypted token stored next to its key, in a folder every service can read, is protected only on paper.

The denial of service bug is a reminder that availability is a security property for authentication services. If the RADIUS path fails closed, nobody gets on the VPN. If someone "temporarily" configures it to fail open during an outage, MFA is gone. Decide which you want before an attacker forces the choice.

Try it yourself

List every server in your environment that runs an identity agent: RADIUS, credential providers, directory connectors and provisioning agents. For each, note the installed version and the last date it was patched. The demo below shows how asset discovery builds that list automatically.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Okta Security Advisory Summary: October 2026
• CVE-2026-78632: Insecure Default File Permissions in Okta RADIUS Agent Windows Installer
• CVE-2026-78633: Denial of Service in Okta RADIUS Agent Packet Parser
• CVE-2026-78628: Improper Input Validation in the Okta Credential Provider for Windows