OpenHuman EUVD-2026-103201

Exploitation requires that the victim is actively running the local OpenHuman core with its HTTP server listening on loopback port 7788, and that the victim's browser loads attacker-controlled content that issues a cross-origin GET to /auth/telegram (UI:R - user interaction via visiting a malicious page). The attacker must additionally possess their own OpenHuman account and a valid one-time Telegram login token to seed the forged callback. Limiting factors: the vulnerable endpoint is loopback-only so the forgery must traverse the victim's own browser (not a direct remote connection), the attack fails if the local core is not running, and it depends on the pre-0.56.0 version where fetch-metadata/origin validation is absent. No elevated privilege on the victim host is needed because the callback is unauthenticated.

This is a network-reachable CSRF flaw (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N, base 8.1 High) in the unauthenticated loopback GET /auth/telegram callback of OpenHuman. The CVSS signals are internally consistent with the description: AV:N reflects that a remote attacker-controlled web page reaches the loopback endpoint via the victim's browser, PR:N reflects that the callback itself requires no authentication, and UI:R reflects the mandatory step of the victim visiting a malicious page - the classic CSRF pattern. C:H/I:H/A:N is reasonable because a successful attack silently swaps the victim's active local session to the attacker's backend account, exposing subsequent agent actions, memory writes, and Telegram messages (confidentiality + integrity) without degrading availability. No EPSS score, CISA KEV entry, POC flag, or SSVC decision data was provided, so probabilistic and exploitation-status signals cannot corroborate the CVSS severity. Net: this is a genuine design weakness, but real-world priority is tempered by prerequisites not captured in the base score - the victim must have the local core running and listening on loopback 7788, must be lured to attacker content, and the attacker must already hold their own OpenHuman account plus a one-time Telegram login token. Combined with the product's narrow deployment footprint, this is a legitimate but situational risk rather than a mass-exploitation priority.

An attacker with their own OpenHuman account obtains a one-time Telegram login token and hosts a malicious web page. When a victim who is running the local OpenHuman core visits that page, the page silently issues a cross-origin GET to the loopback /auth/telegram endpoint on port 7788, causing the core to store the attacker's JWT as the active session. No public exploit code was identified at time of analysis, though the attack is a straightforward browser-driven CSRF requiring no special tooling.