Okta has revealed a serious vulnerability in its Access Gateway appliance—one that grants authenticated administrators the ability to execute system commands via the Admin Console. Identified as CVE-2026-115547, the flaw impacts all Access Gateway versions released before 2026.10.2 and carries a CVSS v3.1 severity rating of 9.1.
The root issue stems from inadequate input validation in the Admin Console’s handling of certain specially crafted configuration values. Rather than being treated purely as configuration data, some values are processed in such a way that they can trigger system-level command execution under the gateway’s service account.
What Access Gateway Is & The Risk
Okta Access Gateway is designed to bridge on-premises applications with Okta’s identity platform, acting as a secure proxy for workloads that cannot be moved fully to the cloud. In this context, allowing arbitrary command execution—even just under a service account—can open doors to broad system compromise depending on privileges and what that account can access.
The vulnerability is categorized under CWE-94 (improper control of code generation) and CWE-20 (improper input validation). Crucially, an attacker must already have administrative access to the Access Gateway Admin Console for exploitation. There is no indication that the flaw allows attackers to bypass authentication or gain admin rights from a lower privileged account.
Implications & Remediation
When exploited, the vulnerability runs commands with the permissions of the “OAG service account.” While this isn’t equivalent to full root access, the impact depends heavily on how that account is provisioned. The advisory doesn’t specify which configuration field is vulnerable or include an exploit, and there’s no evidence yet of active abuse.
The fix is straightforward: organizations running versions older than 2026.10.2 must upgrade to version 2026.10.2 or later. Earlier updates like Access Gateway 2026.9.1 do not include the patch. Besides patching, administrators are urged to audit who has console access and monitor for unauthorized changes to configuration settings.
There’s no reported exploit in the wild at this time, and Okta hasn’t provided a workaround beyond upgrading. That said, defenders should prepare as if abuse is possible—reviewing service-account permissions and access controls is essential.
Analytically, this flaw underscores a recurring reality: even strong perimeter defenses aren’t enough if internal admin controls are weak. Breaches often trace back to “trusted” administrative accounts. What to watch next: whether Okta discloses details of the vulnerable configuration field, if proof-of-concepts surface, or if any incidents of exploitation are reported. Teams that keep privilege minimal and update quickly will be least exposed.
