CVE-2026-109516: Bot for Telegram on WooCommerce <= 1.3.0 - Unauthenticated Authentication Bypass to Account Takeover via Fake Telegram Webhook + Brute-Forced Login Token
The Bot for Telegram on WooCommerce plugin for WordPress is vulnerable to Authentication Bypass leading to Account Takeover in all versions up to, and including, 1.3.0. The /wp-json/woo-telegram/v1/main/ REST endpoint is registered with permissioncallback => 'returntrue' and performs no Telegram webhook signature verification, allowing an unauthenticated attacker to POST a forged bot update with a message.chat.id set to any WordPress login name; bftowgetusersystemid() resolves this attacker-supplied value to the targeted account via getuserby('login', $tgId) with no ownership proof, and writes a login token computed as md5($SERVER['HTTPUSERAGENT'] . time()) — both inputs are fully attacker-controlled or bounded within seconds using the response's own Date header. The resulting token is redeemable at the unauthenticated, capability-check-free, and nonce-less ?action=bftowcreateorder&bftowtoken= endpoint, which calls wpsetauthcookie() unconditionally via loginuserbyid, issuing a persistent authenticated session cookie for the targeted account to the attacker. This makes it possible for unauthenticated attackers to log in as any WordPress user, including administrators, given only that user's username.
Affected Software
Event History
Frequently Asked Questions
Does an attacker need a Telegram account, prior WordPress access, or user interaction?
No. The vulnerable REST endpoint accepts unauthenticated forged bot updates and does not verify a Telegram webhook signature. No WordPress privileges or user interaction are required.
Which accounts can be targeted?
An attacker can target any WordPress account whose login name they supply as the forged Telegram chat ID. The plugin resolves that attacker-controlled value directly to a WordPress user without verifying account ownership.
What access does successful exploitation provide?
Successful exploitation results in a persistent authenticated WordPress session cookie for the targeted account. This permits account takeover through the plugin's unauthenticated token-redemption endpoint.
What makes the login token feasible to obtain?
The token is derived from the HTTP User-Agent and the current time. The attacker controls the User-Agent, and the response Date header bounds the time component to a small range that can be brute-forced.