captcha-relay
Audited by Socket on Feb 26, 2026
2 alerts found:
Securityx2The code fragment describes a CAPTCHA-relay capability with two modes: a human-in-the-loop screenshot mode and a relay-based token mode. The overall purpose is coherent with the demonstrated capabilities (CAPTCHA solving automation via CDP integration and optional tunneling). However, the design introduces significant security and privacy considerations: it transmits CAPTCHA content to external humans (via Telegram) in screenshot mode, and relay mode relies on tunnel/public endpoints that could expose internal services. The workflow enables injection of user-provided clicks or tokens into an active browser session, which is powerful but also can be misused for automation in ways that bypass anti-bot protections. There is no explicit malicious payload, but data exfiltration, privacy leakage, and potential misuse of browser control are notable risks. Given these factors across all four dimensions, the assessment should be between Suspicious and Benign; due to multiple data-exposure and networking patterns tied to the stated purpose, the prudent stance is Suspicious.
This module's purpose is to bypass CAPTCHA protections by relaying real provider widgets to remote human solvers and injecting solved tokens back into automated browser sessions. The design is explicitly intended to subvert anti-abuse mechanisms and therefore is high-risk for misuse. It writes tokens to disk and exposes a local server over public tunnels; it invokes provider internals to force token acceptance. If included as a dependency, it would enable automated systems to defeat CAPTCHA defenses and facilitate abuse and fraud. Use in benign contexts is limited; recommend not including this in production services or public packages without strict controls and explicit, legitimate use approval.