CVE-2026-115547 · Okta Access Gateway Admin Console OS command injection via specially…

01 · The Real Story

Someone left the master key maker's toolbox unlocked, and the locksmith shop controls every door in the building

CVE-2026-115547 is an OS command injection in the Okta Access Gateway (OAG) Admin Console. Specially formatted configuration values pass through unsanitized and execute as the OAG service account. The flaw affects all OAG versions prior to 2026.10.2 (also fixed in 2026.44.0). OAG is a virtual-appliance identity gateway — deployed on-prem or in hybrid cloud — that bridges enterprise applications to Okta's cloud IdP via SAML and OIDC. Compromise of this component means an attacker can forge SAML assertions, intercept authentication traffic, and access every application the gateway fronts. CWE-20 (Improper Input Validation) and CWE-94 (Code Injection) both apply.

Okta rates this CRITICAL at 9.1 with CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H. The PR:H (admin required) looks like a meaningful brake — and standalone, it is. But two real-world factors complicate the picture. First, CVE-2026-115546 (CVSS 8.1, same advisory, same fix) allows any authenticated user with a session on *any* configured authentication source to forge a SAML assertion granting Admin Console access, effectively collapsing PR:H to PR:L in a chained scenario. Second, since February 2025 Okta restricts new OAG admin consoles to RFC 1918 addresses — meaning AV:N overstates reachability for current deployments. These two factors push in opposite directions: the private-network restriction adds friction, but the companion auth bypass removes it. On balance, the vendor's CRITICAL rating is defensible, though the 9.1 score slightly overstates network reachability. We reassess at CRITICAL 8.7.

"Admin-console RCE in Okta's identity gateway — blast radius floors this at CRITICAL despite PR:H"

02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach the OAG Admin Console

The attacker must establish network connectivity to the OAG admin node. Since February 2025, new OAG instances restrict the Admin UI Console to RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16). The admin hostname should not resolve in public DNS per Okta deployment guidance. The admin node sits outside the DMZ in a restricted management segment, separate from the DMZ-hosted worker nodes that handle end-user traffic on port 443.

Conditions required:

Internal network position or VPN access to the OAG management segment
Ability to resolve the OAG admin hostname (internal DNS only)

Where this breaks in practice:

Post-Feb-2025 deployments enforce RFC 1918 IP restrictions on the admin console
Admin node is architecturally separated from internet-facing worker nodes in the DMZ
Admin hostname should not be publicly DNS-resolvable

Detection/coverage: Network IDS/firewall logs for unexpected connections to the OAG admin node IP; DNS query monitoring for admin hostname lookups from non-management subnets

STEP 02

Obtain administrator access

Standalone exploitation requires valid OAG administrator credentials — a high bar. However, CVE-2026-115546 (CVSS 8.1, same advisory batch, same fix version) eliminates this requirement: OAG fails to validate the selected authentication source during sign-on, allowing any user with a valid session on *any* configured auth source to modify the authentication source parameter and generate a SAML assertion granting Admin Console access. This drops the effective privilege requirement from admin to any authenticated user.

Conditions required:

Valid OAG admin credentials (standalone path) OR valid session on any OAG-configured authentication source + CVE-2026-115546 (chained path)

Where this breaks in practice:

OAG admin credentials are typically held by a small infrastructure team (2-5 people)
Chaining CVE-2026-115546 requires a separate exploit and understanding of the auth-source manipulation
MFA enforcement on admin console login (if configured) adds an additional layer

Detection/coverage: Admin Console authentication audit logs; anomalous SAML assertion issuance for admin-scoped sessions; Okta system log events for OAG admin sign-on from unexpected users

STEP 03

Inject malicious configuration values

With authenticated admin access to the OAG Admin Console (browser-based UI on port 443), the attacker submits specially formatted configuration values through console input fields. The input validation flaw (CWE-20 / CWE-94) fails to sanitize these values before they are processed by the backend. A Nuclei template reportedly exists for detection of this injection point, which also lowers the research barrier for weaponization.

Conditions required:

