OpenObserve Accepted an Empty External Password for SSO and Migration-Created Users
Authentication code often stores more than one form of credential. A native password and an external password can coexist for the same account. OpenObserve's advisory for GHSA-7w4v-2c9r-q94v describes a case where the external value was empty and the validator still treated it as a usable credential.
The issue is tracked as CVE-2026-126065 and affects OpenObserve versions before 1.1.0.
The failure
When OpenObserve provisions users through enterprise SSO, custom-role SSO, cloud SSO first login or migration paths, it can create a record with an empty password_ext value. The application also generates a random internal password for the native credential, but that repair does not remove the empty external value.
The shared authentication validator accepts an empty or whitespace-only HTTP Basic password when the account's password_ext is missing or empty. An attacker who knows a victim's email address can therefore send a Basic Authorization header with that email and no meaningful password.
The result is authentication as the affected user. The advisory says the account can be mapped to the default organization and become an external Admin. The exact privileges depend on the account that was provisioned.
Who should check
This is most relevant to deployments that use SSO or have migrated user data. A local-only account with a non-empty external password record is a different configuration. Administrators should query the user store for null or empty external password values and map those records to their provisioning paths.
An empty result in one organization does not prove the entire deployment is safe. Check every organization and the code path that created each external identity. The advisory names multiple SSO paths because they reach the same vulnerable validator from different entry points.
Detection
Review authentication logs for successful HTTP Basic requests from external users who normally use SSO. Look for requests with a username matching an SSO account and an empty password field. Proxy logs may redact credentials, so use application audit records and authentication event context rather than trying to reconstruct passwords.
Check for new administrators, organization mappings and configuration changes after a suspicious login. The advisory describes account takeover, not only a failed login. Successful access can leave the same traces as a legitimate administrator.
Remediation
Upgrade to OpenObserve 1.1.0 or later. After upgrading, inspect all provisioned external users and remove or repair any empty password_ext values that remain. Rotate credentials and revoke sessions for accounts that may have been accessed.
If an upgrade is delayed, restrict the HTTP Basic authentication path at the reverse proxy and require the organization's normal SSO flow. Do not expose the application directly to the internet while the account store contains empty external credentials.
Limits of the evidence
The advisory points to a real authentication bypass and gives the affected version range. It does not show that a particular deployment was compromised. A direct login event, a new administrator or an unauthorized data query is the kind of evidence that should be joined to the vulnerable configuration before the incident is described as confirmed.
Top comments (0)