bbs-go EUVD-2026-103061

Exploitation requires that the target has a bbs-go account linked via Google login and that the /api/login/google_one_tap Google One Tap endpoint is enabled/configured on the instance. The attacker must run their own Google OAuth client and must get the victim to produce and expose a valid Google-signed ID token (e.g., by signing in at an attacker-controlled property) - this user-interaction requirement is the primary limiting factor. The core weakness is that the token's 'aud' (audience) claim is never checked, so a token issued to ANY OAuth client is accepted; there is no authentication or privilege requirement on bbs-go itself, and no special victim privileges are needed beyond an existing Google-linked account.

This is a genuine high-priority authentication flaw, not a CVSS-inflated paper risk. The vendor-supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H) scores 8.6 and is internally consistent with the description: remote, network-reachable, low complexity, no attacker privileges on bbs-go, with full account takeover (high confidentiality and integrity). The one signal that tempers raw severity is user interaction - exploitation hinges on obtaining a victim's Google-signed ID token, which requires the victim to authenticate to an attacker-operated OAuth client, so this is not a point-and-click unauthenticated takeover. No EPSS score and no CISA KEV entry were provided, and there is no indication of active exploitation, so by the precision rules this is 'no public exploit identified' as weaponized tooling - however, a detailed public technical writeup (hackmd) and a VulnCheck advisory with exact vulnerable source-line references exist, substantially lowering the bar to reproduce. Net: a real, exploitable account-takeover bug in a self-hosted forum product, mitigated in practice by the need to lure the victim through an attacker-controlled Google sign-in and by the product's modest deployment footprint. Note: EPSS/KEV data were absent from the input and could not be cross-referenced - treat the exploitation-probability picture as unquantified rather than confirmed-low.

An attacker registers their own Google OAuth client and lures a target bbs-go user into signing in with Google through an attacker-controlled page, capturing the victim's Google-signed ID token. Because bbs-go's google_one_tap handler never validates the token's 'aud' (audience) claim, the attacker replays that token to /api/login/google_one_tap and is issued an authenticated session as the victim's Google-linked account. Vulnerable code paths are publicly identified in a technical writeup and the VulnCheck advisory, so reproduction is straightforward even without a packaged exploit.