With an astonishing 160 commits on July 18th to this one repository (see https://github.com/taylannuhogluofficial-png), and no other activity in any other repository, I would be cautious of this seemingly benign offering.
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.
With an astonishing 160 commits on July 18th to this one repository (see https://github.com/taylannuhogluofficial-png), and no other activity in any other repository, I would be cautious of this seemingly benign offering.
Also I don't see much evidence/proof of care; e.g. there are hallucinations such as a reference to MITRE T1059.007 (https://github.com/taylannuhogluofficial-png/Tblue/blob/208b...) as "Client-Side SQL Injection (Web SQL)" when actually, it deals with JavaScript and not Web SQL: https://d3fend.mitre.org/offensive-technique/attack/T1059.00...
[flagged]
What would make it very easy is to drop into GitHub Actions / CI gates to fail PRs on critical header misconfigurations
You forgot a dependency: when installing tblue, please make sure that "PyYAML" is installed
[dead]
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.
[flagged]