CVE-2026-16076: 
AstrBot vulnerability analysis and mitigation

CVE-2026-16076 is an authentication bypass by spoofing vulnerability in AstrBotDevs AstrBot affecting versions up to and including 4.25.5. The flaw resides in the OpenApiRoute.chat_send function within astrbot/dashboard/routes/open_api.py, where manipulation of the username argument allows an authenticated API key holder to impersonate other users, including administrators. It was disclosed publicly on July 18, 2026, with the exploit having been shared prior to vendor response — the vendor did not respond to early disclosure contact. It carries a CVSS v3.1 base score of 6.3 (Medium) and a CVSS v4.0 base score of 2.1 (Low) (GitHub Advisory, Feedly).

The root cause is improper authentication (CWE-287) and authentication bypass by spoofing (CWE-290). The API-key middleware correctly authenticates the caller and stores a trusted principal as g.username = f"api_key:{api_key.key_id}", but OpenApiRoute.chat_send() subsequently accepts a user-controlled username field from the JSON request body and overwrites the trusted principal with g.username = effective_username. This spoofed identity propagates through WebChatAdapter.convert_message() into MessageMember(username, username), and the admin authorization check in WakingCheckStage.process() then compares event.get_sender_id() against admins_id — trusting the attacker-controlled value. A public proof-of-concept demonstrating end-to-end exploitation was published by researcher YLChen-007, including scripts to reproduce the full attack chain (PoC Gist, GitHub Advisory).

An attacker holding a valid chat-scope API key can impersonate any user, including the administrator, by supplying a spoofed username in the request body. This allows execution of admin-only built-in commands (e.g., /name) over HTTP, resulting in unauthorized data modification and persistence of forged records in the application database. The impact spans confidentiality (low), integrity (low to high for admin-gated operations), and availability (low), with the primary risk being privilege escalation within the AstrBot instance and unauthorized manipulation of bot configuration and state (PoC Gist).

A public proof-of-concept exploit was disclosed by researcher YLChen-007 on GitHub Gist, demonstrating successful exploitation on AstrBot v4.25.5 with a chat-scope API key and a crafted POST request to /api/v1/chat (PoC Gist). The EPSS score is approximately 0.291% (21st percentile), indicating a relatively low but non-negligible probability of exploitation in the wild within 30 days (GitHub Advisory). The CVE status is listed as "Deferred" and no CISA KEV catalog entry or confirmed in-the-wild exploitation has been reported. No threat actor attribution is available at this time.

1. Obtain a valid API key: Log in to the AstrBot dashboard via POST /api/auth/login using valid credentials, then create a chat-scope API key via POST /api/apikey/create.
2. Identify the administrator username: Determine the administrator's sender ID configured in admins_id (commonly astrbot in default deployments).
3. Craft the spoofed request: Construct a POST request to /api/v1/chat with the X-API-Key header set to the obtained API key, and a JSON body containing "username": "astrbot" (or the known admin ID), a session_id, and an admin-only command as the message field.
4. Send the exploit request: Execute the request, e.g.:

curl -N -X POST http://<target>:6186/api/v1/chat \
  -H 'X-API-Key: <your-chat-scope-api-key>' \
  -H 'Content-Type: application/json' \
  -d '{"username":"astrbot","session_id":"spoofed-session","message":"/name pwned_alias","enable_streaming":true}'

5. Confirm privilege escalation: Observe the streaming response confirming the admin-only command executed (e.g., UMO name set to: pwned_alias), and verify the forged record persisted in the database with creator_sender_id="astrbot" (PoC Gist).

• Network: Unexpected POST requests to /api/v1/chat from IP addresses not associated with legitimate API consumers; requests containing username values matching known admin IDs (e.g., astrbot) from non-admin API key holders.
• Logs: AstrBot runtime logs showing entries like [webchat(webchat)] astrbot/astrbot: /name <alias> or admin-only command execution attributed to astrbot sender ID when initiated via the OpenAPI endpoint; log entries showing Prepare to send - astrbot/astrbot: for commands not initiated by the actual administrator.
• File System / Database: Unexpected rows in data/data_v4.db with creator_sender_id="astrbot" and umo values containing webchat:FriendMessage:webchat!astrbot!<session_id> where the session ID is not a recognized legitimate session.
• Application State: Unexpected alias records, configuration changes, or plugin state modifications that appear to originate from the administrator account but were not initiated by the actual administrator (PoC Gist).

Upgrade AstrBotDevs AstrBot to a version later than 4.25.5, as a patch is referenced via GitHub Advisory GHSA-jgf3-cr8w-g5h9 (GitHub Advisory). As a workaround prior to patching, implement strict server-side validation to ensure the username field in OpenApiRoute.chat_send() cannot override the authenticated principal stored in g.username by the API-key middleware. Additionally, apply network-level access controls to restrict the /api/v1/chat endpoint to trusted IP ranges, and audit all existing API keys to revoke any that are not strictly necessary.