В плагине GiveWP для WordPress нашли уязвимость максимальной критичности: CVE-2026-82222 позволяет выполнить произвольные команды на сервере. Для рынка это неприятная новость не только потому, что у GiveWP более 100 тысяч установок, но и потому, что речь идет о донатных формах, то есть о сайтах, где крутятся деньги, персональные данные и репутация некоммерческих проектов. Уязвимость GiveWP затрагивает версии вплоть до 4.16.7.1 и выглядит как классический пример того, как несколько «почти безобидных» дефектов в цепочке превращаются в полноценный RCE.
О проблеме сообщает BleepingComputer со ссылкой на исследование Patchstack. Баг зарегистрирован под идентификатором CVE-2026-82222, а сообщил о нем исследователь Udin Chan 28 июля через платформу Patchstack Vulnerability Intelligence. Исправление вышло 27 августа в версии 4.16.7.2. Сам GiveWP используется для приема пожертвований и управления фандрайзинговыми кампаниями, так что атака бьет не по абстрактному WordPress-сайту, а по инфраструктуре, где часто есть база доноров, почты, платежные сценарии и ограниченный штат администраторов, который не живет в панели обновлений 24/7.
Технически эксплуатация строится не на одном баге, а на связке из трех проблем. Первая часть цепочки — небезопасный helper для десериализации PHP-данных. Вторая — сценарий обработки пожертвования, который сохраняет сериализованные объекты, контролируемые атакующим. Третья — gadget chain в библиотеках, поставляемых вместе с плагином, через которую можно дойти до выполнения системных команд. В переводе на человеческий язык это значит следующее: злоумышленнику достаточно подготовить специальный объект, протащить его через поток обработки доната, а затем дождаться момента, когда сервер его распакует и послушно выполнит чужую команду. Для WordPress-экосистемы это давно знакомый сюжет, но от этого не менее токсичный.
На первый взгляд у атаки есть ограничение: злоумышленнику нужен аккаунт на целевом сайте. Но дальше начинается самая неприятная часть истории. По данным Patchstack, GiveWP предоставляет неаутентифицированное действие регистрации пользователя — give_action=user_register, которое не проверяет настройку WordPress users_can_register. Иначе говоря, даже если владелец сайта отключил регистрацию в стандартной конфигурации WordPress, плагин фактически открывает обходной вход. Атакующий может создать учетную запись, получить cookie аутентификации и тут же продолжить атаку в той же последовательности. После входа он сохраняет вредоносный сериализованный объект в своем профиле, внедряет его в базу сессий плагина через специально сформированное пожертвование, а затем запрашивает любую публичную страницу сайта. На этом этапе сервер десериализует объект и исполняет команду. Отдельная ирония ситуации в том, что запись вредоносной нагрузки в таблицу wp_give_sessions, по словам исследователя Patchstack Джорджа Джонстоуна, происходит еще до возврата HTTP 500. Ошибка видна, а вред уже заложен.
Есть и важная оговорка по охвату. Версии 4.16.6–4.16.7.1 остаются уязвимыми не при любой конфигурации, а при наличии legacy-формы пожертвований без formBuilderSettings. Это не делает риск академическим. Наоборот: такие условия вполне реальны на сайтах, которые обновляли плагин поверх старых инсталляций, используют редактор форм на основе опций или импортировали и восстанавливали старые формы из резервных копий. Для корпоративных и некоммерческих команд это как раз типичный сценарий эксплуатации WordPress: сайт живет годами, плагины мигрируют неидеально, старые сущности в базе никто не любит, но и не трогает. В итоге «устаревшая форма» часто означает не редкий corner case, а обычное состояние продакшена.
Разработчики GiveWP закрыли дыру в версии 4.16.7.2. По данным Patchstack, обновление блокирует сериализованные данные в процессе обработки пожертвований, ужесточает создание объектов в нескольких точках десериализации и дополнительно удаляет уже сохраненные сериализованные payload из затронутых баз данных. Это хороший штрих: не только прекратить новые атаки, но и убрать следы старых заготовок. При этом сама регистрационная логика GiveWP, которая игнорирует настройку WordPress для регистрации пользователей, как отмечает Patchstack, формально осталась, просто больше не ведет к удаленному выполнению кода через эту конкретную цепочку. Для безопасников это означает простую вещь: патч закрывает самый опасный маршрут, но сам по себе не отменяет необходимость проверить модель регистрации, списки пользователей и журналы событий. Если на сайте внезапно появились новые аккаунты, особенно около даты публикации исследования и выхода патча, это уже не мелочь для бэклога.
Контекст у истории тоже неприятный. BleepingComputer напоминает, что в прошлом году через атаки на GiveWP злоумышленники косвенно скомпрометировали Pi-hole и раскрыли имена и email-адреса 30 тысяч доноров. Тогда речь шла не о полном захвате сервера, а о данных жертвователей, но репутационный эффект был предсказуемо болезненным. Для российского и вообще русскоязычного рынка это важный сигнал: плагины для пожертвований и подписок часто воспринимаются как «не core-система», которую обновят по остаточному принципу. На деле они ближе к платежному контуру, чем кажется. Если уязвимость GiveWP дает RCE, дальше вопрос уже не в одном сайте. После первичного доступа атакующий может красть переменные окружения, ходить по соседним сервисам, вытаскивать API-ключи, почту, резервные копии и все то, что в небольших командах часто лежит рядом и надеется на лучшее.
Для администраторов вывод практический: обновляться до 4.16.7.2 нужно без философии про удобное окно, а заодно проверить старые формы, таблицу сессий GiveWP, новые пользовательские аккаунты и признаки необычной активности после пожертвований с ошибкой HTTP 500. Для разработчиков и владельцев WordPress-инфраструктуры история еще раз показывает, что риск в 2026 году рождается не только из «нулевого дня», но и из наследия: старых форм, десериализации PHP, неявных registration flow и сторонних библиотек, которые внезапно умеют больше, чем хотелось бы. Чем больше в CMS-проекте таких исторических слоев, тем выше шанс, что следующий критический баг окажется не исключением, а закономерностью.