Summary
  • Okta published both advisories on October 22, 2026.
  • CVE-2026-115547 is CVSS 3.1 9.1. An authenticated admin can run system commands as the OAG service account.
  • CVE-2026-115546 is CVSS 3.1 8.1. A signed-in user can reach the Admin Console through an unvalidated auth source.
  • The two flaws chain. The second hands the attacker the admin console. The first turns that access into command execution.
  • Both are fixed in Okta Access Gateway 2026.10.2.

An identity flaw with a chain

Okta Access Gateway (OAG) is an appliance. It puts Okta sign on in front of company apps. Its Admin Console holds the keys to that setup.

On October 22, 2026, Okta Trust published two security advisories for it. Each flaw is serious alone. Together they chain. The first flaw hands an attacker the Admin Console. The second turns that access into command execution on the appliance.

The 9.1 flaw

The first record is CVE-2026-115547. It is an input validation failure in the Admin Console. The console accepts crafted configuration values. An authenticated administrator can use them to run system commands. The commands run as the OAG service account.

Common Vulnerabilities and Exposures (CVE) is the public record system. The weaknesses are CWE-94 and CWE-20. CWE-94 is code injection. CWE-20 is improper input validation. Common Weakness Enumeration (CWE) names the flaw type.

The Common Vulnerability Scoring System (CVSS) score is 3.1 9.1. That is critical. The vector shows no user interaction is needed beyond the admin login.

The 8.1 flaw that hands over the console

The second record is CVE-2026-115546. The gateway does not validate the chosen authentication source at sign on. An authenticated user with an active session can change the auth source parameter. The gateway then issues a SAML assertion for the Admin Console.

Security Assertion Markup Language (SAML) is the login token standard. A forged one opens the console door. The attacker never needed admin rights to start.

CVSS 3.1 scores it 8.1. That is high. The attack needs no privileges at all.

The chain is the point

Read the two together. A signed-in user becomes an admin through the 8.1 flaw. The new admin becomes command execution through the 9.1 flaw. Each fix ships in the same release. Partial patching leaves half the chain live.

Okta states both flaws are resolved in version 2026.10.2. The advisory recommends upgrading to 2026.10.2 or greater. Appliances on older builds are affected.

Neither CVE is in the CISA KEV catalog as of October 23, 2026. No exploitation has been reported. That status can change fast. The catalog only lists flaws already under attack.

The governance lesson

Identity systems deserve the shortest patch window you have. They broker every login. A flaw in the broker is a flaw in all doors it guards.

Access control evidence should show three things. Which admins can reach the console. What commands run under the service account. When each login happened. Least privilege is not a slogan here. It is the control that shrinks an admin console flaw into a small blast radius.

Flaw remediation evidence needs the same four answers as any patch. Version before. Version after. Change time. Proof that the new build is live. The Admin Console logs are the proof of the last step.

PolicyCortex does not patch Okta appliances. Okta ships the fix and admins apply it. PolicyCortex helps teams keep the evidence: what version ran, when it changed, and who touched the console.

One ask

Upgrade Okta Access Gateway to 2026.10.2 or greater this week. Review Admin Console logs back to October 1 for unusual sessions.

Sources

Questions on this record
Are these flaws being exploited?
No exploitation has been reported. Neither CVE appears in the CISA KEV catalog as of October 23, 2026. Patch before that changes.
What is Okta Access Gateway?
It is an appliance that puts Okta identity in front of apps. It brokers sign on to web applications. Its Admin Console manages that setup.
Does PolicyCortex patch Okta appliances?
No. Okta ships the fix and admins apply it. PolicyCortex helps teams keep the evidence: what version ran, when it changed, and who touched the console.

Related records

Guides and articles describe the work. The evidence that work produces is described in three proof pages and one architecture page.

proof.state
Proof of State. What the environment was, as of a date someone else picks: point-in-time records, content hashed and chained.
proof.change
Proof of Change. Who or what altered the environment, under what authority, with before and after state hashes.
proof.agency
Proof of Agency. What a machine was permitted to do before it acted, what it did, and what would have stopped it.
architecture
Architecture. How the chain is built and where it lives: inside your tenant, with no egress of evidence.

Further reading in this register

Verify the record this entry describes.

Published
Last updated
Unchanged since publication
Author
Leonard Esere