intrigued. but not sure ill run it.
-----
Verdict
I would not run Tblue against a production website, especially not with cookies, bearer tokens, API keys, or Basic Auth.
I found no obvious host-malware behavior such as os.system, subprocess execution, persistence, or credential-file harvesting. However, the scanner’s actual behavior materially contradicts its safety claims.
Key findings:
- “Passive” mode is not passive. The default module list includes five explicitly active scanners, and the default resolver schedules every listed module before checking --active. Consequently, default execution performs port scanning, DNS enumeration, CORS fuzzing, HTTP verb probing, and TLS probing. Supplying --active appears to run those scanners a second time. Default module list, default resolution, worker scheduling.
- Authenticated scans could leak credentials to third parties. Tblue attaches supplied cookies, custom headers, bearer tokens, or Basic Auth globally to a Requests session. Default scanners then use that session to contact crt.sh, HackerTarget, AlienVault OTX, NVD, OSV, and other services. Authentication handling, third-party calls. I confirmed that a prepared third-party request inherited the Authorization header, custom API header, and cookie.
- Ordinary scanners send potentially consequential payloads. Examples include two POSTs to login/password-reset endpoints, several XXE payloads referencing /etc/passwd, GraphQL probes, XSS form submissions, and Redis PING, INFO, and Memcached stats commands. Account enumeration, XXE payload submission, Redis commands.
- “No data sent anywhere” is false. At minimum, target domains/IPs and detected software versions are transmitted to external intelligence services. If the Anthropic SDK and ANTHROPIC_API_KEY happen to be present, findings are automatically sent for AI analysis unless --no-ai is specified. AI behavior.
- The project has very little provenance. Its visible history consists of four unsigned commits from one day, despite describing itself as “Production/Stable” with thousands of passing tests. There are no releases, tags, forks, or CI workflows. Commit history.
- Avoid the PyPI package. Published tblue 1.0.1 predates the repository’s acknowledged PoC shell-injection fix; its vulnerable PoC file matched the initial commit rather than current main. Generated commands are not automatically executed, but copying one from a maliciously influenced report could execute shell metacharacters. Security-fix commit, PyPI package.
Bottom line: it does not look like deliberate malware, but it is immature, misleadingly documented, and unsafe for its advertised default use. If you investigate further, use only a disposable VM with no credentials, no host mounts, outbound networking restricted to an authorized staging target, and a small explicit --only allowlist.
Verdict I would not run Tblue against a production website, especially not with cookies, bearer tokens, API keys, or Basic Auth. I found no obvious host-malware behavior such as os.system, subprocess execution, persistence, or credential-file harvesting. However, the scanner’s actual behavior materially contradicts its safety claims. Key findings: - “Passive” mode is not passive. The default module list includes five explicitly active scanners, and the default resolver schedules every listed module before checking --active. Consequently, default execution performs port scanning, DNS enumeration, CORS fuzzing, HTTP verb probing, and TLS probing. Supplying --active appears to run those scanners a second time. Default module list, default resolution, worker scheduling. - Authenticated scans could leak credentials to third parties. Tblue attaches supplied cookies, custom headers, bearer tokens, or Basic Auth globally to a Requests session. Default scanners then use that session to contact crt.sh, HackerTarget, AlienVault OTX, NVD, OSV, and other services. Authentication handling, third-party calls. I confirmed that a prepared third-party request inherited the Authorization header, custom API header, and cookie. - Ordinary scanners send potentially consequential payloads. Examples include two POSTs to login/password-reset endpoints, several XXE payloads referencing /etc/passwd, GraphQL probes, XSS form submissions, and Redis PING, INFO, and Memcached stats commands. Account enumeration, XXE payload submission, Redis commands. - “No data sent anywhere” is false. At minimum, target domains/IPs and detected software versions are transmitted to external intelligence services. If the Anthropic SDK and ANTHROPIC_API_KEY happen to be present, findings are automatically sent for AI analysis unless --no-ai is specified. AI behavior. - The project has very little provenance. Its visible history consists of four unsigned commits from one day, despite describing itself as “Production/Stable” with thousands of passing tests. There are no releases, tags, forks, or CI workflows. Commit history. - Avoid the PyPI package. Published tblue 1.0.1 predates the repository’s acknowledged PoC shell-injection fix; its vulnerable PoC file matched the initial commit rather than current main. Generated commands are not automatically executed, but copying one from a maliciously influenced report could execute shell metacharacters. Security-fix commit, PyPI package. Bottom line: it does not look like deliberate malware, but it is immature, misleadingly documented, and unsafe for its advertised default use. If you investigate further, use only a disposable VM with no credentials, no host mounts, outbound networking restricted to an authorized staging target, and a small explicit --only allowlist.