一键导入
jwt-attacks
Detect JWT implementation vulnerabilities including algorithm confusion, none algorithm acceptance, weak secrets, and JWK injection attacks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Detect JWT implementation vulnerabilities including algorithm confusion, none algorithm acceptance, weak secrets, and JWK injection attacks.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Generate polished, human-sounding vulnerability disclosure reports for GHSA, HackerOne, and email. Auto-selects channel, calculates CVSS, and adapts tone.
Mine GitHub Security Advisories and CVE databases for incomplete fixes, finding variant vulnerabilities in patched code or similar patterns in related packages.
Detect authentication and authorization bypass vulnerabilities including missing auth middleware, JWT algorithm confusion, IDOR, and session fixation.
Detect code injection vulnerabilities in packages that dynamically generate or evaluate code via new Function(), eval(), vm.run*, or template literal interpolation.
Detect OS command injection via shell execution sinks where user-controlled input reaches system commands without proper sanitization.
Cross-pollination multiplier technique: find a vulnerability in one package, then search for the same pattern across all similar packages to multiply findings.
| name | jwt-attacks |
| description | Detect JWT implementation vulnerabilities including algorithm confusion, none algorithm acceptance, weak secrets, and JWK injection attacks. |
| metadata | {"filePattern":["**/*.js","**/*.ts","**/*.py","**/*.go"],"bashPattern":["grep.*(jwt|jsonwebtoken|jose|JWK|JWS)"],"priority":82} |
Audit JWT verification/generation libraries, authentication implementations, and any code that validates or creates JSON Web Tokens.
The server uses RS256 (asymmetric) but the attacker changes the token header to HS256 (symmetric) and signs with the public key as the HMAC secret.
Conditions: Library accepts algorithm from token header without allowlist validation.
Token header specifies "alg": "none", and the library accepts unsigned tokens.
Conditions: Library does not validate algorithm or allows "none".
Attacker embeds their own public key in the token header via the jwk parameter, and the library uses it for verification.
HMAC secrets that are short, common words, or default values. Can be brute-forced offline.
"kid": "../../dev/null" -- sign with empty key"kid": "' UNION SELECT 'secret' --" -- inject known key"kid": "|id" -- if kid is passed to shelljku (JWK Set URL) or x5u (X.509 URL) in header points to attacker-controlled server hosting a JWK Set with the attacker key.
grep -rn "jwt\.verify\|jwt\.decode\|jwt\.sign\|jwt\.encode" .
grep -rn "jsonwebtoken\|jose\|PyJWT\|go-jose\|nimbus-jose" .
grep -rn "JWTVerify\|jwtVerify\|createRemoteJWKSet" .
grep -rn "algorithms\|algorithm.*=\|alg.*:" . | grep -i jwt
Is the algorithm explicitly specified or taken from the token header?
// VULNERABLE: no algorithm specified
jwt.verify(token, key);
// SAFE: algorithm allowlist
jwt.verify(token, key, { algorithms: ['RS256'] });
grep -rn "none\|None\|NONE" . | grep -i "alg\|algorithm"
grep -rn "kid\|keyId\|key_id\|getKey\|keyStore" .
Is the kid value used in file paths, database queries, or command execution?
grep -rn "secret\|SECRET\|JWT_SECRET\|TOKEN_SECRET" .
Is the secret hardcoded, from environment variable, or sufficiently random?