OpenObserve EUVD-2026-86328

Exploitable against default configurations because /config/runtime is registered without authentication and requires no user interaction (AV:N/AC:L/PR:N/UI:N) - any client with network reachability to the instance can trigger it. The MOST severe outcome (plaintext database credentials) is LIMITED to deployments using the PostgreSQL metadata backend, since the leaked meta_postgres_dsn/meta_postgres_ro_dsn/meta_ddl_dsn/usage_reporting_creds fields only carry credentials in that configuration; other deployments still leak root admin email, internal NATS address, and filesystem layout. Realistic risk is further gated by whether the instance is exposed to untrusted networks (e.g., internet-facing) versus isolated behind internal-only access. Affected versions are prior to 0.90.3.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, base 7.5) is well-supported by the description: the /config/runtime endpoint is registered with no authentication and is reachable by any network client, requiring no user interaction and no special conditions on a default install. The confidentiality-only impact (C:H, I:N, A:N) is appropriate because the flaw leaks secrets rather than modifying state - but that leak is severe on PostgreSQL-backed deployments, where meta_postgres_dsn/meta_postgres_ro_dsn/meta_ddl_dsn expose full database connection strings (credentials included), enabling downstream compromise of the backing store. No EPSS score, KEV entry, POC, or SSVC decision data was provided, so exploitation-likelihood signals are absent; per the precision rules this is 'no public exploit identified at time of analysis.' The fix is confirmed (PR #12220 removes the /runtime and /reload routes; commit 4f3db1cf; release v0.90.3), and the root cause - a hide_sensitive_fields keyword filter that does not recognize 'dsn' or 'creds' substrings - is concrete and easily weaponized. Net: this is a genuine, high-value unauthenticated information-disclosure issue for exposed instances, tempered by the fact that OpenObserve is a moderately-deployed platform rather than ubiquitous infrastructure, so realistic risk depends heavily on whether the instance is internet-reachable and PostgreSQL-backed.

An unauthenticated attacker who can reach an OpenObserve instance sends a single GET request to /config/runtime and receives the full server configuration serialized as JSON. Because the sensitive-field filter misses 'dsn' and 'creds' names, the response includes plaintext PostgreSQL DSNs (with credentials), the root admin email, internal NATS address, and filesystem layout, which the attacker then uses to connect directly to the backing database. No public exploit code is identified, but the attack is a trivial single HTTP GET requiring no authentication or tooling.