上个月 Quix Page Builder 的 SQL 注入提醒犹在耳边，另一个流行页面构建器又出事了。10 月 27 日，Balbooa 发布 Gridbox 2.20.4.2，一次性修复两个可被匿名访客直接触达的 SQL 注入漏洞——Joomla CNA 同日发布 CVE-2026-102788 和 CVE-2026-102789，双双定级 CVSS 4.0 评分 9.3（Critical），受影响范围覆盖从 1.0.0 到 2.20.4.1 的全部历史版本。安全监测方 mySites.guru 的数据更说明问题的紧迫性：发布当天早晨，其监测的 Gridbox 站点约 95% 还运行在受影响版本上。如果你在用 Gridbox，请把这篇当作加急通知。

两个漏洞：一条经典注入加一条零权限端点

第一个（CVE-2026-102788，CWE-89）在商店和分类文章列表的排序参数上：访客可以通过页面 URL 指定列表的排序方式，而在 2.20.4.1 及之前，这个用户提供的值被直接拼进了数据库查询的 ORDER BY 子句——匿名访客由此可以读取站点数据库中的数据，包括 Joomla 用户表。2.20.4.2 的修复是把排序值对白名单做严格校验，不在名单上的一律回退到安全默认值，这是教科书式的正确修法。第二个（CVE-2026-102789，CWE-284）更离谱：页面编辑器里有一个加载博客文章的任务，在 2.20.4.1 上完全没有权限检查——任何访客都能调用它，而这个任务的排序参数进了同一个查询，等于给第一条注入又开了一扇不用认证的门。

两个漏洞都不需要登录、不需要用户交互，网络可达、低复杂度——这正是 CNA 给出 9.3 Critical 的原因（mySites.guru 自己读代码后认为按只读注入评 8.7 High 更准确，但引用记录里的 9.3，因为扫描器和其他通告都会显示这个分数）。无论哪个数字，结论一致：今天就升级。

值得警惕的不只是这一次

看一眼 Gridbox 最近两个月的时间线：9 月 21 日，2.20.3.1 修复博客作者参数的未认证 SQL 注入；10 月 8 日，2.20.4.0 修复语言安装 CSRF 和图片路径检查；10 月 21 日，2.20.4.1 发布；10 月 27 日，又是两个 Critical 注入——而且这次的排序注入与上次的博客作者注入发生在同一批列表代码里。再往前翻，7 月的一次安全审计在 Gridbox 里发现过 23 个严重漏洞，外加一个"一个 Cookie 即可成为超级用户"的认证绕过。

为什么页面构建器是 SQL 注入的重灾区？我的观察有三点：它们暴露大量前端 AJAX 端点（排序、筛选、预览、编辑器数据加载），每一个都是潜在攻击面；它们的核心功能就是把用户输入翻译成复杂数据库查询，出错概率天然高；版本迭代快，新端点上线的速度容易跑赢安全审查。Quix 和 Gridbox 先后中招不是巧合，而是这个品类的结构性风险。

给中文用户的行动清单

用 Gridbox 的站点：立即升级到 2.20.4.2，后台"扩展-更新"即可。受影响范围为 1.0.0-2.20.4.1 全部版本，不存在"版本够新应该没事"的侥幸。不确定是否已被利用的站点：检查访问日志中排序参数（sort/order 类）的异常值、核对超级用户列表、查看新增的管理员账户——数据库读取不留痕，但后续利用往往会留。用其他页面构建器的站点：Quix 用户请确认已到 6.3.4；其余品牌建议本月内完成一次版本核查——这个月已经证明了没人能置身事外。所有站点：这次修复的协调人是 Joomla Security Strike Team 的 David Jardin——正是 J!Awards 2026 的年度志愿者。官方安全团队的响应质量是 Joomla 生态的隐形资产，但响应再快也快不过你点一下更新按钮。

总结

一个月内两大页面构建器先后曝出未认证 SQL 注入，95% 的 Gridbox 站点在披露当天仍暴露在 9.3 分的 Critical 之下——这组数字应该改变你对"选型"的看法：评估页面构建器时，安全修复记录（CVE 历史、响应速度、覆盖范围）应当与功能清单放在同一张表里。功能决定站点能做成什么样，安全决定站点能活多久。