Authenticated admin session on OAG Admin Console
Knowledge of the injectable configuration field(s) and the required payload format

Where this breaks in practice:

No fully weaponized public exploit or standalone PoC repo found on GitHub or ExploitDB as of disclosure
Nuclei template provides detection but requires adaptation for active exploitation
The specific injectable fields are not publicly documented in detail

Detection/coverage: OAG configuration change audit trail; application-layer inspection of Admin Console POST requests for command-injection patterns (; | && $())

STEP 04

Execute OS commands as OAG service account

The backend processes the injected configuration values, executing attacker-supplied system commands in the context of the OAG service account. This is OS-level command execution on the OAG virtual appliance. The service account context determines the immediate blast radius — it has access to OAG's SAML signing keys, application definitions, routing configuration, and network position bridging DMZ to internal networks.

Conditions required:

Successful command injection from Step 3

Where this breaks in practice:

OAG service account may not be root — appliance hardening constrains some post-exploitation paths
Virtual appliance environment may have limited tooling for lateral movement

Detection/coverage: Process execution monitoring (auditd, osquery, EDR if deployed on appliance) for anomalous child processes spawned by OAG/web server process; file integrity monitoring on OAG configuration directories

STEP 05

Pivot to identity-scale compromise

From the OAG service account, the attacker can extract SAML signing certificates and private keys, forge assertions for any application behind the gateway, intercept authentication traffic transiting the gateway, modify application routing to redirect users to attacker-controlled infrastructure, or pivot laterally via the OAG's network position bridging the DMZ and internal segments. This constitutes tenant-scale identity compromise.

Conditions required:

OAG service account access from Step 4
Understanding of OAG internals: SAML key storage, application definitions, network routing

Where this breaks in practice:

Post-exploitation requires OAG-specific knowledge not publicly documented in exploit toolkits
SAML key extraction and assertion forging require cryptographic tooling and understanding of target SP configurations

Detection/coverage: SIEM correlation of OAG admin alerts with downstream authentication anomalies; certificate access and export monitoring; anomalous SAML assertion patterns (unexpected issuers, unusual assertion attributes)

03 · Compensating Control

CRITICAL 8.7→IGNORE 0.0

SEVERITY REDUCED

Patch to OAG 2026.10.2 immediately — The definitive fix. OAG 2026.10.2 addresses CVE-2026-115547, the companion CVE-2026-115546 auth bypass, and the PHP2Shell RCE bugs (CVE-2026-109618/109619). Per the noisgate mitigation SLA for CRITICAL, deploy within 3 days. OAG appliance upgrades are performed through the Management Console and require a maintenance window. Coordinate with your Okta admin team to schedule.

CRITICAL 8.7→HIGH 6.5

SEVERITY REDUCED

Restrict admin console access to dedicated PAWs or jump hosts — Tighten the admin console IP allowlist beyond RFC 1918 to only Privileged Access Workstations (PAWs) or a specific jump host. This collapses the reachable attacker population from 'anyone on the internal network' to 'operators of 2-3 hardened management stations.' Implement as a firewall rule on the OAG admin node or via the OAG admin console IP restriction settings. Deploy within 3 days per noisgate mitigation SLA.

CRITICAL 8.7→HIGH 7.0

SEVERITY REDUCED

Enforce MFA on OAG Admin Console authentication — If not already enforced, require multi-factor authentication for all OAG Admin Console logins. This mitigates both credential-theft scenarios (standalone path) and partially disrupts the CVE-2026-115546 chain by adding an authentication factor the SAML assertion forgery may not satisfy. Configure via Okta authentication policies for the OAG admin app. Deploy within 3 days.

CRITICAL 8.7→CRITICAL 8.5

Enable and alert on OAG configuration change audit logs — Ensure OAG Admin Console configuration changes are logged and forwarded to your SIEM. Create high-fidelity alerts for any configuration modification — especially from unexpected source IPs or user accounts. This is a detective control and does not prevent exploitation, but it compresses attacker dwell time. Deploy within 3 days.

CRITICAL 8.7→CRITICAL 8.7

