Okta Access Gateway 2026.9.1: Eleven Advisories, One Upgrade

On 8 September 2026 Okta published 21 security advisories in one batch. Eleven of them cover Okta Access Gateway (OAG), the on-premises appliance that puts Okta sign-in in front of legacy header-based and Kerberos apps. The most serious is CVE-2026-78626, an authorization bypass in Protected Rules rated CVSS 8.1. Every OAG issue in the batch has the same fix: appliance version 2026.9.1.

What's affected

Okta Access Gateway appliance versions before 2026.9.1. The advisories we reviewed in detail:

The other six OAG advisories in the batch, scored between 5.9 and 6.7, cover Kerberos configuration path validation (CVE-2026-78620), SNMP configuration input handling (CVE-2026-78630), application label sanitization (CVE-2026-78545), the management console exception handler (CVE-2026-78550), custom directive validation bypass (CVE-2026-78552) and dashboard application label validation (CVE-2026-78625).

A few details stand out. In CVE-2026-78626, Okta says OAG did not properly sanitize input or evaluate regular expressions in the Protected Rule check, so a low-privilege user of the app could reach resources the rule was meant to block. In CVE-2026-78623, SAML assertion values were substituted into the SQL string before it was prepared, which defeats the point of a prepared statement. CVE-2026-78560 is the simplest: with pass-through enabled, OAG trusted an identity named in an HTTP header without cryptographic validation, so an unauthenticated client could just claim to be someone.

How to check if you're exposed

1. Find your appliances. Check the OAG admin console's version display on each node, and your hypervisor or cloud inventory for the OAG image.
2. Check for Protected Rules. In the OAG admin console, review each application's policies for Protected Rule entries. These are the apps in scope for the 8.1 bypass.
3. Check datastores. Look for advanced-mode database datastores with custom SQL, and LDAP datastores with search filter templates. If either references SAML assertion attributes, you're in scope for the injection pair.
4. Check the pass-through source. If the pass-through authentication module is enabled for any app, test from a client whether a request with the identity header set reaches OAG unchanged:

# From a client network, against a test app behind OAG.
# Replace HEADER_NAME with the header your pass-through source reads.
curl -sk -o /dev/null -w '%{http_code}\n' \
  -H "HEADER_NAME: test.user@example.com" \
  https://app.example.com/

A 200 with a session cookie for a user you didn't authenticate as means your upstream isn't stripping the header.

What to do now

1. Upgrade every OAG appliance to 2026.9.1 or later. That is the remediation for all eleven advisories.
2. If upgrade has to wait, strip the identity header upstream. Okta's interim advice for CVE-2026-78560 is to have an upstream proxy or firewall strip or overwrite the header if the pass-through source is enabled.
3. Review datastore templates. Even after patching, treat SAML attributes as user input. Prefer attributes the IdP controls (immutable IDs) over ones users can edit, like display names.
4. Lock down the management interface. Two advisories need admin access to the console. Keep it on a management network, not reachable from user subnets.
5. Review access logs for apps with Protected Rules, looking for low-privilege users reaching paths those rules cover, from before your upgrade date.

Why it matters

Access gateways exist to bolt modern identity onto apps that can't speak SAML or OIDC. That makes them a translation layer, and translation layers are where injection lives. A SAML attribute starts as a claim from an identity provider and ends up as a string in SQL or an LDAP filter. If any part of that attribute is user-editable upstream, the gateway is taking user input into a database query.

The pass-through bug is a reminder of an old rule for header-based auth: the header is only trustworthy if every hop between the client and the app overwrites it. Header-based identity is still common in legacy app fronting, and it fails silently when someone adds a new route that skips the proxy.

Okta published 21 advisories on 8 September and seven more on 13 October, and its October summary says it is now scanning its own code with frontier AI models. As more vendors do this, expect advisories to arrive in batches, and plan appliance upgrade windows with that in mind.

Try it yourself

Write down every appliance in your identity path: gateways, RADIUS agents, AD connectors, credential providers. For each, note the version and who owns patching. If that list took more than ten minutes, the gap is visibility. The demo below shows how continuous monitoring flags new advisories against what you actually run.

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

Quick check

Sources

• Okta security advisories index
• CVE-2026-78626: Improper Input Sanitization in OAG Protected Rules
• CVE-2026-78623: Improper Handling of SAML Assertion Attributes in OAG Advanced Mode Datastores
• CVE-2026-78579: OAG LDAP Datastore Filter Interpolation
• CVE-2026-78560: OAG Pass-Through Authentication Source
• CVE-2026-78624: OAG Backup and Restore Path Validation
• Okta Security Advisory Summary: October 2026