The vulnerability in OpenClaw allowed a non-owner to gain owner privileges on the MCP loopback path. This was possible because the owner status was determined by the x-openclaw-sender-is-owner HTTP header, which could be easily spoofed by a malicious client. The core of the vulnerability lies in the resolveMcpRequestContext function, which trusted this header to determine the senderIsOwner flag.
The patch addresses this by fundamentally changing the authentication mechanism for the loopback interface. Instead of a single bearer token and a spoofable header, the system now generates two distinct tokens: an ownerToken and a nonOwnerToken. The validateMcpLoopbackRequest function was updated to check for either of these tokens and determine the senderIsOwner status based on which token was provided. Consequently, resolveMcpRequestContext was changed to rely on this secure, token-based authentication result instead of the insecure header. Any runtime profiler capturing an exploit would likely show validateMcpLoopbackRequest and resolveMcpRequestContext in the stack trace as they are directly responsible for processing the malicious request.