| Имя плагина | Код заголовка и нижнего колонтитула AddFunc |
|---|---|
| Тип уязвимости | Межсайтовый скриптинг (XSS) |
| Номер CVE | CVE-2026-2305 |
| Срочность | Низкий |
| Дата публикации CVE | 2026-04-10 |
| Исходный URL-адрес | CVE-2026-2305 |
Плагин AddFunc Head & Footer Code XSS (CVE-2026-2305): Что владельцам сайтов WordPress нужно знать — и как WPFirewall защищает вас
Дата: 10 апреля 2026
Уровень серьезности (список Patchstack): Низкий (CVSS 6.5)
Затронутые версии: <= 2.3
Исправлено в: 2.4
Необходимые привилегии: Участник (аутентифицированный)
Недавнее раскрытие (CVE-2026-2305) описывает уязвимость аутентифицированного сохраненного межсайтового скриптинга (XSS) в плагине AddFunc Head & Footer Code для WordPress (версии до 2.3). Эта уязвимость позволяет пользователю с доступом уровня Contributor внедрять скриптовые нагрузки через пользовательские поля, которые могут быть позже отображены без очистки — создавая сохраненный XSS на страницах или экранах администратора, где эти поля выводятся.
Как команда WPFirewall (поставщик безопасности WordPress и управляемого WAF), я хочу предоставить вам читаемое, практическое изложение рисков, реалистичных сценариев атак, шагов по обнаружению и очистке, а также многоуровневых защит, которые вы должны применить немедленно. Я также объясню, как наши возможности брандмауэра защищают вас (включая виртуальное патчирование и подписи WAF), и предоставлю конкретные, безопасные рекомендации по коду и конфигурации для разработчиков и администраторов сайтов.
Это написано с точки зрения практикующего специалиста по безопасности WordPress — практично, без лишних слов, с воспроизводимыми шагами, которые вы можете использовать уже сегодня.
Исполнительное резюме — что произошло и почему это важно
- Плагин AddFunc Head & Footer Code (версии <= 2.3) позволял включать пользовательский контент из пользовательских полей постов в вывод без достаточной очистки/экранирования.
- Аутентифицированный пользователь с правами Contributor (способный добавлять или редактировать посты и пользовательские поля) мог сохранить нагрузку, содержащую теги скриптов или обработчики событий.
- Когда этот контент позже отображается на фронтенде или на странице администратора без надлежащего экранирования, сохраненный скрипт выполняется в браузере посетителя или администратора.
- Влияние зависит от того, где поле отображается:
- Если нагрузка выполняется на фронтенде (публичные страницы), посетители сайта могут пострадать (зловредные перенаправления, поддельные формы, криптомайнеры, инъекция контента).
- Если нагрузка выполняется на страницах администратора (например, когда редактор или администратор открывает пост в панели управления), пользователи с более высокими привилегиями могут стать мишенью, что приведет к захвату сайта: угон аккаунта, установка плагинов/тем, изменения настроек или установка задних дверей.
- Плагин был исправлен в версии 2.4. Немедленным правильным действием для затронутых сайтов является обновление до 2.4 или более поздней версии.
Почему Contributor может быть опасен — модель угроз в реальном мире
Многие владельцы сайтов считают пользователей уровня Contributor низкорисковыми, потому что они не могут публиковать контент. Хотя это верное представление для управления контентом, контрибьюторы все же обычно могут создавать посты, редактировать свои черновики и добавлять пользовательские поля (в зависимости от конфигурации сайта). Сохраненный XSS через пользовательские поля особенно опасен, потому что:
- Вредоносный контент постоянен — он хранится в базе данных и будет активироваться каждый раз, когда он отображается.
- Если сайт или тема выводят пользовательские поля на страницы администрирования (предварительный просмотр постов, мета-боксы) или на фронтенд-страницы без экранирования, скрипты выполняются с привилегиями просматривающего пользователя в их браузере.
- Злоумышленники могут создавать полезные нагрузки, которые выполняют действия от имени администратора (меняют пароли, создают учетные записи администраторов, устанавливают плагины), используя аутентифицированную сессию администратора и поддельные запросы (CSRF в сочетании с XSS).
Короче говоря: вклад пользователей, которым вы доверяли контент, может быть использован для компрометации сайта, если отсутствует очистка/экранирование.
Типичный поток эксплуатации (на высоком уровне, не подлежащий действию)
- Злоумышленник регистрирует или использует учетную запись с привилегиями Конtributora (или компрометирует одну).
- Злоумышленник редактирует черновик или создает пост и добавляет вредоносный контент в пользовательское поле (например,
<script>…</script>или полезные нагрузки на основе атрибутов, такие какonerror=…внутри разрешенного тега). - Сайт хранит этот контент в postmeta.
- Когда пост загружается в контексте, где плагин или тема выводят это пользовательское поле без очистки (фронтенд-страница, предварительный просмотр администратора или мета-бокс), браузер выполняет внедренный код.
- Если администратор просматривает затронутую страницу или пост в интерфейсе администратора (или если нацелены посетители), внедренный скрипт может:
- Украсть куки администратора (если не HttpOnly — хотя современные лучшие практики уменьшают кражу куки, но не все сайты следуют им),
- Использовать привилегии администратора для создания новой учетной записи администратора через REST API / конечные точки администратора,
- Изменять файлы или настройки плагинов/тем,
- Установить заднюю дверь или сохранить дальнейшее вредоносное ПО,
- Экстрагировать данные.
Поскольку эксплуатация часто требует взаимодействия администратора (просмотр поста в админке или клик по конкретной ссылке предварительного просмотра), Patchstack указывает “Требуется взаимодействие пользователя”, но это взаимодействие может быть таким же простым, как открытие редактора постов или созданной ссылки предварительного просмотра.
Практические шаги для защиты вашего сайта — немедленные действия (контрольный список)
- Обновите плагин
– Если вы используете AddFunc Head & Footer Code, немедленно обновите до версии 2.4 или выше. Это каноническое решение. - Если вы не можете обновить немедленно
– Удалите или временно отключите плагин.
– Заблокируйте учетные записи участников от редактирования или добавления пользовательских полей до обновления плагина.
– Примените виртуальное патчирование на уровне WAF (см. рекомендации WAF ниже). - Сканируйте на наличие вредоносного контента в пользовательских полях
– Используйте WPCLI или прямые запросы к БД для поиска мета-значений, содержащих<script,onerror=,яваскрипт:, или подозрительный HTML.
– Пример (сначала создайте резервную копию вашей БД):
запрос к базе данных wp "SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%
– Также ищитеonerror=,загрузка=,яваскрипт:шаблоны.
– Просмотрите записи и удалите или очистите подозрительные мета-значения. - Аудит учетных записей пользователей
– Проверьте всех участников и редакторов: они легитимны? Удалите устаревшие или подозрительные учетные записи.
– Обеспечьте использование надежных паролей и 2FA для привилегированных ролей (Редактор, Администратор). - Проверьте на признаки компрометации
– Ищите неизвестные учетные записи администраторов, неожиданные файлы плагинов/тем, недавно измененные файлы, запланированные задачи и исходящие соединения с сервера.
– Запустите сканирование на наличие вредоносного ПО (сканер WPFirewall или другой авторитетный сканер). - Поменяйте учетные данные и API-ключи, если есть подозрения на компрометацию
– Измените пароли администратора и любые открытые API-ключи.
– Аннулируйте сессии, если это необходимо (принудительный выход для всех пользователей). - Резервное копирование перед очисткой
– Сделайте полную резервную копию сайта (файлы и БД) перед устранением проблемы. Это сохраняет доказательства и дает вам точку отката. - Укрепите пользовательские поля в будущем
– Требуйте очистки при сохранении и экранирования при выводе — смотрите рекомендации по коду ниже.
Как безопасно найти вредоносные сохраненные XSS-записи
Поиск подозрительного контента в базе данных имеет решающее значение, но должен проводиться осторожно:
- Всегда создавайте резервную копию перед выполнением запросов или внесением изменений.
- Начните с запросов только для чтения, чтобы выявить подозрительные записи, затем просмотрите их вручную.
- Примеры запросов для обнаружения WPCLI:
# Найдите postmeta, который содержит <script"
Экспортируйте подозрительные мета-значения и проверьте их, затем решите, нужно ли их очистить или удалить.
Очистка подозрительных записей
Если вы идентифицируете вредоносные мета-значения:
- Если запись явно вредоносная (полные
<script>блоки), удалите строку мета. - Если запись содержит полезные данные, но также и внедренные теги, очистите содержимое:
<?php
Если вам некомфортно вручную редактировать базу данных, обратитесь к вашему разработчику или хосту.
Руководство для разработчиков: безопасная обработка пользовательских полей (очистка при сохранении и экранирование при выводе)
Уязвимости, подобные этой, обычно вызваны отсутствием или недостаточной очисткой на входе и отсутствием экранирования на выходе. Следуйте обоим принципам:
- Очищайте при сохранении (чтобы сохраненные данные были безопасными)
- Экранируйте при выводе (никогда не доверяйте сохраненным данным)
Рекомендуемые шаблоны:
- Используйте функции очистки WordPress при сохранении мета:
<?php
- При выводе всегда экранируйте в зависимости от контекста:
<?php
- Лучший шаблон: зарегистрируйте мета с обратным вызовом очистки (хорошо работает с REST):
<?php
- Всегда проверяйте права перед сохранением или отображением мета только для администраторов. Используйте nonce для админских форм.
WAF и виртуальное патчинг — немедленная защита на уровне сети
Когда существует уязвимость плагина и немедленное обновление невозможно, хорошо настроенный веб-экран приложения (WAF) предоставляет виртуальное патчинг. Виртуальное патчинг означает перехват вредоносных запросов и блокировку их до того, как они достигнут уязвимого кода.
Типичные меры WAF для этого типа хранимого XSS включают:
- Блокировка POST-запросов, которые содержат подозрительные скриптовые полезные нагрузки в известных именах мета-полей (например, содержимое postmeta,
_настраиваемый_*). - Блокировка или очистка запросов, которые содержат
<script>теги, атрибуты обработчиков событий (onerror=,загрузка=),яваскрипт:URI, закодированное в base64 содержимое скрипта или очевидные шаблоны обфускации. - Ограничение частоты POST-запросов, которые создают или обновляют записи от пользователей с низкими привилегиями.
- Блокировка известных сигнатур эксплуатации и кодировок полезных нагрузок.
Пример псевдо-правила (для общего движка WAF) — только концептуально:
# Псевдокод правила WAF: блокировать теги скриптов в полях postmeta'
Если вы используете WAF на основе хоста или облачный WAF, настройте правило, которое проверяет тело запроса на наличие этих шаблонов и блокирует их для пользователей с правами Участника/Автора. Это обеспечивает немедленное смягчение, пока вы обновляете.
В WPFirewall мы предоставляем целевые правила виртуального патчинга, которые обнаруживают и блокируют шаблоны, используемые в попытках хранимого XSS, в сочетании с мониторингом и уведомлением, когда произошла заблокированная попытка.
Примеры правил WAF — в стиле ModSecurity (пример, настройте под свою среду)
Ниже приведены примеры шаблонов, которые можно использовать в качестве отправной точки. Они иллюстративные — тестируйте внимательно, чтобы избежать ложных срабатываний:
Пример правила ModSecurity для обнаружения тегов в теле POST"
Пример правила для обнаружения атрибутов событий, таких как onerror= или onload="
Важно: всегда тестируйте правила в тестовой среде, чтобы выявить законные крайние случаи (некоторый законный контент может включать разрешенный HTML) и настраивайте правила соответственно.
Обнаружение — журналы и индикаторы эксплуатации
Если вы подозреваете, что произошла эксплуатация:
- Проверьте журналы доступа сервера на наличие POST-запросов, которые создают или изменяют посты (POST-запросы к /wp-admin/post.php, /wp-json/wp/v2/posts).
- Проверьте журналы приложения (если они у вас есть) на наличие подозрительных параметров POST.
- Ищите предупреждения от вашего сканера вредоносного ПО, показывающие измененные файлы плагинов/тем, незнакомые файлы или веб-оболочки.
- Проверьте список администраторов на наличие вновь созданных учетных записей администратора.
- Ищите исходящие соединения с вашего сервера к неизвестным хостам.
- Просмотрите недавние задания cron и запланированные задачи на наличие неизвестных PHP-исполнений.
Если вы найдете внедренный контент в postmeta, рассматривайте это как потенциальное компрометирование: выполните полный ответ на инцидент (карантин, судебный снимок, восстановление из чистой резервной копии, если это необходимо).
После заражения — устранение и усиление безопасности
Если вы найдете доказательства того, что сайт был скомпрометирован:
- Изолировать отключите сайт (выведите его из сети или заблокируйте входящий доступ) во время расследования.
- Сохраняйте доказательства: сделайте полный снимок, сохраните журналы (веб-сервер, база данных).
- Определите механизмы постоянства: проверьте наличие добавленных администраторов, измененного wp-config.php, замененных файлов ядра, вредоносных плагинов/тем, задач cron, запланированных событий.
- Очистить: удалите вредоносные файлы и записи в базе данных. Если не уверены, восстановите из чистой резервной копии.
- Изменить учетные данные: сбросьте все пароли, аннулируйте ключи API, измените ключи SSH.
- Установите патч: обновите ядро WordPress, плагины и темы до последних версий.
- Укрепление: ограничьте права доступа к файлам, отключите редактирование файлов через wp-config.php (
define('DISALLOW_FILE_EDIT', true)), обеспечьте двухфакторную аутентификацию для всех администраторов, пересмотрите минимальные привилегии для всех учетных записей. - Монитор: включите мониторинг безопасности, мониторинг целостности файлов и оповещения о критических событиях.
Долгосрочные меры контроля — снизьте риск от злоупотребления ролями и ненадежного HTML
- Минимизируйте количество учетных записей, которые могут редактировать контент; применяйте минимальные привилегии.
- Требуйте рабочие процессы одобрения для контента, отправленного пользователями, где это возможно (проверка перед публикацией).
- Ограничьте роли, которые могут добавлять пользовательские поля или использовать плагины, которые раскрывают рендеринг пользовательских полей.
- Обучите участников о рисках встраивания HTML в поля.
- Используйте заголовки политики безопасности контента (CSP), чтобы ограничить влияние внедренных скриптов (это может снизить охват некоторых атак XSS).
- Для сайтов с большим количеством участников включите более строгую разделение ролей и рассмотрите плагины для модерации потока.
Как доверенный WAF + управляемая безопасность сокращает время на устранение проблем
Управляемый WAF и служба безопасности предоставляют:
- Быстрое виртуальное патчирование: блокируйте попытки эксплуатации немедленно, не изменяя код приложения.
- Обновления сигнатур по мере публикации исследований, чтобы правила ловили новые нагрузки.
- Инструменты сканирования и удаления вредоносного ПО для поиска и устранения внедренного контента.
- Мониторинг и оповещения, чтобы вам не приходилось следить за журналами 24/7.
- Руководство во время реагирования на инциденты и помощь в откате при необходимости.
WPFirewall сочетает эти возможности со специализированной логикой для WordPress (шаблоны запросов, REST конечные точки, конечные точки администратора), чтобы мы могли обнаруживать и смягчать атаки, нацеленные на общие векторы WordPress, такие как сохраненный XSS в метаданных.
Практические заметки по настройке WAF (уменьшение ложных срабатываний)
- Исключение доверенных IP-адресов администраторов из агрессивной блокировки может предотвратить прерывания рабочего процесса администратора — но сбалансируйте это с риском безопасности.
- Используйте правила, которые соответствуют именам параметров, обычно используемым для метаполей (meta[], postmeta, acf, пользовательские поля), вместо того чтобы блокировать все
<script>теги глобально. - Записывайте подозрительные, но не явно злонамеренные запросы (режим только оповещения) в течение определенного времени перед блокировкой — это помогает настроить сигнатуры под шаблоны использования вашего сайта.
Пример плейбука реагирования на инциденты (кратко)
- Обновите плагин до 2.4 (если возможно).
- Если немедленное обновление невозможно: включите правило виртуального патча, которое проверяет тела POST на наличие скриптов и атрибутов событий, нацеленных на параметры postmeta.
- Выполните запрос к базе данных, чтобы найти подозрительные мета-значения; экспортируйте результаты для проверки.
- Удалите подтвержденные злонамеренные записи и очистите неоднозначные.
- Сбросьте пароли для всех администраторов; обеспечьте 2FA.
- Просканируйте файловую систему на наличие измененных файлов и неизвестных PHP-файлов.
- Восстановите из чистой резервной копии, если устранение неполадок неясно.
- Мониторьте журналы на предмет повторных попыток; блокируйте нарушающие IP-адреса.
Рекомендации для разработчиков по устранению этого класса ошибок
- Всегда очищайте при сохранении и экранируйте при выводе.
- Используйте API WordPress: register_post_meta с обратными вызовами очистки, sanitize_text_field, wp_kses_post, esc_html, esc_attr.
- Используйте нонсы и проверки прав для любых операций сохранения на стороне администратора.
- Избегайте хранения необработанного HTML, если это абсолютно не необходимо; если вы это делаете, ограничьте разрешенные теги и атрибуты с помощью wp_kses.
- Сделайте безопасность частью CI/CD пайплайна: статический анализ, проверки зависимостей и обзоры безопасности перед выпуском плагинов/тем.
Как проверить, что ваш сайт больше не уязвим.
- Убедитесь, что код AddFunc Head & Footer обновлен до версии 2.4 или выше.
- Проверьте, что нет записей postmeta с
<script>или атрибутами события, которые могут быть выполнены. - Подтвердите, что фронтенд и админские страницы сайта экранируют вывод пользовательских полей.
- Проверьте журналы WAF на заблокированные попытки и убедитесь, что у вас включены ведение журнала/оповещения.
- Проведите полный скан на наличие вредоносного ПО и проверьте целостность файлов.
Начните с бесплатной защиты от WPFirewall.
Защита вашего сайта на WordPress не должна быть сложной. Если вы хотите немедленную базовую защиту, пока просматриваете обновления плагинов и очищаете подозрительный контент, рассмотрите возможность подписки на бесплатный базовый план WPFirewall. Бесплатный план включает активно управляемый брандмауэр, неограниченную пропускную способность, WAF, сканер вредоносного ПО и покрытие для рисков OWASP Top 10 — достаточно, чтобы заблокировать многие распространенные попытки эксплуатации и дать вашей команде время для безопасного применения исправлений. Попробуйте WPFirewall Basic бесплатно здесь: https://my.wp-firewall.com/buy/wp-firewall-free-plan/
(Если вы хотите автоматическое удаление вредоносного ПО и более продвинутый контроль, такой как черные списки IP, наши платные планы добавляют эти функции за скромную ежегодную плату.)
Финальные рекомендации — список приоритетных действий (короткий).
- Обновите код AddFunc Head & Footer до 2.4+ сейчас.
- Если вы не можете обновить немедленно, заблокируйте или отключите плагин и примените правила виртуального патча WAF.
- Сканируйте и удаляйте вредоносные записи пользовательских полей.
- Проведите аудит пользователей и обеспечьте соблюдение паролей/двухфакторной аутентификации для привилегированных аккаунтов.
- Укрепите санитарную обработку во время сохранения и экранирование при выводе для пользовательских полей.
- Используйте WPFirewall или управляемый WAF для получения немедленной защиты и мониторинга.
Заключительные мысли
Эта уязвимость напоминает о том, что даже казалось бы низко-привилегированные роли и небольшие плагины могут представлять значительный риск, если данные хранятся и затем отображаются без надлежащей санитарной обработки и экранирования. WordPress гибок, что является его величайшей силой — и также его наиболее частым источником риска, когда код предполагает доверие там, где его не должно быть.
Примените обновление, просканируйте и удалите подозрительные мета-значения и поставьте WAF перед вашим сайтом — не как постоянную замену безопасному коду, а как необходимый компенсирующий контроль, который дает вам время, пока вы устраняете коренную причину. Если вам нужна помощь в реализации правил WAF, виртуальном патче или очистке после инцидента, команда WPFirewall специализируется на быстрой, осведомленной о WordPress смягчающей защите.
Если вам нужен пошаговый аудит или помощь, свяжитесь с вашим поставщиком безопасности или воспользуйтесь бесплатным планом WPFirewall, чтобы получить немедленную базовую защиту, пока вы устраняете проблемы.
Будьте в безопасности и рассматривайте пользовательские поля как ненадежный ввод — очищайте, экранируйте и проверяйте.
— Команда безопасности WP-Firewall
