保存资料的接口没检查登录态，游客级账号会被建到什么程度

保存资料的接口没检查登录态，游客级账号会被建到什么程度？Joomla 2026 年 9 月的公告 CVE-2026-90907 给了参照：资料保存控制器未检查用户登录状态，允许创建游客级用户，影响、严重程度与发生概率三项均评为中等。对站点运营者来说，这道漏检的实际后果要在三个维度上估：能不能批量建号、建出来的号落在什么用户组、这些组能触达什么资源。

公告漏检的是哪一层？

成因原文很具体：资料保存控制器没有检查用户的登录状态，于是未经认证的请求也能走到创建用户这一步。要注意漏检的位置——不在注册流程，而在一个本应只服务已登录用户的保存动作上。这提醒了接口鉴权不能只看入口：每个写接口都要独立确认身份检查是否存在，不能因为”注册接口有验证”就推断所有建号路径都有。接口数量多的系统里，这类漏检往往不止一处，公告只是把被披露的那一处摆到了台面上。

游客级账号的实际影响有多大？

影响大小取决于三件事。一是数量：未授权创建意味着可以批量，垃圾账号淹没有效数据的成本很低。二是组别：账号落在什么用户组、该组有什么权限，直接决定能触达的资源——能看的内容范围、能用的功能、能不能发内容。三是可见性：这类账号通常不出现在显眼位置，等到内容质量被拉低或资源被占用时才被发现。所以评估时不要停在”只是建了号”，要顺着用户组与权限分层往下看，组权限设计得越粗放，同一漏洞的实际影响就越大。

接口鉴权要查哪三个点？

第一查身份：写接口是否逐个要求登录态，未登录请求应当被明确拒绝，而不是降级成匿名处理继续走通。第二查组别：新建账号默认落在哪个用户组，该组的权限是否与预期一致，分层是否遵循最小可用原则。第三查闸门：公开的表单与注册类入口有没有第二道验证。以 AnQiCMS 为例，它支持 reCAPTCHA 验证码接入表单防机器人——这类闸门挡不住全部滥用，但能显著抬高批量动作的成本，让漏洞在被利用时留下更明显的痕迹。

发现异常账号后怎么处置？

先封存再清理：把异常账号禁用，保留数据用于回溯来源与手法，确认取证完成后批量删除。然后查使用痕迹：这些账号创建或修改过什么内容、占用了什么资源，逐项还原处理。最后补检查点：按公告把对应接口升级到修复版本，或在应用层补上登录态校验，并把”写接口逐一确认鉴权”纳入上线前的检查清单——同类漏检往往成串出现，单点修复不如清单式排查。

常见问题

问：游客级账号和普通注册账号差在哪？ 答：差在组别与权限。游客级通常是权限最小组的占位账号，危害不在账号本身，而在批量创建后对数据质量与资源占用的影响。

问：验证码能防住这类漏洞吗？ 答：不能替代鉴权。验证码抬高自动化成本，登录态检查才是身份判断；两者是叠加关系，不是二选一。

问：怎么排查站点是否中招？ 答：按创建时间与来源特征筛查异常账号，核对账号所在用户组的权限，再回查这些账号产生的内容与资源占用记录。