Summary
OpenObserve versions before 0.90.3 expose the unauthenticated /config/runtime endpoint, which can return sensitive server configuration data in plaintext. Because the filtering logic does not recognize certain DSN and credentials field names, an unauthenticated network client may obtain database credentials and internal deployment details.
Affected context
The issue occurs in OpenObserve deployments where the /config/runtime endpoint is reachable without authentication and the server serializes its complete configuration for the response. Sensitive values may remain visible when configuration field names use DSN- or credentials-related names that are not covered by the sensitive-field filtering logic. PostgreSQL-backed deployments may be particularly exposed because database connection credentials can be included.
Exploit preconditions
- Attack surface: Network-accessible
/config/runtimeendpoint - Required access: No authentication may be required when the endpoint is exposed
- Trigger point: A request that causes the server to serialize and return runtime configuration
- Why exposure is possible: The filtering mechanism does not classify certain DSN and credentials fields as sensitive before serialization
Why this happens
The vulnerability results from incomplete sensitive-data filtering combined with unauthenticated access to a configuration-disclosure endpoint. Field-based redaction relies on a narrow set of recognized names, while sensitive values such as database DSNs and reporting credentials use alternate names that are returned unchanged. This behavior maps to CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, because confidential configuration data is disclosed to clients that have not been authorized to receive it.
Potential impact
- Database credentials could be disclosed
- Unauthorized parties could access connected PostgreSQL services
- The root administrator email address could be revealed
- Internal NATS addresses and filesystem paths could be exposed
- Attackers could use deployment details to support further intrusion or lateral movement
- Operational and tenant-related information could be used for reconnaissance
General mitigation guidance
Mitigation generally focuses on reducing configuration disclosure and ensuring that sensitive data is never serialized into unauthenticated responses.
Common defensive patterns include:
- Requiring strong authentication and authorization for runtime configuration endpoints
- Applying deny-by-default redaction for secrets, credentials, DSNs, tokens, and connection strings
- Using structured secret classification rather than relying only on field-name matching
- Returning only an explicit allowlist of non-sensitive operational fields
- Keeping database credentials and reporting secrets outside general runtime configuration responses
- Limiting network exposure through internal routing, access controls, and segmentation
- Applying least privilege to database accounts and service identities
- Rotating credentials when configuration disclosure is suspected
How teams detect issues like this
Organizations can detect this class of issue through:
- API inventory reviews that identify configuration and diagnostic endpoints
- Dynamic testing for unauthenticated access to runtime or administrative routes
- Response inspection for DSNs, passwords, usernames, email addresses, internal hostnames, and filesystem paths
- Static analysis and code review checks for configuration serialization without authorization guards
- Review of redaction implementations for denylist-only logic and incomplete sensitive-field coverage
- API gateway or policy enforcement that blocks unauthenticated access to administrative configuration paths
- Automated security scanning and secret-detection tools integrated into testing workflows