Rotate OAG SAML signing certificates post-patch — After patching, rotate the SAML signing certificates and private keys stored on the OAG appliance. If an attacker already exploited this vulnerability, they may have extracted signing material. Rotation invalidates any exfiltrated keys. Coordinate with downstream SP owners to update trust anchors. Complete within 7 days of patching.

What doesn't work

WAF in front of the application tier — the admin console is on a separate management network segment, not behind the WAF that protects the data-plane worker nodes. WAF rules will not inspect traffic to the admin console.
Revoking non-admin user accounts to block CVE-2026-115546 chain — CVE-2026-115546 works with *any* valid session on *any* configured authentication source; you cannot disable all user accounts without taking down the service. The fix is patching, not account revocation.
Network segmentation of OAG worker nodes from internal resources — worker nodes are already in the DMZ by architecture. The vulnerable component is the *admin node*, which sits outside the DMZ in the management segment. Segmenting workers does not protect the admin node.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	No active exploitation reported. Not listed in CISA KEV. No GreyNoise or Shadowserver scanning activity observed for this CVE as of disclosure date (2026-10-23).
Proof-of-concept availability	Nuclei template reportedly available per SecurityOnline. No dedicated GitHub repository (e.g., `CVE-2026-115547`) found. Not indexed on ExploitDB or Metasploit. pocindex.io did not return results for this CVE ID.
EPSS score	Not yet scored — CVE disclosed 2026-10-23 (today). EPSS data typically populates within 24-48 hours of NVD publication.
CISA KEV status	Not listed. No known exploitation in federal or private-sector environments as of disclosure.
CVSS vector interpretation	`CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H` — The S:C (Changed Scope) is the severity driver, reflecting that exploitation on the OAG appliance impacts resources beyond the vulnerable component (downstream apps, identity infrastructure). PR:H is the primary brake.
Affected versions	Okta Access Gateway < 2026.10.2 (all prior versions including 2026.10.1 and earlier)
Fixed versions	OAG 2026.10.2 and OAG 2026.44.0. No distro backports applicable — OAG is a vendor-managed virtual appliance (OVA).
Companion vulnerabilities	CVE-2026-115546 (CVSS 8.1, auth source bypass → admin access); CVE-2026-109618 (CVSS 9.2, PHP RCE via OOM corruption); CVE-2026-109619 (CVSS 9.2, PHP2Shell RCE via stale global state). All patched in OAG 2026.10.2.
Exposure surface	OAG Admin Console restricted to RFC 1918 addresses since February 2025. Admin hostname should not resolve in public DNS. Worker nodes (data plane) are DMZ-facing on port 443. Shodan/Censys exposure data not available for OAG admin consoles specifically due to private-network restriction.
Disclosure & credit	Disclosed 2026-10-22/23 via Okta security advisory on trust.okta.com. Researcher credit not publicly attributed in available sources. Advisory covers four CVEs across three advisories in the same OAG release.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (8.7/10)

Why this verdict

PR:H is already priced into the 9.1 CVSS — the vendor vector explicitly includes PR:H, so the admin-only requirement is not additional friction beyond what the score already reflects. The real question is whether real-world conditions amplify or attenuate that baseline.
Admin console network restriction (AV:N → effectively AV:A): Since February 2025, OAG admin consoles are restricted to RFC 1918 private ranges. The CVSS AV:N overstates reachability for current deployments. This is the primary basis for the 0.4-point score reduction from 9.1 to 8.7. Pre-2025 legacy deployments may still expose the admin console more broadly.
CVE-2026-115546 chain collapses PR:H to PR:L in practice: The companion auth-source bypass (same advisory, same fix) allows any user with a valid session on any configured OAG authentication source to generate a SAML assertion granting admin access. This substantially weakens the standalone PR:H friction for environments that haven't yet patched.
Role multiplier — identity gateway (100% high-value role): Okta Access Gateway is *canonically* identity infrastructure. 100% of OAG deployments serve as SAML/OIDC identity gateways bridging enterprise applications to Okta's cloud IdP. Compromise yields: SAML signing key extraction → assertion forgery for all downstream SPs → tenant-scale identity compromise. This is identity-scale blast radius by definition. The floor for canonical identity infrastructure with identity-scale outcome is CRITICAL. No friction can pull below this floor.
No exploitation or weaponized PoC tempers urgency, not severity: The absence of active exploitation and the lack of a public weaponized exploit reduce the *immediacy* of the threat but do not reduce the *potential impact*. A Nuclei template already exists, and the four-CVE advisory batch (including two CVSS 9.2 PHP RCE bugs) makes OAG an attractive target for focused research.

