如果您收到我发来的邮件，指引您访问本页面，那是因为您的网站似乎正在运行 Events Manager（WordPress 插件 events-manager，由 Marcus Sykes / wp-events-plugin.com 开发）的某个版本，而该版本落在一个已知安全问题的受影响范围之内。本页面将说明这个问题是什么、 如何判断它是否适用于您的站点，以及如何更新。

在其他一切之前，先说关于本通知最重要的一点：处于受影响范围内的版本，本身并不意味着您的站点 会暴露。 下面描述的问题，只有当 Events Manager 被配置为接受 未登录 访问者的预订时才可能 被利用（该插件称之为 “No-User-Account Booking Mode”，即无用户账户预订模式）。如果您的站点要求 先有账户才能预订，或者根本不接受预订，那么即便处于受影响的版本，它也很可能不会暴露。我可以从 公开文件中读取您的插件版本，但我无法看到您的预订配置，因此本通知是一份预防性的提醒，而不是 关于您站点的确认结论。

这个问题是 CVE-2026-12987，是该插件预订系统中的一个未经身份验证的 PHP 对象注入，可进而导致 SQL 注入。分配该 CVE 的机构并未公布严重性评分；Patchstack 将同一项发现评为 满分 10 中的 8.8 （高危）。它影响 4.0.0 至 7.3.6 版本，并已在 7.3.7 中修复。如果您正在运行受影响的版本， 请 将 Events Manager 更新到 7.3.7 或更高版本（推荐使用最新的 7.4.x 发行版）。没有任何迹象 表明这个问题正在任何地方被利用。

关于紧迫程度需要说明一点，因为这是我发出的通知中最取决于具体情况的一份：它对您有多重要， 几乎完全取决于那个预订设置。如果您站点的预订要求登录，那么更新只是例行的插件维护。如果您的 站点确实接受未拥有账户的访问者进行公开预订，请把更新当作优先事项：在这种配置下，该缺陷可能 让攻击者无需登录就 读取您站点数据库中的数据（例如密码哈希和密钥）。即便如此，本页面也是 一份预防性的提醒，而不是事件报告，并不意味着需要任何紧急响应。

这是一个 插件 缺陷，而不是 WordPress 核心的缺陷。如果 Events Manager 插件本身处于受影响的 版本，那么即便是完全最新的 WordPress 也 无法 保护您。

这条消息是否可信？

是的。这是一份来自独立安全研究人员的善意、负责任披露通知。我 不会 向您索要金钱、 密码或对您站点的访问权限，也 没有 试图入侵它、上传任何东西或利用任何漏洞。

我所做的一切，只是查看您的网站向每一位访问者提供的公开可见文件（就像您的主页是公开的一样）， 并记录 Events Manager 插件在其公开的 readme.txt 文件中公布的版本号。我特意 没有 触碰预订 系统，而且这项检查完全不涉及您的数据、您的后台管理区域，或您站点的任何私密部分（更多细节见 下方我做了什么、没做什么）。

如果您想核实我的身份，请查看本页底部的联系方式以及关于页面。

为什么这很重要

Events Manager 是 WordPress 上历史最悠久的活动与预订插件之一（自 2008 年起就在官方目录中， 在其生命周期内约有 630 万次下载）。它让站点能够发布活动并为这些活动接受预订，如果运营者选择 这样做，还包括来自站点上没有用户账户的访问者的预订。

在受影响的版本中，当访问者提交一份预订时，他们填写的自定义注册字段会被存储为预订数据；而当 插件随后加载该预订时，它会将存储的数据解包（”反序列化”），却不限制其中允许包含的内容。因此， 经过特制的输入可以被转化为攻击者所选择的程序对象（PHP 对象注入），而一连串这样的对象会到达 一个未被正确参数化的数据库查询（SQL 注入）。对处于易受攻击配置的站点而言，其实际后果是： 一个没有账户、没有登录的攻击者可能 读取站点数据库中的任意数据，例如密码哈希以及 WordPress 使用的密钥。

有两点有助于客观看待此事。第一，入口是公开的预订表单，因此这种攻击只有在未登录的访问者能够 提交预订的情况下才会奏效。这正是 “No-User-Account Booking Mode” 这一前提条件：如果您站点的 预订要求先有账户，那么匿名访问者就无法到达存在漏洞的路径，即便处于受影响的版本，您的站点也 很可能不会暴露。第二，这是一个 数据读取问题，而不是服务器或管理员权限的接管：它本身并不能 让攻击者在您的服务器上运行代码或登录您的后台管理区域。再直白地重复一遍，没有迹象表明存在 活跃的利用行为：它不在 CISA 的已知被利用漏洞目录中，其被利用可能性评分（EPSS）接近于零， 我也没有听说任何利用报告。

如果我的邮件引用了这个问题，那意味着您站点报告的版本落在受影响的范围之内。我并没有测试您的 具体站点是否可被利用，也无法看到您的预订系统是如何配置的；我所观察到的一切，只是该站点报告了 一个受影响的版本。

我是否受影响？

有两个问题可以决定这一点，按以下顺序。

第一：您是否接受未登录访问者的预订？ 这是起决定作用的问题，而且只有您自己能回答。

  • 如果您站点的预订 要求账户或登录，或者您的站点根本不接受预订，那么即便处于受影响的版本， 您也很可能 不会暴露。作为普通的维护，仍然建议更新。
  • 如果您的站点 接受未拥有账户的访问者进行预订（Events Manager 称之为 “No-User-Account Booking Mode”），那么这个问题适用于您，您应当尽快更新。
  • 检查方法：在 WordPress 后台，在 Events Manager 的预订设置中查找允许无用户账户进行预订的 选项。或者干脆从外部测试：在隐私浏览窗口中打开您的某个活动页面，看看您是否可以在不被要求 登录的情况下填写并提交一份预订。

