身份验证的七条缝：2026年，攻击者不再“绕过”认证，他们从链环之间走进来

原创

www.klsec.com
www.klsec.com

昆仑AI安全实验室

2026年11月2日 14:08
广东

去阅读

2026年10月14日，vlife的一个CVE被公开：TokenUtil里硬编码了一个HS256对称密钥。任何知道这个密钥的人，可以自己签发一个superUser=true的JWT，访问任意URL，成为超级管理员。十一天后，OpenDeepWiki的CVE几乎一模一样：appsettings.json里硬编码Jwt:SecretKey，攻击者离线伪造管理员token。

这些不是孤立事件。2026年，身份验证漏洞的CVE列表长得惊人，但如果你把它们拆开看，会发现一个共同的模式：攻击者很少“攻破”某一个验证环节。他们找的是环节之间的缝——一个环节做了检查，下一个环节以为检查已经做过了；一个组件解析出的身份，另一个组件用不同的方式理解同一个字段。

身份验证从来不是一道门。它是一条由多个决策点组成的链：令牌生成、令牌验证、身份链接、MFA状态、会话管理、密码恢复。每一环都在假设“上一环已经处理好了”。2026年的真实攻击，几乎全部发生在这个假设失效的地方。

一、令牌层的缝：硬编码密钥与算法混淆——签名“有效”，但签发者不是你

JWT的安全模型建立在一个前提上：只有持有正确密钥的一方，才能生成一个签名有效的令牌。当这个前提不成立时，整个令牌层就失去了意义。

硬编码密钥是最直接的那一类。vlife的TokenUtil、BotSharp的appsettings.json、OpenDeepWiki的Jwt:SecretKey、Kener的DUMMY_SECRET fallback key——2026年这一批CVE的共同点是：密钥被提交到了代码仓库里，攻击者不需要“窃取”，只需要“阅读”。BotSharp的CVE描述写得很直白：攻击者可以用提交的HMAC密钥和固定的issuer/audience签发令牌，冒充任何已知用户，包括管理员，访问所有[Authorize]保护的API路由。

但硬编码只是令牌层最粗糙的那条缝。更隐蔽的是算法混淆——验证方和签发方对“这是什么类型的密钥”理解不一致。

libjwt的CVE-2026-44699是这个模式在2026年的精确标本。libjwt接受一个不包含alg参数的RSA JWK作为HS256令牌的验证密钥。在OpenSSL后端里，这导致HMAC验证使用一个零长度密钥运行。攻击者不需要知道任何秘密，也不需要RSA私钥，就能伪造一个“验证通过”的JWT。PyJWT 2.13.0里的同类问题（CVE-2026-48526）被DevGuard的描述概括为：“验证方误将公钥用作对称算法的共享密钥”。fast-jwt的CVE-2026-107724走的是另一条路：它把原始序列化的公钥JWK JSON分类为HMAC secret，因为src/crypto.js把非PEM字符串当作对称密钥材料处理。

这些漏洞的共同逻辑是：令牌的“签名有效”和“由可信方签发”是两个不同的命题。 算法混淆让攻击者可以在不持有任何合法密钥的情况下，让第一个命题成立。而验证逻辑没有（或者无法）检查第二个命题。

对你意味着什么：测试JWT时，不要只测alg: none。测密钥类型和算法声明的交叉组合——把RS256的公钥当HS256的secret用，把不带alg的JWK丢进HS256验证，把公钥JSON当对称密钥传进去。签名有效不等于令牌合法，这是令牌层最根本的那条缝。

二、身份链接的缝：OIDC说“这个邮箱属于他”，你的应用说“那就让他进来”

OAuth/OIDC的账户链接，是2026年身份验证漏洞最密集的区域。它的逻辑看似简单：身份提供方（IdP）返回一个身份断言，应用把它链接到一个本地账户。问题在于，“链接的依据”和“链接的安全性”是两个不同的东西，而大多数实现只检查了第一个。

Wallos的CVE-2026-61641是这个模式的教科书。OIDC登录仅凭email claim匹配就将传入的OIDC身份链接到现有本地账户，不验证IdP是否将该邮箱标记为已验证（email_verified） 。当IdP允许用户呈现任意或未验证的邮箱时（多租户IdP、开放自注册的IdP、或者攻击者部分控制的任何IdP），一个没有Wallos账户的攻击者可以用管理员的邮箱认证，直接以管理员身份登录——完整账户接管，不需要密码。

Budibase的CVE-2026-73302是同一个缝的另一个切面。OIDC流程解析email时没有getEmailVerified或email_verified要求，然后users.getGlobalUserByEmail被用作fallback账户链接键。攻击者通过一个将受害者邮箱断言为未验证的IdP认证，一个新provider身份被合并进受害者的Budibase账户，继承受害者的角色。

