Summary
OpenHuman's approval gate uses a JSON-RPC bearer token as an approval session identifier, causing the credential to appear in approval records, events, debug logs, and RPC responses. Anyone who obtains these artifacts may use the token to access the core RPC interface and perform privileged operations while the token remains valid.
OpenHuman's approval gate uses a JSON-RPC bearer token as an approval session identifier, causing the credential to appear in approval records, events, debug logs, and RPC responses. Anyone who obtains these artifacts may use the token to access the core RPC interface and perform privileged operations while the token remains valid.
Affected context
The issue affects OpenHuman desktop and Rust library deployments where approval records, events, debug logs, or RPC responses include the bearer token used as an approval session identifier. Exposure can occur during normal desktop operation; the token remains useful until it is rotated or, for launch-specific tokens, until the corresponding core instance is no longer active.
The issue affects OpenHuman desktop and Rust library deployments where approval records, events, debug logs, or RPC responses include the bearer token used as an approval session identifier. Exposure can occur during normal desktop operation; the token remains useful until it is rotated or, for launch-specific tokens, until the corresponding core instance is no longer active.
Exploit preconditions
- Attack surface: Persisted approval records, events, debug logs, and RPC responses
- Required access: Ability to obtain or read an artifact containing the bearer token
- Trigger point: Token inclusion in approval-related data during normal operation
- Why exploitation is possible: The exposed value is also a credential for the core RPC interface and can be used while it remains valid
- Attack surface: Persisted approval records, events, debug logs, and RPC responses
- Required access: Ability to obtain or read an artifact containing the bearer token
- Trigger point: Token inclusion in approval-related data during normal operation
- Why exploitation is possible: The exposed value is also a credential for the core RPC interface and can be used while it remains valid
Why this happens
The approval gate reuses a bearer credential as a session identifier and allows that sensitive value to flow into records, events, logs, and responses. This is an information exposure issue (CWE-200); storing or transmitting the credential in readable artifacts also relates to CWE-312 and CWE-532. The underlying insecure pattern is propagating secrets through operational data rather than using a separate, non-sensitive identifier.
The approval gate reuses a bearer credential as a session identifier and allows that sensitive value to flow into records, events, logs, and responses. This is an information exposure issue (CWE-200); storing or transmitting the credential in readable artifacts also relates to CWE-312 and CWE-532. The underlying insecure pattern is propagating secrets through operational data rather than using a separate, non-sensitive identifier.
Potential impact
- An attacker may gain unauthorized access to the core RPC interface
- Sensitive agent or integration data could be exposed
- Privileged operations may be performed without authorization
- Access could persist until the token is rotated or its associated core instance stops
- An attacker may gain unauthorized access to the core RPC interface
- Sensitive agent or integration data could be exposed
- Privileged operations may be performed without authorization
- Access could persist until the token is rotated or its associated core instance stops
General mitigation guidance
Defensive patterns focus on keeping credentials separate from identifiers and preventing secrets from entering logs or persisted operational data.
- Use opaque, non-secret identifiers for approval sessions
- Minimize token exposure by limiting where credentials are stored, transmitted, and rendered
- Redact or suppress secrets in logs, events, records, and RPC responses
- Apply short-lived credentials, rotation, and least-privilege access where appropriate
- Restrict access to diagnostic artifacts and prefer secure-by-default logging and response behavior
Defensive patterns focus on keeping credentials separate from identifiers and preventing secrets from entering logs or persisted operational data.
- Use opaque, non-secret identifiers for approval sessions
- Minimize token exposure by limiting where credentials are stored, transmitted, and rendered
- Redact or suppress secrets in logs, events, records, and RPC responses
- Apply short-lived credentials, rotation, and least-privilege access where appropriate
- Restrict access to diagnostic artifacts and prefer secure-by-default logging and response behavior
How teams detect issues like this
- Search source code and data flows for bearer tokens reused as session identifiers or included in approval-related output
- Review logging, event, persistence, and RPC response paths for sensitive credential values
- Use static analysis or secret-scanning rules to flag token fields passed to logging or serialization APIs
- Enforce policies that redact credentials and prevent secrets from being committed to logs or stored in broadly accessible artifacts
- Search source code and data flows for bearer tokens reused as session identifiers or included in approval-related output
- Review logging, event, persistence, and RPC response paths for sensitive credential values
- Use static analysis or secret-scanning rules to flag token fields passed to logging or serialization APIs
- Enforce policies that redact credentials and prevent secrets from being committed to logs or stored in broadly accessible artifacts
