OpenObserve's Small Fingerprint Still Requires an Identity Audit

An observability platform often holds logs, traces and metrics from many systems. Authentication defects in that plane can expose operational data even when the external asset count is modest.

ZoomEye count-only queries were run with sub_type=all, page 1 and page size 1 on 2026-11-13 between 07:40 and 07:42 Asia/Shanghai.

The title count is much larger than the exact application count. Both describe matching assets, not confirmed vulnerable installations.

The identity issue

GHSA-7w4v-2c9r-q94v covers OpenObserve versions before 1.1.0 and is tracked as CVE-2026-126065. The authentication validator accepts an empty or whitespace-only HTTP Basic password for accounts whose external password is null or empty.

SSO provisioning and migration paths can create those records. The native password can be repaired with a random value while the external password remains empty. An attacker who knows the account email can use it as a username with a blank password.

The ZoomEye result cannot reveal the password_ext field, the enabled SSO path or the account privileges. Those facts come from the application database and identity configuration.

Triage the candidate set

Confirm that each matching host is an OpenObserve deployment owned by the organization. Record the version, public or private access path, reverse-proxy policy and identity provider.

For versions before 1.1.0, inspect external user records for null or empty password_ext. Review accounts created by enterprise SSO, custom-role SSO, cloud SSO first login and migration.

Search authentication logs for successful Basic requests from accounts that normally use SSO. Review administrator creation, organization mapping and queries against sensitive streams.

Priority

Start with internet-reachable instances and those with the widest log ingestion. A deployment with no external users is still worth checking because migration-created records may not be obvious from the current SSO membership.

Restrict Basic authentication at the proxy while the account store is reviewed. Do not assume a login page with SSO branding rules out the Basic path.

Remediation

Upgrade to 1.1.0 or later. Repair or remove empty external password values, rotate credentials and revoke sessions for potentially accessed accounts.

After the update, test an SSO-provisioned account with a blank Basic password and confirm rejection. Test a normal SSO login to ensure the remediation did not break the intended flow.

Evidence retention

Keep the ZoomEye queries, totals, scope and time with the host inventory. Link each matching asset to its version and identity check. If the public fingerprint disappears, the historical evidence still explains why the host remains in the review.

References

• GitHub Security Advisory GHSA-7w4v-2c9r-q94v
• ZoomEye AI