Coder的CVE-2026-55076增加了一层类型转换的复杂性：email_verified的类型强制转换绕过。修复方案明确写道：“确保IdP返回的email_verified是原生JSON布尔值” ，而“email-fallback链接问题没有配置层面的workaround”。这句话的潜台词是：只要你的代码里有“用email做fallback链接”这个逻辑，而你又信任了不是严格布尔true的email_verified，这条缝就存在。

Keycloak的CVE-2026-14781和ash\_authentication的CVE-2026-49757、Pingvin Share的GHSA-7P7C，全部指向同一个结构性缺陷：email是身份提供方世界里的一个“声明”，不是应用世界里的一个“已验证的主键”。 当应用把email当作账户链接的唯一依据时，它实际上是在信任“任何能让IdP发出一个包含这个email的断言的人”。

对你意味着什么：测试OIDC/OAuth时，不要只看“有没有校验email_verified”。看当email_verified缺失、为false、为字符串\"true\"、为数字1时，链接逻辑分别怎么走。看是否存在email-based的fallback链接，以及这个fallback是否可以被一个受攻击者控制的IdP触发。“邮箱相同”和“是同一个人”之间，隔着IdP的验证策略和你的验证逻辑两道门，任何一道没关严，缝就在那里。

三、MFA层的缝：step-up检查“有没有验证记录”，而不是“验证了什么”

MFA的设计意图是：在密码之外，再增加一个“只有本人能提供”的因素。2026年的漏洞揭示了一个更微妙的问题：MFA的“完成状态”和“验证上下文”是可以被拆开的。

Logto的CVE-2026-55377把这一点展示得很精确。Account Center的step-up检查接受任何属于当前用户、且isVerified === true的活跃验证记录。一个用于绑定新passkey的WebAuthn注册验证记录，可以仅凭一个现有的Account API bearer token创建并验证，然后通过logto-verification-id头提交，被Account Center路由当作identityVerified=true处理，允许进行MFA因素管理——不需要证明持有现有密码、标识符或MFA因素。漏洞的本质是：step-up检查的是“有没有一个isVerified=true的记录”，而不是“这个记录对应的验证动作是不是当前操作所要求的那个动作” 。绑定passkey的验证和“证明你是账户主人”的验证，在语义上完全不同，但系统把它们当成了同一种东西。

tinyauth的CVE-2026-32246（GHSA-3Q28-QJRV-QR39）走的是状态机层面的缝。用户用密码登录后，会话被标记为TotpPending: true，中间件正确设置了TotpPending: true且不设置IsLoggedIn 。但OIDC authorize handler只检查“用户上下文是否存在”，不检查IsLoggedIn或TotpPending。由于中间件为TOTP-pending会话填充了上下文（用户名已填入），GetContext成功，handler用不完整会话中的用户名签发授权码。攻击者用这个授权码换取有效的access token和ID token，TOTP从未被提交。同一个代码库里，proxy controller正确地通过检查IsBasicAuth && TotpEnabled阻断了TOTP不完整会话，但OIDC handler没有等价的门禁。

vikunja的CVE-2026-34727是同一逻辑在另一个产品里的体现：OIDC回调处理器签发完整JWT令牌，不检查匹配的用户是否启用了TOTP双因素认证。phpMyFAQ的CVE-2026-111882则是通过Keycloak和Entra ID SSO回调跳过TOTP。Sync-in Server的GHSA-92CR-JXW4-5WJG更直接：POST /api/auth/token返回不受限制的Bearer access和refresh JWT，不检查2FA是否启用，一个请求即可绕过2FA。

对你意味着什么：测试MFA时，不要只测“能不能不提供OTP就登录”。测每一个签发令牌或授权码的端点，在TOTP-pending状态下分别返回什么。测step-up的验证记录是否被复用于不同语义的操作。测OIDC/OAuth流程是否绕过了本地MFA状态。MFA的强度不取决于OTP算法，取决于“在MFA完成之前，系统还允许什么” ——而2026年的漏洞说明，系统在MFA完成之前允许的东西，比设计者以为的多得多。

四、令牌生成与生命周期的缝：可预测的令牌与永不过期的重置

会话令牌和密码重置令牌，是身份验证链上另外两个被低估的环节。

Lantronix的CVE-2026-80154把会话令牌的“可预测性”推到了极致：会话令牌从设备型号和当前时间（一秒分辨率）确定性生成，结果是一个小的、可枚举的活跃令牌集合。攻击者可以推导出已登录用户的有效会话令牌，并绕过源IP和User-Agent验证——通过构造一个利用Web服务器路径路由中文件扩展名处理的畸形URI，绕过每会话的源地址验证，然后从不同源地址使用推导出的令牌获取提权。这里的缝不在令牌本身，在于令牌的生成逻辑假设了“时间+型号”提供了足够的熵，而这个假设在攻击者知道型号和大致时间的情况下不成立。

