Strix is an open-source penetration-testing tool that uses autonomous AI agents to inspect applications, exploit vulnerabilities, and validate findings with working proofs of concept. Developers and security teams use it for application security testing, bug-bounty research, remediation guidance, reporting, and automated checks in development pipelines.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/usestrix/strix/fix-security-vulnerabilities-with-strixnpx skills add usestrix/strix --skill fix-security-vulnerabilities-with-strixgit clone --depth 1 https://github.com/usestrix/strixWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/usestrix/strix/fix-security-vulnerabilities-with-strix)<a href="https://agentmods.dev/skills/usestrix/strix/fix-security-vulnerabilities-with-strix"><img src="https://agentmods.dev/badge/skills/usestrix/strix/fix-security-vulnerabilities-with-strix.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00124 | $0.01468 |
| Opus 5 | $0.00062 | $0.00734 |
| Sonnet 5 | $0.00025 | $0.00294 |
| Haiku 4.5 | $0.00012 | $0.00147 |
Grade A, and why
fix-security-vulnerabilities-with-strix scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
new_id=$(curl -sS "$BASE/scans/$scan_id/rerun" "${auth[@]}" -X POST | jq -r .scan_id) Copies of this mod
1 near-identical copy found in the catalogue:
- fix-security-vulnerabilities-with-strix — 92% identical, 6 lines differ
How it starts
The opening of the file, as written. The whole thing — 78 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Fix Strix findings and verify
Turn validated Strix findings into minimal, correct fixes — and prove they work by re-scanning.
1. Triage
Get the findings from wherever the scan ran:
- OSS CLI — artifacts in
strix_runs/<run-name>/:vulnerabilities/*.md— one finding per file: description, severity, PoC steps or script, affected code locations, remediation guidance.vulnerabilities.json— the same findings as JSON (ids, severity, CWE/CVE,code_locationswithfix_before/fix_aftersuggestions when available).
- Cloud (app.strix.ai) — pull findings with the CLI:
strix cloud vulns list --scan-id <scan-id> --json(orstrix cloud scans get <scan-id> --json | jq '.vulnerabilities', orstrix cloud vulns list --severity criticalorg-wide). Each finding carriesseverity, cwe, endpoint, method, impact, technical_analysis, poc_description, poc_script_codeand, for code findings,code_file/code_diff/code_before/code_after. After a fix is verified, mark it withstrix cloud vulns update <id> --status fixed. See the managed-pentesting-with-strix skill forstrix cloud loginand scopes.
Order work by severity: critical → high → medium → low. Every Strix finding was validated with a working proof-of-concept, so do not dismiss findings as false positives without re-testing the PoC yourself.
2. Fix
For each finding:
- Reproduce it with the PoC from the finding file when feasible.
- Fix the root cause, not the specific payload (parameterize every query instead of blocking one string, and enforce authorization in the handler instead of hiding the endpoint).
- Prefer the framework's built-in defense (ORM parameterization, template auto-escaping, CSRF middleware, centralized authz) over ad-hoc sanitization.
- Keep the diff minimal and apply the repo's existing patterns. Finding files often include
fix_before/fix_aftersnippets — use them as a starting point, not verbatim.
Common finding classes and expected fixes: injection → parameterization/escaping at the sink; IDOR/broken access control → object-level authorization checks; SSRF → allowlist + block internal ranges; XSS → context-aware output encoding + CSP; secrets exposure → rotate the secret AND remove it from code/history; auth issues → fix the server-side check (never client-side).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago Changed bb1b351fd60c
- 5d ago First seen · 78 lines · 124 tokens per session scan A 6be75ecea9dd
fix-security-vulnerabilities-with-strix is a skill published in the GitHub repository usestrix/strix (59,967 stars, last pushed 2d ago), licensed Apache-2.0. It adds 124 tokens to every session and 1,468 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
analyzing-bootkit-and-rootkit-samples
Analyzes bootkit and advanced rootkit malware infecting the Master Boot Record (MBR), Volume Boot Record (VBR), or UEFI firmware for below-OS persistence, covering boot sector analysis, UEFI module inspection, and anti-rootkit detection. Use when compromise survives OS reinstallation or antivirus/EDR fails to detect…
analyzing-macro-malware-in-office-documents
Analyzes malicious VBA macros embedded in Microsoft Office documents (Word, Excel, PowerPoint) to identify download cradles, payload execution, persistence mechanisms, and anti-analysis techniques. Uses olevba, oledump, and VBA deobfuscation to extract the attack chain. Activates for requests involving Office macro…
analyzing-malware-behavior-with-cuckoo-sandbox
Detonate malware samples in Cuckoo Sandbox to observe runtime behavior — process creation, file system and registry changes, network communications, and API calls — and generate behavioral reports for classification and IOC extraction. Use when a sample has passed static triage and needs dynamic/behavioral analysis…
analyzing-network-traffic-of-malware
Analyzes network traffic generated by malware during sandbox execution or live incident response to identify C2 protocols, data exfiltration channels, payload downloads, and lateral movement patterns using Wireshark, Zeek, and Suricata. Activates for requests involving malware network analysis, C2 traffic decoding…
analyzing-packed-malware-with-upx-unpacker
Identifies and unpacks UPX-packed malware samples, including binaries with modified UPX magic bytes or headers that block automated decompression, to recover the original executable for static analysis. Use when a sample shows high entropy, minimal imports, or only LoadLibrary/GetProcAddress in its import table, or…
analyzing-campaign-attribution-evidence
Systematically evaluate cyber-campaign evidence to attribute an operation to a threat actor, using the Diamond Model and Analysis of Competing Hypotheses (ACH) to weigh infrastructure overlaps, TTP consistency, malware code similarity, and timing/language artifacts into confidence-weighted attribution assessments. Use…