CVE-2026-123010 in netlify-okta-auth
Summary
by MITRE • 11/05/2026
@twilio-labs/netlify-okta-auth through 1.0.2 relies on an unverified iss claim. This affects an outbound HTTP request to retrieve a public signing key. There may be other impacts in a misconfiguration where oktaUrl isn't set.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in the twilio-labs/netlify-okta-auth package, affecting versions through 1.0.2, represents a critical flaw in the implementation of JSON Web Token (JWT) validation logic within an authentication middleware designed for Netlify environments integrated with Okta identity providers. The core technical deficiency lies in the failure to verify the issuer claim, commonly referred to as iss, during the token parsing and validation process. In standard OAuth 2.0 and OpenID Connect flows, the issuer claim is a mandatory field that identifies the principal that issued the JWT. By neglecting this verification step, the authentication module fails to ensure that the presented tokens originate from the expected Okta tenant or identity provider instance. This oversight creates a significant attack surface where an attacker can potentially forge valid-looking access tokens using keys from a different, maliciously controlled issuer, thereby bypassing legitimate authentication checks and gaining unauthorized access to protected resources.
The operational impact of this vulnerability is compounded by the specific mechanism used for key retrieval. The application relies on an outbound HTTP request to fetch public signing keys, typically via the JWKS (JSON Web Key Set) endpoint provided by the identity provider. While fetching keys dynamically is a standard practice to support key rotation, it introduces complexity regarding trust boundaries. If the issuer claim is not strictly validated against the expected Okta domain or tenant ID before accepting tokens signed with these keys, an attacker could exploit misconfigurations where the oktaUrl parameter is either unset or incorrectly configured. In such scenarios, the application might accept tokens from any source that presents a valid signature relative to fetched public keys, effectively nullifying the authentication barrier. This lack of strict issuer validation means that even if key retrieval functions correctly, the fundamental trust anchor required to link those keys to a specific identity provider is missing, allowing for token substitution attacks where credentials issued by one entity are accepted as valid for another.
From a classification perspective, this vulnerability aligns with CWE-287, which denotes Improper Authentication, specifically falling under scenarios involving insufficient verification of claims in authentication protocols. It also relates to CWE-345, Insufficient Verification of Data Authenticity, as the system fails to adequately verify that the data (the JWT) originates from a trusted source. In terms of adversary tactics, this flaw facilitates Initial Access techniques described in MITRE ATT&CK under T1078, Valid Accounts, by allowing attackers to use forged or stolen tokens to impersonate legitimate users without needing valid credentials for the specific target environment. The risk is particularly acute in serverless and edge computing environments like Netlify, where authentication logic often runs at the edge with limited visibility into backend state, making robust client-side validation of token properties essential for security integrity.
To mitigate this vulnerability, immediate remediation requires upgrading to a patched version of the netlify-okta-auth package that enforces strict issuer verification. Developers must ensure that the configuration explicitly sets the oktaUrl parameter to point exclusively to their organization's specific Okta domain, preventing ambiguity in key source identification. Furthermore, security best practices dictate implementing additional validation layers such as verifying the audience claim (aud) to ensure the token is intended for this specific application and checking expiration times (exp) rigorously. It is also advisable to implement certificate pinning or strict URL allowlisting for the JWKS endpoint fetch operation if possible, although standard HTTPS verification combined with issuer string matching against a known whitelist of trusted Okta domains remains the primary defense. Regular security audits of authentication middleware configurations should be conducted to ensure that no optional parameters are left unset in production environments, thereby closing potential gaps where misconfigurations could lead to unauthorized access.