密码重置令牌的缝，在于“一次性”和“有效期”这两个属性没有被强制执行。vikunja的CVE-2026-28268是一个业务逻辑漏洞：重置令牌在使用后没有被失效，而且令牌清理cron job存在关键逻辑bug，导致重置令牌永久有效。攻击者只要在任何时候截获一个令牌（日志、浏览器历史、钓鱼），就可以在未来任意时间完成持久的完整账户接管。Flarum的CVE-2026-39923是有效期绕过的另一个版本：过期的重置令牌可以通过直接提交到重置处理端点被重用，绕过24小时限制。

还有一个更隐蔽的缝：密码重置与令牌失效之间的脱节。CVE-2026-22706记录了一个场景：攻击者之前获得的refresh token，在合法用户重置密码之后仍然可以继续铸造新的access token。轮换凭证不再终止活跃的攻击者会话，密码重置作为遏制措施失效了。补丁的逻辑是：在每一次密码修改和密码重置时，使用户关联的所有refresh token失效，无论是否提供了deviceId。

对你意味着什么：测会话令牌时，检查生成逻辑的熵来源——如果它包含时间、设备ID、递增序列，尝试推导。测密码重置时，用同一个令牌提交两次，用过期令牌提交，在密码重置后检查旧的refresh token是否仍然有效。“一次性”和“过期”不是文档里写了就生效的，它需要在每一个消费令牌的代码路径上被强制执行。

五、唯一的共同点：身份验证的“完成”是一个跨组件的共识，而共识在2026年经常不成立

把这七条缝放在一起，一个更抽象的结论浮出来：身份验证的“完成”从来不是某一个组件能单独决定的事情。 它是令牌签发方、令牌验证方、身份链接逻辑、MFA状态机、会话管理器和密码恢复流程之间达成的共识。2026年的CVE列表说明，这个共识在每一个接口上都可能破裂。

vlife的硬编码密钥让“签发方”和“验证方”之间的信任变成了公开信息。libjwt的算法混淆让“签名有效”和“可信签发”脱钩。Wallos的email链接让“IdP说这是管理员的邮箱”直接变成了“他是管理员”。Logto的step-up让“有一个验证记录”冒充了“完成了当前操作要求的验证”。tinyauth的OIDC handler让“有用户上下文”冒充了“MFA已完成”。Lantronix的确定性令牌让“知道型号和时间”冒充了“持有会话”。vikunja的永不过期重置令牌让“曾经截获过一次”冒充了“现在有权重置”。

每一次失败，都不是某个组件“没有做验证”，而是某个组件“验证了错误的东西”，而下一个组件“信任了那个错误的结论”。

如果你在做身份验证的安全测试或代码审计，把问题从“这里有没有校验”换成：“这个校验的结论，被谁消费了？消费它的组件，是否用同样的语义理解这个结论？” 硬编码密钥的结论是“签名有效”，但验证方需要的是“由我方签发”。email链接的结论是“邮箱匹配”，但应用需要的是“身份已验证”。step-up的结论是“有验证记录”，但操作需要的是“完成了特定语义的验证”。缝就长在语义的错位上。

写在最后

2026年的身份验证攻击，已经很少是“猜密码”或者“爆破OTP”了。攻击者读代码仓库里的密钥，交叉算法声明和密钥类型，找email-based的fallback链接，利用TOTP-pending状态去换OIDC授权码，推导基于时间的会话令牌，等一个永远不会过期的重置令牌。

身份验证不是一道门，是一条链。链的强度不取决于最坚固的那一环，取决于相邻两环之间对“什么算完成”的共识有多牢固。 2026年的CVE在提醒你：那个共识，比你想象的要脆弱得多。

严正声明

本文所述所有身份验证漏洞分析、CVE案例及攻击链，仅用于已获得明确书面授权的安全测试、代码审计、红队演练和安全研究场景。vlife（CVE-2026-110612）、Budibase（CVE-2026-73302）、Wallos（CVE-2026-61641）、Logto（CVE-2026-55377）、tinyauth（CVE-2026-32246）、vikunja（CVE-2026-34727、CVE-2026-28268）、libjwt（CVE-2026-44699）、Lantronix（CVE-2026-80154）等漏洞的验证必须在授权范围内进行，并及时将受影响组件更新至修复版本。未授权扫描、测试、攻击行为违反《中华人民共和国网络安全法》第27条及《刑法》第285条，将承担法律责任。技术无罪，边界是法律。