In Rocket.Chat <8.3.0, <8.2.1, <8.1.2, <8.0.3, <7.13.5, <7.12.6, <7.11.6, and <7.10.9, a NoSQL injection vulnerability can lead to account takeover of the first user with a generated token when an OAuth app is configured.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a small standalone Python proof-of-concept exploit for CVE-2026-29198 affecting Rocket.Chat. The repo contains three files: a brief README, a requirements.txt listing requests, and the main exploit script poc_cve_2026_29198.py. The script is the clear entry point and uses argparse plus the requests library to interact with a target Rocket.Chat server. The exploit targets Rocket.Chat API handling of the access_token query parameter and abuses NoSQL-style operators in GET parameters to trigger an authentication bypass. It first checks reachability using /api/v1/info, /api/v1/me, or /. It then performs a patch sanity check by sending a normal invalid string token to /api/v1/me and expecting rejection. The core exploit logic iterates through several injected parameter variants such as $ne, $exists, $gt, and $regex against access_token until /api/v1/me returns HTTP 200 with a successful JSON body containing a user _id. When successful, it prints leaked victim account details including username, roles, email data, and status. If the --escalate flag is supplied, the script attempts additional authenticated API actions using the same injected parameters rather than a recovered token. Specifically, it queries /api/v1/users.list to enumerate users and identify admin accounts, then /api/v1/channels.list to test broader access and list channels. This makes the exploit more than a detector: it demonstrates practical unauthorized access and limited post-bypass enumeration. There is no shell payload, code execution, persistence, or malware behavior. The capability is unauthorized API access as any user with an active OAuth token present in the backend, with impact depending on the privileges of the matched account. The exploit is operational but still PoC-style: payloads are hardcoded, targeting is manual via --url, and results are printed to console.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
No public activity tracked yet. Mallory keeps watching.
No public activity observed for this vulnerability.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.