6 августа 2026 года вышел WordPress 7.0.3 — security-релиз без новых фич. В анонсе 12 исправлений. Главное: pre-auth reflected XSS на экране входа (CVE-2026-64638) с потенциалом до PHP-исполнения кода. Нашёл это не «охотник в одиночку», а команда pwn.ai (автономный пентест на ИИ). CSS-инъекцию сдал Anthropic. Для владельца сайта смысл простой: обновить ядро до 7.0.3 (или до актуального патча своей ветки, когда бэкпорт дойдёт), не ждать «тихих» автоматических обновлений вслепую.
Что вышло и когда
Официальный пост: WordPress 7.0.3 release (John Blackbourn, 6 августа 2026). Рекомендация security team стандартная: обновить сайты сразу. Способы: Dashboard → Updates → Update Now, либо архив wordpress-7.0.3.zip. Сайты с auto-updates подтянут обновление сами, когда очередь дойдёт.
Вместе с 7.0.3 выкатили 7.1 RC2 с теми же применимыми фиксами. Бэкпорты security team обещает на все ветки, которые ещё получают security-фиксы (сейчас «through 4.7»), но активно поддерживается только самая свежая major. Бэкпорты идут пакетами, не «все ветки в один день».
CVE-2026-64638: XSS на login без входа
В анонсе это сформулировано так: pre-auth reflected cross-site scripting на login screen, с потенциалом до PHP code execution. Детали security team вынесла в advisory: CVE-2026-64638 / GHSA-52p2-r8wf-jcrf.
Что это значит на практике, без маркетинговых «RCE в один клик»:
- Аутентификация атакующему для XSS не нужна: цель — страница входа.
- Типичный сценарий reflected XSS: жертва (часто администратор) переходит по специально собранной ссылке или попадает на страницу, где отражается неэкранированный параметр.
- «Потенциал до PHP code execution» в контексте WordPress обычно опирается на уже открытые возможности после XSS в сессии admin: редактор тем/плагинов (если включён), установка плагинов, запись в файлы через другие привилегии. Это не автоматический shell на каждый сайт мира, а цепочка «XSS → действия от имени админа».
Разборы вроде Wordify оценивают CVE-2026-64638 как High (CVSS около 8.9) и подчёркивают user interaction: без того, чтобы человек открыл вредоносную ссылку, «сканер сам» не отрабатывает. Патч, по их описанию, сводится к корректному экранированию (esc_html, esc_url, esc_attr) в зоне login/user. Это как раз тот класс багов, который годами «вроде и знают, что надо escape», пока не прилетает CVE.
Если у вас отключён file editor, стоят 2FA, жёсткий WAF и минимальные права, цепочка после XSS короче. Если file editor включён, плагины ставятся с одного клика, а админы ходят по любой ссылке из почты — путь к «почти RCE» короче. Обновление ядра закрывает входную точку независимо от этого.
Остальные 11 пунктов: не «мелочь»
Официальный список (сжато, формулировки по анонсу WordPress.org):
- Contributor+ stored XSS в постах через emoji settings element (Asaf Mozes / amosec).
- Contributor+ stored XSS в Post Content block (n05ec).
- Contributor+ stored XSS в Quick Edit на сайтах с большим числом пользователей (Naveen S, Ajmal Moochingal).
- Contributor+ stored XSS в Post Date block (Alex Concha, WordPress Security Team).
- Privilege escalation на multisite при включённой регистрации: пользователь может создать новый сайт (Aikido Security).
- Утечка информации: Latest Comments block светил комментарии к password-protected постам (Ehtisham Siddiqui).
- Enumeration of post slugs (HDWSec).
- Disclosure of notes в comment feeds (Elio Gubser).
- Author+ CSS injection через обход safe CSS attribute filter (Anthropic).
- Bypass email address confirmation flow (0ways).
- SSRF в URL validation: запросы в link-local ranges (Andrew Mohawk и несколько независимых репортеров).
Для мультисайта с открытой регистрацией escalation «создать сайт» — не теоретический пункт. Для блогов с Contributor/Author XSS в блоках контента и Quick Edit — классика «контент-менеджер → XSS в админке редактора». SSRF в URL validation бьёт по серверной стороне: исходящие запросы туда, куда ядру ходить не следовало.
ИИ находит баги в ядре: pwn.ai и Anthropic
В благодарностях security team прямо указаны pwn.ai (pre-auth XSS на login) и Anthropic (CSS injection). Это не «ИИ написал эксплойт в Twitter», а ответственное disclosure в релизном цикле WordPress.
Тренд уже не новость: автономные и агентные инструменты ускоряют поиск банальных, но опасных ошибок экранирования, фильтров CSS, edge cases в REST и URL. WordPress ведёт программу через HackerOne; объём репортов растёт, и часть находок приходит уже не только от людей с ручным Fuzzing, а от пайплайнов. Конкретные цифры вроде «N репортов в месяц» лучше сверять с актуальными публичными метриками HackerOne/программы WordPress на дату чтения. Важно другое: security-релизы будут чаще, окна «поживу на 7.0.0 полгода» — короче.
Что сделать на рабочих сайтах
1. Узнать текущую версию
В админке: Dashboard → Updates. С CLI:
wp core version wp core check-update
2. Бэкап, потом обновление
Security-релиз обычно «лёгкий», но на проде без бэкапа файлов и БД обновлять не стоит: плагины, кастом, object cache, mu-plugins. После бэкапа:
wp core update --version=7.0.3 wp core update-db wp core version
Если сидите не на 7.0.x, а на более старой major, которая ещё получает security-бэкпорты, цель — не «любой 7.0.3», а последний патч вашей ветки, когда бэкпорт выйдет. До его появления либо планируйте upgrade ветки, либо следите за анонсами security team.
3. Проверить, что обновление реально легло
После auto-update иногда «вроде обновилось», а версия в version.php или через wp core version осталась старой (права, диск, таймаут, половина файлов). Сверьте:
wp core verify-checksums wp core version
И откройте фронт + /wp-admin/: критичные плагины (кеш, security, page builder) не должны сыпать fatals. Сбросьте page cache / CDN cache после обновления.
4. Снизить ценность XSS, даже после патча
- Отключить редактор файлов тем/плагинов (
DISALLOW_FILE_EDIT), если он не нужен. - 2FA для администраторов.
- Не раздавать роль Administrator «всем своим».
- Ограничить доступ к /wp-login.php и /wp-admin/ по IP или через HTTP auth на edge, если бизнес-процесс позволяет.
- Плагины и темы из доверенных источников, без «nulled».
Это не замена обновлению 7.0.3, а уменьшение ущерба, если следующий XSS снова окажется pre-auth или stored от Contributor.
Где обычно ломается обновление
- Нехватка прав на запись в корень сайта: обновление оборвалось на половине файлов.
- Object cache / opcode cache отдаёт старый код: кажется, что версия новая, поведение старое.
- Жёсткая «заморозка» версии в deploy-пайплайне: Dashboard пишет 7.0.3, а CI на следующем деплое откатывает ядро.
- Мультисайт: обновление сети vs обновление одного сайта, разные права super-admin.
- Кастомные must-use плагины, которые лезут в login flow и конфликтуют с патчем (реже, но бывает).
Как проверить, что вы не на уязвимой 7.0.x
Цель для ветки 7.0: не ниже 7.0.3. Для других веток — ждать/ставить security-бэкпорт или перейти на поддерживаемую major. После обновления:
wp core version # ожидаемо: 7.0.3 (или новее на вашей ветке)
В логах веб-сервера и WAF имеет смысл смотреть всплески запросов к wp-login.php с длинными query-string (типичный след reflected XSS-кампаний), но отсутствие таких логов не значит «нас не пытались». Патч закрывает дыру независимо от логов.
Вывод
WordPress 7.0.3 — не «косметика». 12 security-фиксов, из них pre-auth XSS на login (CVE-2026-64638) с заявленным потенциалом эскалации до PHP RCE через цепочку привилегий. Находки pwn.ai и Anthropic в одном релизе показывают, что агенты и ИИ-инструменты уже в контуре responsible disclosure ядра. На практике: бэкап → 7.0.3 (или актуальный security-патч ветки) → verify-checksums → сброс кеша → по возможности DISALLOW_FILE_EDIT и 2FA. Остальное — процесс, а не разовый подвиг.