Why not higher?

The vendor's 9.1 is the highest reasonable score. AV:N overstates reachability given the RFC 1918 admin console restriction enforced since February 2025 — real-world network access is closer to AV:A (adjacent/internal) for current deployments. No active exploitation or weaponized PoC exists at disclosure, and the admin prerequisite, while chainable via CVE-2026-115546, still requires a multi-step attack. A score above 9.1 is not warranted.

Why not lower?

Dropping below CRITICAL is blocked by the deployment-role floor: OAG is canonical identity infrastructure (IdP gateway, SAML assertion issuer) where 100% of installations occupy the high-value role. The documented chain — especially when incorporating CVE-2026-115546's auth bypass — terminates in identity-scale compromise (SAML key theft, assertion forgery for all downstream applications). The private-network restriction on the admin console is meaningful friction but does not eliminate the threat — internal attackers, VPN-connected users, and anyone who chains CVE-2026-115546 from a valid session can still reach the admin console. Generic 'requires internal access' is insufficient to break a CRITICAL floor for identity infrastructure.

06 · Verification

Crowdsourced verification payload.

Run this script on the OAG appliance via SSH as root or the oag-admin user. Usage: bash check_cve_2026_115547.sh. The script checks the installed OAG version against the fixed version (2026.10.2) and exits with code 0 (PATCHED), 1 (VULNERABLE), or 2 (UNKNOWN).

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-115547 — Okta Access Gateway version checker
# Run on the OAG appliance via SSH as root or oag-admin.
# Exit codes: 0 = PATCHED, 1 = VULNERABLE, 2 = UNKNOWN
set -euo pipefail

FIXED="2026.10.2"
OAG_VER=""

# Method 1: Check known version file locations
for vfile in /opt/oag/version /opt/okta/access-gateway/version /etc/oag-release /opt/oag/.version; do
  if [[ -f "$vfile" ]]; then
    OAG_VER=$(grep -oP '[0-9]+\.[0-9]+\.[0-9]+' "$vfile" 2>/dev/null | head -1)
    [[ -n "$OAG_VER" ]] && break
  fi
done

# Method 2: RPM query fallback
if [[ -z "$OAG_VER" ]]; then
  OAG_VER=$(rpm -q --queryformat '%{VERSION}' okta-access-gateway 2>/dev/null || true)
fi

# Method 3: Check running process version string
if [[ -z "$OAG_VER" ]]; then
  OAG_VER=$(strings /opt/oag/bin/oag-server 2>/dev/null | grep -oP '^[0-9]{4}\.[0-9]+\.[0-9]+$' | head -1 || true)
fi

if [[ -z "$OAG_VER" ]]; then
  echo "UNKNOWN — Could not determine OAG version."
  echo "Verify manually: OAG Admin Console > Settings > About, or contact Okta support."
  exit 2
fi

echo "Detected OAG version : $OAG_VER"
echo "Fixed version        : $FIXED"
echo "CVE                  : CVE-2026-115547"
echo "---"

# sort -V handles dotted-version comparison correctly
if printf '%s\n%s' "$FIXED" "$OAG_VER" | sort -V -C 2>/dev/null; then
  echo "PATCHED — OAG $OAG_VER >= $FIXED"
  exit 0
else
  echo "VULNERABLE — OAG $OAG_VER < $FIXED (CVE-2026-115547)"
  echo "Action: Upgrade to OAG 2026.10.2+ immediately."
  exit 1
fi