The risk is significantly amplified by the provided 'docker-compose.yml' file, which defaults to binding the service to '0.0.0.0' and fails to enforce the 'HEADROOM_PROXY_TOKEN' environment variable. When deployed using this configuration, the service exposes its data-plane endpoints to the network, enabling unauthenticated attackers to perform identity spoofing remotely. Defenders must ensure that the proxy is bound to local interfaces only or that the 'HEADROOM_PROXY_TOKEN' is strictly enforced for all inbound requests.

Impact

Successful exploitation allows unauthenticated attackers to read or write the LLM memory of any user registered within the Headroom instance. This could lead to the exposure of proprietary data, sensitive user conversations, or the injection of malicious context into future LLM interactions, compromising the integrity of all stored assistant memory.

Recommendation

• Immediately update the 'docker-compose.yml' configuration to bind the proxy to '127.0.0.1' and verify that 'HEADROOM_PROXY_TOKEN' is enabled and non-default.
• Implement network-level access controls to restrict access to the LLM proxy port to authorized internal IP addresses only.
• Patch the Headroom LLM proxy to the version where the 'resolve_memory_identity' seam is introduced in 'headroom/proxy/identity.py'.
• Audit logs for suspicious 'x-headroom-user-id' header patterns that deviate from expected user identification formats.