Okta Fixes Auth0 and Access Gateway Flaws Enabling XSS, Auth Bypass, and SQL Injection

Okta Access Gateway (CVE-2026-78623, CWE-89) fails to sanitize SAML assertion values before they are interpolated into database queries when the datastore is configured in advanced mode. Because the unsanitized values are substituted directly into the query string prior to statement preparation, an attacker whose crafted SAML assertion is processed by the gateway can cause unintended SQL execution against the configured backend database. Successful exploitation yields a high-confidentiality impact (exposure of backend database data) with limited integrity and availability impact, and the changed-scope score (S:C) means the backend database can be affected beyond the gateway component. Organizations running Okta Access Gateway with an advanced-mode datastore backed by a SQL database are affected; no specific affected version range is provided in the available data. Exploitation has not been observed: there is no known public proof-of-concept, the flaw is not in CISA KEV, and EPSS assigns only a 0.2% probability of exploitation within 30 days.

Do: Check whether your Access Gateway datastore is configured in advanced mode against a SQL backend; if so, apply the remediation version or mitigation specified in Okta's security advisory, since no fixed version is stated in the available data. Review the backend database's query logs for anomalous or malformed SQL and constrain which SAML assertion attributes are passed into datastore queries. Because exploitation requires crafted assertion values with low-privilege access, also validate that assertion attribute values follow expected formats as an interim hardening measure.

Okta Access Gateway (OAG), the gateway component Okta customers deploy to extend single sign-on to on-premises or private applications, mishandles input sanitization and regular expression evaluation in its Protected Rule authorization check, an incorrect-authorization flaw (CWE-863). The bypass is triggered only when an administrator has explicitly configured a Protected Rule policy on one or more application resources; an authenticated user with low-level privileges can then submit input that evades the rule's regular-expression matching and reach resources the policy was meant to restrict. A successful bypass yields high confidentiality and integrity impact (unauthorized read and potentially modification of protected application resources) with no availability impact, per the CVSS 8.1 score (network vector, low privileges required, no user interaction). Only organizations running Okta Access Gateway that use Protected Rule policies are affected; OAG deployments without any Protected Rule configuration are not exposed. There is no public proof-of-concept, the flaw is not in CISA KEV, and EPSS assigns a 0.2% probability of exploitation within 30 days (12th percentile), indicating no known exploitation at this time.

Do: Inventory your Okta Access Gateway configuration to determine whether any application resources use Protected Rule policies; if none do, you are not affected by this bypass. If Protected Rules are in use, consult Okta's security advisory (trust.okta.com) for the patched OAG release and upgrade promptly, then review gateway access logs for requests that reached protected resources without satisfying the rule. Until patching is complete, consider compensating access controls at the application layer and continue monitoring for anomalous access to the affected resources.

The Auth0 AD/LDAP Connector fails to properly HTML-encode directory data shown in search results and updater log content within its admin panel, allowing stored Cross-Site Scripting (CWE-79). An authenticated user with privileges to modify directory attributes, or a low-privileged local user on the host where the connector runs, can insert script content that is later rendered to an administrator. When an administrator views the affected search results or update logs, the injected script executes in the admin's browser, enabling session-context actions with high confidentiality, integrity, and availability impact per the CVSS scope-changed rating (9.0, critical). Only organizations running the self-hosted Auth0 AD/LDAP Connector to federate on-premises Active Directory/LDAP with Auth0 are affected. There is no known public proof-of-concept, the issue is not in CISA's KEV catalog, and EPSS assigns only a 0.2% probability of exploitation within 30 days, so no active exploitation is currently known.

Do: Update the AD/LDAP Connector to the fixed release published by Okta/Auth0 (consult the vendor advisory for the exact patched version, since none is listed here), and verify via the connector's updater/admin panel that the new build is deployed. In the meantime, restrict which accounts can modify directory attributes and limit local logon access on the connector host, and have administrators inspect any directory attribute values or updater log entries from untrusted users before viewing them in the admin panel.