第二：您运行的是哪个版本？ 您不必仅凭我的说法来判断。

从公开清单查看（无需登录）： 在浏览器中打开 yourdomain.com/wp-content/plugins/events-manager/readme.txt。请注意，这款插件的自述文件是 readme.txt（小写）。顶部附近的 Stable tag: 这一行是您的安装所报告的版本， 而这正是我读取的那个公开文件。

从 WordPress 后台管理区域查看（如果您有访问权限）：

  1. 登录您的 WordPress 仪表盘（通常位于 yourdomain.com/wp-admin）。
  2. 前往 Plugins 然后 Installed Plugins。
  3. 找到 Events Manager 并记下其名称下方显示的版本。

然后按照以下规则判断，并注意版本号是 按数值比较，而不是按字母顺序比较：

  • 4.0.0 至 7.3.6： 可能受影响（取决于上面关于预订模式的问题），请立即更新。
  • 7.3.7 或更新版本： 已经修复。这包括 7.3.7.1，它是针对一个非安全性显示回归的后续修复， 而不是第二次安全发布：7.3.7 和 7.3.7.1 都包含该安全修复。它也包括所有当前的 7.4.x 发行版。
  • 早于 4.0： 不受这个问题的影响。存在漏洞的预订数据处理是在该插件 4.0 版重写时首次引入的， 因此更早的发行版并不带有它（那么旧的发行版有大量其他理由需要更新，但本通知不是其中之一）。
  • 不要被文本排序误导：Events Manager 在 6.0 之前使用过诸如 5.99912 这样的版本字符串（厂商在 6.0 之前一直沿用 5.999.x 的编号方案），这样的版本是一个 低于 6.0 的旧发行版，处于受影响 的范围之内，而不是比 7 更新的版本。请逐个数字依次比较，而不要把版本号当作文本来读。

如何升级

最安全的做法是通过 WordPress 自身进行更新，并事先做好备份：

  1. 在做出更改之前 备份您的站点（文件和数据库）。大多数主机服务商都提供一键备份， 或者使用 WordPress 备份插件。
  2. 在 WordPress 后台，前往 Dashboard 然后 Updates，或 Plugins 然后 Installed Plugins。如果列出了 Events Manager 更新，就从这里安装它。
  3. 如果您更喜欢命令行，WP-CLI 可以完成同样的事情： wp plugin update events-manager。
  4. 如果没有出现更新，您可以直接从该插件在 WordPress.org 目录上的页面获取最新版本， Events Manager， 并通过 Plugins 然后 Add New Plugin 然后 Upload Plugin 进行更新。
  5. 更新后，按照上述步骤确认新的版本号（7.3.7 或更高；推荐使用最新的 7.4.x 发行版）， 并检查您的活动与预订页面是否正常工作。

既然您已经在处理这些，不妨顺便确认 WordPress 核心 以及您的其他插件是否都是最新的， 因为同样的原则适用于所有这些组件。

更新之后

更新到 7.3.7 或更高版本即可堵上这个问题，对大多数站点来说，这就是全部要做的事。没有迹象表明 这个缺陷已在任何地方被利用，因此 本通知不意味着需要任何紧急响应：您不需要把站点视为已被 入侵或将其下线。

有一项后续工作值得考虑，它同样取决于前面那个关于预订的问题。如果您的站点在处于受影响版本期间， 一直接受未拥有账户的访问者进行公开预订，那么该缺陷可能触及的数据（数据库内容，包括密码哈希和 密钥）至少在理论上是可读取的，尽管没有证据表明有人这样做过。在这种情况下，有两项例行的预防 措施是合理的：

  • 以您平常查看站点活动的普通方式，看看近期的预订和用户活动中有没有任何看起来不对劲的地方。
  • 轮换存放在您数据库和配置中的密钥：在 wp-config.php 中重新生成 WordPress 的密钥和盐值 （在官方的 密钥生成器 上， 点击一下即可得到新值；替换它们会让所有用户被登出一次），并通过您的主机面板更改数据库密码。 由于密码哈希也在理论上可读取的数据之列，让管理员账户刷新其密码是一个合理的额外步骤。

请把这当作普通的安全日常维护，而不是事件响应。如果您站点的预订一直都要求登录（或者您不接受 预订），那么仅仅更新就已足够。

我做了什么、没做什么

为了对我邮件背后的检查做到完全透明：我只读取了您的站点本来就向每一位访问者提供的公开文件， 具体来说是该插件的公开 readme.txt 文件和您的主页。我 没有 访问您的 WordPress 后台管理 区域、您的数据库，或站点的任何私密部分。特别是，我 没有 触碰那个存在漏洞的预订路径， 也没有测试或利用任何东西。

这是一项 基于版本号的观察：您的站点报告的版本落在受影响的范围之内。由于这个问题取决于 具体配置，处于该范围内的站点也可能根本不会暴露（如果预订要求登录，或者不接受预订），而且 它也可能已经通过其他方式得到缓解，例如 Web 应用程序防火墙。本通知并不是断言在我检查时您的 站点确实可被利用。

我没有网站管理员 / 我遇到了困难

如果您不是维护站点的人，请将本页面转发给负责维护的人（您的网页开发者、代理机构或主机服务商）。 他们会很快认出上述步骤。

如果您自己维护站点却遇到了困难，我很乐意免费帮您指明正确的方向。请使用下方的联系方式与我联系。

联系方式

Evan Harris，安全研究员

我就此类问题主动联系，纯粹是为了帮助运营者保护他们的站点。如果您希望不再被联系， 只需告诉我，我会予以尊重。

参考资料

官方通告与追踪

厂商 / 插件