HTTP 测试会创建一个一次性的捐赠者用户、元数据和 GiveWP 会话行。测试后请使用附带的重置命令。

快速开始

要求：

• 带 Compose v2 的 Docker
• Python 3.10 或更高版本
• curl
• unzip
• sha256sum 或 shasum
• 可访问 downloads.wordpress.org 以获取官方插件归档

运行完整的易受攻击/已修补矩阵：

该命令：

1. 从 WordPress.org 下载 GiveWP 4.16.5.1 和 4.16.7.2。
2. 验证两个 SHA-256 哈希值。
3. 构建一个全新的仅回环 WordPress 6.6.2/PHP 8.1 实验室，并明确禁用正常的 WordPress 注册。
4. 测试原始 4.16.5.1，并要求 Web 用户创建标记。
5. 使用原始 4.16.7.2 构建第二个全新实验室。
6. 要求 HTTP 标记保持不存在。
7. 在直接控制中绕过入口，并确认已修补的 ProviderForwarder 终端也拒绝字符串可调用。

已修补的实验室在结束时保持运行。使用以下命令移除它：

要使用另一个回环端口：

预期证据

易受攻击的控制必须以具体的终端证据结束：

已修补的控制必须显示：

没有标记的 HTTP 500、存储的载荷、异常或检测器命中 不被接受为 RCE 证据。

手动实验室生命周期

启动并测试易受攻击的版本：

启动并测试已修补的版本：

检查当前状态：

移除容器、卷、测试用户、会话和标记状态：

缓存的插件 ZIP 和提取的资源会被保留以加快重新运行。使用以下命令同时移除这些确切生成的资源：

受影响和已测试的版本

公开公告将 4.16.7.1 及之前的版本列为受影响。本仓库仅直接证明其阳性/阴性测试矩阵中的两个版本。

参考：

• Patchstack 公告
• CVE-2026-82222
• GiveWP 加固提交
• GiveWP 官方插件页面

根本原因

该漏洞利用结合了多种行为：

1. GiveWP 4.16.5.1 暴露了一个注册操作，即使在正常 WordPress 注册被禁用时也会创建并认证一个低权限捐赠者。
2. 该用户可以在自己的名字元数据中持久化序列化数据。
3. Give\Helpers\Utils::maybeSafeUnserialize() 使用 allowed_classes => false，产生 __PHP_Incomplete_Class，但后续的序列化保留了原始的类名和属性。
4. 该对象图存储在 GiveWP 购买会话中。
5. 后续不受限制的 maybe_unserialize() 复活了随附的类。
6. 自动析构进入一个完整的 POP 链，最终调用 system()。

HTTP 载体中需要四个字面命名空间反斜杠。两次有效的剥离过程将其从 4 -> 2 -> 1 减少。载荷不含 NUL 字节，并且已验证 PHP 8.1.30 能为私有 Session::$attributeName 属性水合纯序列化名称。

完整 POP 链

攻击者控制的对象图：

关键的隐藏转换是 PHP 隐式的 IteratorAggregate 分发。TCPDF::$imagekeys 是无类型的，因此分配一个 Symfony Session 会导致 foreach 调用 Session::getIterator()。

标记命令在 Symfony 强制执行 getAttributeBag(): AttributeBagInterface 返回类型之前执行。由此产生的 TypeError 和 HTTP 500 是后置效应。

早期尝试遗漏了什么

被拒绝的候选对象图使用了：

该对象图无法工作。TCPDF::_destroy() 仅 unset objcopy；PHP 不会将自动析构路由到 __call('__destruct', ...)。

缺失的操作是：

早期的审查跟踪了析构函数和显式方法调用，但没有递归检查 foreach 触发的隐式对象协议。Symfony Session 提供了缺失的桥梁：

• foreach 调用 getIterator()。
• getIterator() 到达 getBag($attributeName)。
• 攻击者控制的 storage 是一个 DonationFactory。
• 未定义的 getBag 调用 ProviderForwarder::__call()。
• loadedProviders['getBag'] = 'system' 选择可调用对象。
• attributeName 提供命令参数。

源码证据

相关的 GiveWP 4.16.5.1 位置：

官方发布哈希值：

实验室在每次全新启动前都会从已验证的 ZIP 中重新提取每个插件，将其无修改地复制到 WordPress 中，并将部署的完整插件文件树与已验证的源码进行字节比较。三个官方 Docker 基础镜像也固定在其多架构清单摘要上。

为什么 4.16.7.2 阻止了该链

GiveWP 4.16.7.2 在注册、序列化输入处理、会话复活、数据迁移和小工具加固方面增加了独立的防御。

终端加固要求解析出的对象实现预期的提供者契约：

因此，攻击者控制的字符串 system 被拒绝。本仓库中的直接控制绕过 HTTP 载体，并验证仅凭这一终端防御就足以使其标记保持不存在。

检查真实部署

单独的阴性 PoC 结果不证明站点已修补。WAF、不同的路由、禁用的注册、缺失的旧版表单、会话配置或禁用的 PHP 命令函数都可能在一个仍然易受攻击的代码库上阻止标记。

推荐的验证流程：

1. 记录已部署的 GiveWP 版本和源码修订号。
2. 备份或快照 WordPress 站点和数据库。
3. 将该快照恢复到隔离的暂存环境中。
4. 禁用不必要的出站网络访问。
5. 针对克隆运行此仅标记验证器。
6. 将 GiveWP 更新到最新的受支持版本，其中 4.16.7.2 是包含已测试修复的最低版本。
7. 重复相同的测试并要求标记不存在。
8. 独立验证已安装的插件版本和已修补的源码。

版本检查：

修复和事件审查

将 GiveWP 更新到最新的受支持版本。更新后：

• 在适用的情况下清除 PHP opcode 缓存。
• 确认没有旧版 GiveWP 副本仍然处于活动状态或可通过 Web 访问。
• 审查意外的 WordPress 或捐赠者账户。
• 在用户元数据和 GiveWP 会话中搜索序列化的 TCPDF、Symfony Session 或 loadedProviders 对象图。
• 关联同一会话中的注册、个人资料更改、捐赠请求和后续 HTTP 500 响应。
• 调查意外的 Web 服务器子进程或文件系统更改。

如果暴露于互联网的易受攻击安装包含对象注入痕迹，请将其视为潜在沦陷，而不仅仅是更新插件。

仓库布局

未提交的内容：

验证边界

证据标准刻意严格：只有通过未修改的库存链产生的可观察命令标记才被标记为 RCE。HTTP 接受、序列化、异常和检测器命中均为中间证据。