安全公告的支持范围只列主程序，扩展出的问题算谁的

内容系统的安全公告支持范围只写主程序和框架，这是 Joomla 安全中心直接说明的：这份通告只提供已解决的 Joomla! 软件发布中的安全问题，并写明只为 Joomla! CMS、Joomla! Framework 与官方站点网络提供支持。也就是说，站点上真正在跑的第三方扩展，不在这条支持范围里。最新的两条通告编号是 1095 与 1096，严重度 Moderate，受影响版本从 1.5.0 一直到 5.4.8、以及 6.0.0 到 6.1.3，修复日期同为 2026-09-25。

公告清单覆盖的是哪些对象

它覆盖的是「由谁发布、由谁负责修补」的对象，而不是「站点上有多少软件」。主程序、框架、官方站点这三类有明确的维护者，因此有统一的发布通道和格式；扩展项目的维护者是分散的，代码节奏、支持版本和修复方式都由项目自己定。

把清单当成站点的全部暴露面是常见误读。清单之外的部分往往更多：站里挂的扩展、模板用到的脚本、以及接口上对接的外部服务。这些不在同一份通告里，出问题时需要另一套跟踪动作。

范围写在页面上是为了什么

写明范围的作用是让读者能判断「这条公告与我有关吗」。配套的三条信息是严重度、受影响版本和修复日期：版本区间决定你是否命中，严重度决定排序，修复日期决定还有多少时间。这三条成对出现才构成可执行的判断，只有一句「修复了若干问题」是不够的。

需要注意的是，官方给的严重度分档是按项目自身口径评的，不等于你站上的实际风险。同一个缺陷，开放注册的站点和只给内部账号使用的站点，暴露面差好几档。

扩展类问题走哪条通道

通常有三条。第一条是扩展项目自己的发布记录与安全通告，维护者可能在项目仓库、官方站点或社区论坛里发；第二条是通用漏洞编号体系，第三方研究机构提交后按组件披露；第三条是聚合型的漏洞目录，把不同来源的问题收在一个检索入口里。

实际操作上更稳的做法是把跟踪对象列出来，而不是把公告页收藏起来：每个扩展记下维护者是谁、发布页在哪、最近一次更新是什么时候。长期没有更新的扩展要单独标注，因为「没人发通告」很可能不是没有问题，而是没有人在维护。

站内的两道补位

第一道在入库前。扩展带来的输入面通常比主程序更宽，表单字段、富文本、附件说明这些内容都会进入站内。把内容审核与敏感词过滤配在入库这一步，能挡住一部分明显不可信的文本进入展示链路，它不能替代代码修复，但能压缩可被利用的内容形态。

第二道在使用权限上。扩展往往附带后台设置页与接口入口，按用户组把可操作范围收小，能减少「一次凭据泄露就整站可改」的情况。哪些角色可以改配置、哪些只能发内容，这件事在装扩展之前定下来比之后补更省事。多站点场景里，还要确认扩展是分站点启用还是全局生效，全局启用的扩展会把一个问题放大到所有站点。

常见问题

主程序公告里没有我的扩展，是不是没人管？ 不是，扩展由项目自己发；如果长期没有发布记录，应把它当成风险项而不是安全项。

能不能把支持范围理解成责任划分？ 它是维护边界的声明。范围外的问题不必然无人修，但修复时间与补丁形态不可预期。

站内已有的防护能不能顶住未修的扩展缺陷？ 入库前的审核与权限收口能压缩利用条件，不能替代版本跟进；确认被利用时要先收口入口再排升级。

要多久复核一次扩展清单？ 建议与主程序的版本检查同频，每次主程序升级时顺带确认扩展的最近更新时间是否落在支持期内。