Okta has fixed two Okta Access Gateway (OAG) flaws in version 2026.10.2: one lets an authenticated administrator run system commands, and the other may let a signed-in user obtain Admin Console access. A separate Okta advisory on PHP runtime flaws sets a later fix version, 2026.44.0, so 2026.10.2 shouldn't be your stopping point.
What happened
Okta published both advisories on October 22, 2026. Each applies to appliance versions before 2026.10.2, and neither lists a workaround.
- CVE-2026-115547 (CVSS 9.1): An input validation gap in how the Admin Console handles crafted configuration values gives someone already signed in as an administrator a way to issue system commands, which run under the OAG service account.
- CVE-2026-115546 (CVSS 8.1): At sign-on, the gateway performs no check on which authentication source was chosen. Someone holding a valid session for any configured source can tamper with that parameter, and the outcome may be a SAML assertion that opens the Admin Console.
The same day, Okta published a third advisory for CVE-2026-109618 and CVE-2026-109619, the PHP runtime flaws known as PHP2Shell. It covers appliance versions below 2026.44.0 and says the default configuration mitigates known exploitation, without naming the settings involved. CISA added both flaws to its Known Exploited Vulnerabilities catalog on October 26, listed under PHP rather than Access Gateway.
Exploitation status for the two OAG-specific flaws comes from secondary sources, because Okta's advisories don't address it. SQ Magazine reports that CISA's SSVC assessment for CVE-2026-115547, timestamped October 23, lists exploitation as "none" and automatable as "no." Daily CyberSecurity's vulnerability table marks both CVEs as not exploited. Treat those as point-in-time readings, not vendor confirmation.
Why it matters
Read together, the two flaws suggest a path from an ordinary session to commands on the appliance: CVE-2026-115546 could put a signed-in user in the Admin Console, where CVE-2026-115547 applies. That chain is our inference. Okta published them separately and doesn't describe them as linked, its wording for the first step is conditional, and the 8.1 vector rates attack complexity as high.
Still, it changes how to read the 9.1 score. Until both are patched, the administrator requirement isn't a limit you can fully rely on.
CVE-2026-115546 is also a federation design lesson. The failed check concerns which authentication source was selected, so the exposed population is anyone with a session from any source on that gateway. Your least-controlled source sets the bar. The advisories don't say what the service account can reach, so don't assume the impact stops at the appliance.
The version numbers are easy to misread. Third-party posts cite both 2026.10.2 and 2026.44.0, and both come from Okta, for different CVEs.
What to check in your environment
- Inventory every appliance. Record the version on each node, including high-availability workers, and compare it to 2026.10.2 and 2026.44.0.
- Target 2026.44.1. Okta's release notes tell customers on versions before 2026.44.0 to upgrade directly to this bug fix release, which has the same security enhancements as 2026.44.0. It also addresses intermittent HTTP 503 errors in versions 2026.9.2 through 2026.44.0.
- Prepare the change. Okta's upgrade guide calls for a snapshot or backup and access from the appliance to
yum.oag.okta.comon port 443. Upgrade workers first and the admin node last, and expect three to five minutes offline. - List authentication sources. Note who can get a session through each source on each gateway. Okta doesn't offer source removal as a mitigation, so use this to set patch priority and scope log review.
- Review Admin Console access. Confirm who holds it and remove stale accounts. Until you've patched, treat each account as able to run commands on the appliance.
- Review sign-in and change logs. Look for Admin Console sign-ins by non-administrators and configuration changes nobody can account for. The advisories publish no indicators, so a clean review isn't proof.
- Check for configuration drift. Okta's PHP2Shell mitigation statement covers the default configuration only, so prioritize customized appliances. Federal teams should also check the October 29 KEV due date and forensic triage requirement.
References
- Okta: Command Execution via Admin Console Input
- Okta: Authentication Source Verification Issue
- Okta: PHP Runtime Vulnerabilities
- Okta: Access Gateway release notes
- Okta: Upgrade Access Gateway
- CISA: Known Exploited Vulnerabilities catalog
- SQ Magazine: Okta Access Gateway CVE-2026-115547
- Daily CyberSecurity: Okta Access Gateway vulnerabilities