Nir Zadok

A weak authentication issue exists in the JWT authentication flow. An attacker with a valid JSON Web Token (JWT) from the configured identity provider can authenticate as any existing user by exploiting an email-based fallback lookup. This occurs because the system fails to verify the `email verified` claim. By presenting a token with an unverified email address that matches a victim's account, an attacker can inherit the victim's role, including `proxy admin` privileges. This can lead to the permanent overwriting of the victim's stored identity binding, granting persistent unauthorized access to administrative endpoints that expose API keys and user management.

An authentication bypass exists in the local HTTP agent-control API. The system grants unauthenticated access by accepting a client-supplied loopback `Host` header instead of validating the actual TCP connection origin. In default configurations, a confined process executed by a tool can reach the loopback API without port exposure to escape its OS sandbox, escalate to unconfined execution, and disable approval prompts. If the port is externally reachable via reverse proxy, SSH forward, or tunnel, a remote attacker can create sessions, execute arbitrary commands, and exfiltrate stored conversation transcripts without credentials.