The Okta Access Gateway does not sanitize the application label field before including it in the generated nginx configuration file. The unsanitized value is interpolated into an nginx server block directive, resulting in execution of injected directives.

The Okta Access Gateway does not sanitize SAML assertion values before interpolating them into database queries in the advanced mode datastore configuration. The unsanitized values are substituted directly into the query string prior to preparation, resulting in unintended SQL execution against the configured backend database.

The Okta Access Gateway management console passes user-supplied input to eval() without sanitization during an authenticated administrator SSH session. As a result, the unsanitized input is executed directly, leading to code execution with the privileges of the management console.

The Okta Access Gateway does not apply its Lua directive restriction to the application-level custom configuration field. The field is interpolated directly into the nginx server block without inspection, resulting in execution of injected directives.

The Okta Access Gateway does not sanitize dashboard label values before writing them into generated PHP configuration files. The generated file is automatically included during authentication requests, resulting in execution with the privileges of the web server process.

The Okta Hyperdrive Integration installer does not mask the OAuth client secret when passed as an MSI property. The credential is recorded in plaintext in the installer log, the Application Event Log, and the process command line, all of which are readable by an authenticated local user on the workstation.

The Okta Access Gateway improperly handles input sanitization and regular expression evaluation within its Protected Rule authorization check, resulting in an authorization bypass when an administrator has explicitly configured a Protected Rule policy on one or more application resources.

The Okta Access Gateway does not neutralize shell metacharacters in SNMP configuration values before a privileged script uses them to construct OS commands. An authenticated local user with access to the management interface can supply crafted values, resulting in the execution of arbitrary OS commands with root privileges.

The Okta Hyperdrive Agent writes the decoded SAML bearer assertion to a local application log file at the default log level on every successful MFA completion. This insertion of sensitive information into the log file makes a live authentication credential readable by any local user with access to the log file.

The Okta Hyperdrive agent plugin returns a success response without a signed SAML assertion when the organization's policy requires no MFA for a given user. The response contains only a bare boolean validation indicator with no cryptographic artifact, resulting in an unverifiable authentication verdict being delivered to the relying application.

The Okta Access Gateway does not sanitize SAML assertion attribute values before interpolating them into LDAP search filters in the LDAP datastore configuration. The raw values are substituted directly into the filter string and passed to the LDAP search operation, resulting in modification of the intended query logic.

The Okta Access Gateway Kerberos configuration handler does not validate file paths specified in event payloads before writing file contents. The path from the event payload is used directly as the write destination, resulting in files being written to unintended locations on the appliance filesystem.

The Okta Access Gateway backup restore function does not validate the filename embedded in an encrypted backup payload. This results in writing file contents to unintended locations on the appliance filesystem.

The Okta Hyperdrive Integration plugin resolves a required assembly using a registry path within the current user's hive without integrity verification. The referenced path is loaded via Assembly.LoadFrom without signature validation, resulting in an unverified assembly executing within the context of the host process or elevated installer.

The Okta Access Gateway includes an optional pass-through authentication source that accepts user identity from a client-supplied HTTP header without cryptographic validation. In architectures where this optional source is enabled without an upstream reverse proxy or firewall configured to sanitize and enforce client headers, an unauthenticated user can supply an arbitrary identity value to initiate a session.

The Okta Verify for Windows uninstaller does not verify whether the user data directory is a filesystem junction before deleting its contents with elevated privileges. The delete operation follows the junction target, resulting in recursive deletion of unintended directory contents.

Okta On-Premises Provisioning (OPP) agents log certain user data during administrator-initiated password resets. This vulnerability allows an attacker with access to the local servers running OPP agents to retrieve user personal information and temporary passwords created during password reset. You are affected by this vulnerability if the following preconditions are met: Local server running OPP agent with versions >=2.2.1 and <= 2.3.0, and User account has had an administrator-initiated password reset while using the affected versions.

The Auto-update service for Okta Verify for Windows is vulnerable to two flaws which in combination could be used to execute arbitrary code.

Description In the Okta Java SDK, race conditions may arise from concurrent requests using the ApiClient class. This could cause a status code or response header from one request’s response to influence another request’s response.

Affected product and versions You may be affected if you meet the following preconditions: - Using the Okta Java SDK between versions 11.0.0 and 20.0.0, and - Implementing a multithreaded application with the ApiClient class where the response status code is used in access control flows

Resolution Upgrade Okta/okta-sdk-java to versions 21.0.0 or greater.

Description In the Okta Java SDK, specific multithreaded implementations may encounter memory issues as threads are not properly cleaned up after requests are completed. Over time, this can degrade performance and availability in long-running applications and may result in a denial-of-service condition under sustained load.

Affected product and versions You may be affected by this vulnerability if you meet the following preconditions: - Using the Okta Java SDK between versions 21.0.0 and 24.0.0, and - Implementing a long-running application using the ApiClient in a multi-threaded manner.

Resolution Upgrade Okta/okta-sdk-java to versions 24.0.1 or greater.

Acknowledgement Okta would like to thank Andrew Pikler (pyckle) for their discovery and responsible disclosure.

An open redirect vulnerability exists in Okta OIDC Middleware prior to version 5.0.0 allowing an attacker to redirect a user to an arbitrary URL.

Okta Advanced Server Access Client versions 1.13.1 through 1.65.0 are vulnerable to command injection due to the third party library webbrowser. An outdated library, webbrowser, used by the ASA client was found to be vulnerable to command injection. To exploit this issue, an attacker would need to phish the user to enter an attacker controlled server URL during enrollment.

Okta Privileged Access server agent (SFTD) versions 1.82.0 to 1.84.0 are affected by a privilege escalation vulnerability when the sudo command bundles feature is enabled. To remediate this vulnerability, upgrade the Okta Privileged Access server agent (SFTD) to version 1.87.1 or greater.

The Okta Device Access features, provided by the Okta Verify agent for Windows, provides access to the OktaDeviceAccessPipe, which enables attackers in a compromised device to retrieve passwords associated with Desktop MFA passwordless logins. The vulnerability was discovered via routine penetration testing.

Note: A precondition of this vulnerability is that the user must be using the Okta Device Access passwordless feature. Okta Device Access users not using passwordless are not affected, and customers only using Okta Verify on platforms other than Windows, or only using FastPass are not affected.

A vulnerability in Okta Verify for iOS versions 9.25.1 (beta) and 9.27.0 (including beta) allows push notification responses through the iOS ContextExtension feature allowing the authentication to proceed regardless of the user’s selection. When a user long-presses the notification banner and selects an option, both options allow the authentication to succeed. The ContextExtension feature is one of several push mechanisms available when using Okta Verify Push on iOS devices. The vulnerable flows include: When a user is presented with a notification on a locked screen, the user presses on the notification directly and selects their reply without unlocking the device; When a user is presented with a notification on the home screen and drags the notification down and selects their reply; When an Apple Watch is used to reply directly to a notification.

A pre-condition for this vulnerability is that the user must have enrolled in Okta Verify while the Okta customer was using Okta Classic. This applies irrespective of whether the organization has since upgraded to Okta Identity Engine.

Imprivata Privileged Access Management (formally Xton Privileged Access Management) 2.3.202112051108 allows XSS.

The LDAP Agent Update service with versions prior to 5.18 used an unquoted path, which could allow arbitrary code execution.