Предоставленный PoC намеренно ограничен:

• Он выполняет только touch /tmp/CVE-2026-82222-RCE-GETBAG.
• Он не предоставляет опции произвольных команд.
• Он не создаёт оболочку, callback, механизм персистентности или повышение привилегий.
• Он отказывается работать с целями вне loopback, если оператор не укажет явный флаг --allow-authorized-non-loopback.
• Docker публикует WordPress только на 127.0.0.1.
• Имя проекта Compose формируется из пути к каталогу, поэтому один клон не может удалить контейнеры или тома другого клона.
• Лаборатория использует чистый официальный исходный код плагина; она не инструментирует и не модифицирует уязвимую цель.

HTTP-тест создаёт одноразового донора, метаданные и строки сессии GiveWP. После тестирования используйте встроенную команду сброса.

Быстрый старт

Требования:

• Docker с Compose v2
• Python 3.10 или новее
• curl
• unzip
• sha256sum или shasum
• Сетевой доступ к downloads.wordpress.org для официальных архивов плагинов

Запустите полную матрицу уязвимая/исправленная версия:

Эта команда:

1. Загружает GiveWP 4.16.5.1 и 4.16.7.2 с WordPress.org.
2. Проверяет оба SHA-256 хеша.
3. Создаёт новую лабораторию WordPress 6.6.2/PHP 8.1 только на loopback с явно отключённой стандартной регистрацией WordPress.
4. Тестирует чистую версию 4.16.5.1 и требует создания маркера веб-пользователем.
5. Создаёт вторую новую лабораторию с чистой версией 4.16.7.2.
6. Требует отсутствия HTTP-маркера.
7. Обходит вход в систему при прямом управлении и подтверждает, что исправленный терминальный ProviderForwarder также отклоняет строковый callable.

Исправленная лаборатория остаётся запущенной в конце. Удалите её с помощью:

Для использования другого loopback-порта:

Ожидаемые доказательства

Уязвимый контроль должен завершиться конкретными терминальными доказательствами:

Исправленный контроль должен показать:

HTTP 500, сохранённая нагрузка, исключение или срабатывание детектора без маркера не принимаются как доказательство RCE.

Ручной жизненный цикл лаборатории

Запустите и протестируйте уязвимую версию:

Запустите и протестируйте исправленную версию:

Проверьте текущее состояние:

Удалите контейнеры, тома, тестовых пользователей, сессии и состояние маркера:

Кэшированные ZIP-архивы плагинов и извлечённые ресурсы сохраняются для ускорения повторных запусков. Удалите и эти сгенерированные ресурсы с помощью:

Затронутые и протестированные версии

Публичный advisory указывает версии до 4.16.7.1 включительно как затронутые. Этот репозиторий напрямую доказывает только две версии в своей матрице положительных/отрицательных тестов.

Ссылки:

• Advisory 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-цепочка

Граф, контролируемый атакующим:

Критический скрытый переход — это неявная диспетчеризация IteratorAggregate в PHP. TCPDF::$imagekeys не типизирован, поэтому присвоение Symfony Session заставляет foreach вызывать Session::getIterator().

Маркерная команда выполняется до того, как Symfony применит тип возврата getAttributeBag(): AttributeBagInterface. Возникающие TypeError и HTTP 500 являются пост-синк эффектами.

Что упустили более ранние попытки

Отклонённый граф-кандидат использовал:

Этот граф не может работать. TCPDF::_destroy() только удаляет objcopy; PHP не направляет автоматическое уничтожение через __call('__destruct', ...).

Отсутствующей операцией была:

Более ранний обзор следовал за деструкторами и явными вызовами методов, но не рекурсивно исследовал неявный объектный протокол, запускаемый foreach. Symfony Session предоставляет недостающий мост:

• foreach вызывает getIterator().
• getIterator() достигает getBag($attributeName).
• Контролируемое атакующим storage — это DonationFactory.
• Неопределённый getBag вызывает ProviderForwarder::__call().
• loadedProviders['getBag'] = 'system' выбирает callable.
• 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. Восстановите этот снапшот в изолированном staging-окружении.
4. Отключите ненужный исходящий сетевой доступ.
5. Запустите этот верификатор только с маркером против клона.
6. Обновите GiveWP до последней поддерживаемой версии, при этом 4.16.7.2 — минимальная версия, содержащая протестированные исправления.
7. Повторите идентичный тест и требуйте отсутствия маркера.
8. Независимо проверьте установленную версию плагина и исправленный исходный код.

Проверка версии:

Исправление и разбор инцидента

Обновите GiveWP до последней поддерживаемой версии. После обновления:

• Очистите кэши PHP opcode, где это применимо.
• Убедитесь, что более старая копия GiveWP не осталась активной или доступной через веб.
• Проверьте неожиданные учётные записи WordPress или доноров.
• Поищите в метаданных пользователей и сессиях GiveWP сериализованные графы TCPDF, Symfony Session или loadedProviders.
• Сопоставьте регистрацию, изменения профиля, запросы пожертвований и последующие ответы HTTP 500 из той же сессии.
• Исследуйте неожиданные дочерние процессы веб-сервера или изменения файловой системы.

Если интернет-доступная уязвимая установка содержит артефакты инъекции объектов, рассматривайте это как потенциальную компрометацию, а не только как необходимость обновления плагина.

Структура репозитория

Не включено в коммит:

Границы проверки

Стандарт доказательства намеренно строгий: только наблюдаемый командный маркер через немодифицированную стандартную цепочку обозначается как RCE. HTTP-приём, сериализация, исключения и срабатывания детекторов являются промежуточными доказательствами.