Уязвимость плагина Яндекс.Метрики для WordPress: разбор CVE-2025-63063 и безопасная альтернатива
2026
Введение
7 декабря 2025 года в официальном плагине Яндекс.Метрики для WordPress была обнаружена уязвимость, затронувшая более 60 000 сайтов по всему миру. Уязвимость получила идентификатор CVE-2025-63063 и была классифицирована как «Broken Access Control» — нарушение контроля доступа.
Особенность ситуации в том, что речь идёт об официальном плагине от крупной компании, а не о каком-то заброшенном поделии неизвестного разработчика. При этом Яндекс так и не выпустил исправление спустя несколько месяцев после публикации CVE.
Эта статья поможет разобраться: что именно произошло, насколько это опасно, и — самое важное — как защитить свой сайт без потери функциональности аналитики.
Часть 1. Что такое CVE и как работает система уязвимостей
CVE — Common Vulnerabilities and Exposures
CVE — это международная база данных, в которой каждой обнаруженной уязвимости присваивается уникальный номер. Система поддерживается организацией MITRE при поддержке правительства США и используется как стандарт во всей индустрии безопасности.
Номер CVE состоит из трёх частей:
CVE - 2025 - 63063
↑ ↑ ↑
Префикс Год Порядковый номер
Когда исследователь безопасности находит уязвимость, он:
- Описывает её и сообщает разработчику (ответственное раскрытие)
- Ждёт, пока выйдет патч (обычно 90 дней)
- Публикует информацию в базе CVE
CVSS — система оценки серьёзности
Каждой уязвимости присваивается числовая оценка от 0 до 10 по шкале CVSS (Common Vulnerability Scoring System):
| Оценка | Уровень | Пример |
|---|---|---|
| 9.0–10.0 | 🔴 Критический | Удалённое выполнение кода без авторизации |
| 7.0–8.9 | 🟠 Высокий | SQL-инъекция с доступом к данным |
| 4.0–6.9 | 🟡 Средний | Нарушение контроля доступа |
| 0.1–3.9 | 🟢 Низкий | Раскрытие незначительной информации |
CVE-2025-63063 получила оценку 5.3 — средний уровень.
Часть 2. Анатомия уязвимости CVE-2025-63063
Затронутый продукт
- Плагин: Yandex.Metrica (wp-yandex-metrika)
- Разработчик: Яндекс
- Затронутые версии: все, вплоть до 1.2.2 включительно
- Активных установок: 60 000+
- Исправление: отсутствует
Тип уязвимости: Broken Access Control
«Broken Access Control» (нарушение контроля доступа) — один из самых распространённых классов уязвимостей в веб-приложениях. Он входит в топ-1 списка OWASP Top 10 — авторитетного рейтинга критических угроз для веб-приложений.
Суть простая: приложение не проверяет, кто именно делает запрос, прежде чем его выполнить.
Как это работает в WordPress
WordPress использует систему AJAX-обработчиков для выполнения действий на сервере без перезагрузки страницы. Каждый обработчик регистрируется примерно так:
// Правильная регистрация — с проверкой прав
add_action('wp_ajax_my_action', 'my_handler'); // только для залогиненных
add_action('wp_ajax_nopriv_my_action', 'my_handler'); // для всех, включая гостей
Если разработчик добавляет действие через wp_ajax_nopriv_ без намерения открывать его всем, или регистрирует обработчик, не проверяя права внутри функции — возникает уязвимость.
Правильный обработчик должен выглядеть так:
function my_secure_handler() {
// 1. Проверка nonce (одноразовый токен против CSRF)
check_ajax_referer('my_nonce_action', 'nonce');
// 2. Проверка прав пользователя
if (!current_user_can('manage_options')) {
wp_die('Access denied', 403);
}
// 3. Только теперь выполняем действие
// ...
}
В плагине Яндекс.Метрики одна или несколько функций пропускали проверку авторизации. Это значит, что любой посетитель сайта — даже не зарегистрированный — мог отправить специально сформированный запрос и выполнить действие, которое должно быть доступно только администратору.
Что мог сделать злоумышленник
Поскольку технические детали эксплойта не раскрыты публично (стандартная практика при отсутствии патча), точный сценарий неизвестен. Однако исходя из класса уязвимости и функциональности плагина, вероятные последствия:
Вероятно возможно:
- Просмотр настроек плагина (ID счётчика Метрики)
- Изменение ID счётчика — подмена аналитики на чужой счётчик
- Сброс или изменение конфигурации плагина
Невозможно при CVSS 5.3:
- Захват административного доступа к сайту
- Чтение паролей или личных данных пользователей
- Загрузка вредоносных файлов на сервер
- Выполнение произвольного кода (это был бы критический уровень 9+)
Почему Wordfence показывает «Критический»
Пользователи Wordfence видят красную плашку «Критический» и пугаются. Важно понимать: это внутренняя UX-классификация Wordfence, означающая «требует немедленного внимания», а не официальная оценка серьёзности уязвимости. CVSS-оценка остаётся 5.3 — средний уровень.
Часть 3. Почему плагин опасен вдвойне
Проблема отсутствия патча
Уязвимость была опубликована 7 декабря 2025 года. Прошло несколько месяцев — Яндекс так и не выпустил исправление.
Это тревожный сигнал по нескольким причинам:
- Все версии уязвимы. Нет «безопасной» версии, на которую можно обновиться.
- Автоматические обновления не помогут. Даже если у вас включено автообновление плагинов, нового безопасного релиза просто нет.
- Это говорит о состоянии поддержки. Крупная компания, игнорирующая CVE несколько месяцев, либо забросила поддержку плагина, либо не считает безопасность приоритетом.
Публичная информация привлекает атаки
Как только CVE публикуется в открытых базах данных, автоматизированные сканеры злоумышленников начинают массово проверять сайты на наличие уязвимого плагина. Это происходит в течение дней, иногда часов после публикации.
Именно поэтому даже «средняя» уязвимость без патча опаснее «высокой» с патчем: в первом случае у вас нет способа закрыть дыру стандартными средствами.
Часть 4. Неправильные и правильные способы решения
❌ Неправильно: просто деактивировать плагин
Деактивированный плагин всё ещё находится на сервере. Его файлы доступны по прямому URL. В некоторых случаях AJAX-обработчики WordPress могут срабатывать даже для деактивированных плагинов. Деактивация — не решение.
❌ Неправильно: ждать патча
Если патча нет несколько месяцев — ждать его бессмысленно. Нужно действовать сейчас.
❌ Неправильно: нажать «Игнорировать» в Wordfence
Это просто скроет предупреждение из интерфейса. Уязвимость никуда не денется.
✅ Правильно: удалить плагин и перенести функциональность
Яндекс.Метрика — это просто JavaScript-код. Плагин делал ровно одно: вставлял этот JS на каждую страницу. Мы можем сделать то же самое без плагина, напрямую через WordPress.
Часть 5. Решение: Must-Use Plugin
Что такое Must-Use Plugins
WordPress имеет специальную директорию wp-content/mu-plugins/. Файлы в этой папке:
- Загружаются автоматически при каждом запросе WordPress
- Не могут быть деактивированы через панель администратора (нет кнопки «Деактивировать»)
- Не зависят от активной темы — работают даже при смене темы
- Отображаются в разделе «Must-Use» в списке плагинов (только для информации)
- Не сбрасываются при обновлении WordPress или темы
Это идеальное место для критически важного кода, который должен работать всегда.
Почему не functions.php
Добавление кода в functions.php темы — популярный совет, но у него есть недостаток: при обновлении темы файл functions.php перезаписывается. Если вы не используете дочернюю тему, ваш код будет удалён. Must-Use Plugin лишён этого недостатка.
Реализация
Создайте файл /wp-content/mu-plugins/yandex-metrika.php со следующим содержимым:
<?php
/**
* Plugin Name: Yandex Metrika Counter
* Description: Яндекс.Метрика без плагина и без уязвимостей.
* Version: 1.0
*/
// Защита от прямого обращения к файлу
if ( ! defined( 'ABSPATH' ) ) exit;
function msb_yandex_metrika() {
// Не вставлять скрипт в админке
if ( is_admin() ) return;
?>
<!-- Yandex.Metrika counter -->
<script type="text/javascript">
(function(m,e,t,r,i,k,a){
m[i]=m[i]||function(){(m[i].a=m[i].a||[]).push(arguments)};
m[i].l=1*new Date();
for (var j = 0; j < document.scripts.length; j++) {
if (document.scripts[j].src === r) { return; }
}
k=e.createElement(t),a=e.getElementsByTagName(t)[0],
k.async=1,k.src=r,a.parentNode.insertBefore(k,a)
})(window, document, 'script',
'https://mc.yandex.ru/metrika/tag.js?id=ВАШИ_ID', 'ym');
ym(ВАШИ_ID, 'init', {
webvisor: true,
clickmap: true,
accurateTrackBounce: true,
trackLinks: true
});
</script>
<noscript>
<div>
<img src="https://mc.yandex.ru/watch/ВАШИ_ID"
style="position:absolute; left:-9999px;" alt="" />
</div>
</noscript>
<!-- /Yandex.Metrika counter -->
<?php
}
// Приоритет 1 — вставляем в самое начало <head>
add_action( 'wp_head', 'msb_yandex_metrika', 1 );Замените ВАШИ_ID на числовой идентификатор вашего счётчика из кабинета Яндекс.Метрики.
Разбор кода
if ( ! defined( 'ABSPATH' ) ) exit; Защита от прямого обращения к PHP-файлу через браузер. Если файл запрашивается напрямую (не через WordPress), ABSPATH не определена — скрипт завершается.
if ( is_admin() ) return; Счётчик не нужен в административной панели. Эта проверка исключает лишнюю загрузку JS при работе в wp-admin.
add_action( 'wp_head', 'msb_yandex_metrika', 1 ); Хук wp_head срабатывает при генерации тега <head> на каждой странице. Приоритет 1 означает, что наш код выполнится одним из первых — это хорошая практика для счётчиков аналитики.
Часть 6. Как это работает с кешированием
Многие WordPress-сайты используют плагины кеширования (WP Fastest Cache, W3 Total Cache, WP Super Cache и другие). Важно понимать, как счётчик взаимодействует с кешем.
Схема работы
Первый запрос к странице:
PHP запускается → mu-plugin вставляет скрипт Метрики в HTML →
WordPress отдаёт готовый HTML → плагин кеша сохраняет HTML на диск
Все последующие запросы:
nginx/Apache отдаёт HTML прямо с диска (PHP не запускается) →
В HTML уже есть код счётчика →
Браузер загружает tag.js с серверов Яндекса →
Счётчик срабатывает ✓
Ключевой момент: скрипт Метрики встраивается в HTML ещё до кеширования. Поэтому кешированные страницы уже содержат код счётчика — всё работает корректно.
Опасные настройки кеша
Единственная потенциальная проблема — функции Minify JS и Combine JS (минификация и объединение JavaScript-файлов). Если они включены, плагин кеша может попытаться «оптимизировать» встроенный код счётчика.
Рекомендация: если используете минификацию JS, добавьте домен mc.yandex.ru в список исключений в настройках плагина кеша.
Часть 7. Сравнение подходов
| Параметр | Плагин wp-yandex-metrika | Код в functions.php | Must-Use Plugin |
|---|---|---|---|
| Безопасность | ❌ CVE-2025-63063 | ✅ Нет уязвимостей | ✅ Нет уязвимостей |
| Выживает при обновлении темы | — | ❌ Нет | ✅ Да |
| Выживает при смене темы | — | ❌ Нет | ✅ Да |
| Можно случайно отключить | ⚠️ Да | — | ✅ Нет |
| Нагрузка на PHP | Выше | Средняя | Минимальная |
| Видно в админке | ✅ Да | ❌ Нет | ✅ Да (раздел Must-Use) |
| Требует технических знаний | ❌ Нет | ⚠️ Минимально | ⚠️ Минимально |
Часть 8. Общие уроки по безопасности WordPress-плагинов
Урок 1: Официальный ≠ Безопасный
Плагин от крупной компании не гарантирует безопасности. Яндекс — огромная организация, но её плагин имеет уязвимость и несколько месяцев без патча. Всегда проверяйте репутацию и историю обновлений плагина.
Урок 2: Количество плагинов = площадь атаки
Каждый установленный плагин — это потенциальная точка входа для атаки. Принцип: если функцию можно реализовать без плагина — реализуйте без плагина.
Особенно это касается простых задач: вставка счётчиков аналитики, добавление мета-тегов, редиректы — всё это делается парой строк кода в mu-plugins или functions.php.
Урок 3: Мониторинг уязвимостей обязателен
Установите Wordfence или аналог и настройте уведомления по email. Реагировать на уязвимости нужно в течение дней, не месяцев.
Полезные ресурсы для мониторинга:
- WPScan Vulnerability Database — wpscan.com/plugins
- Patchstack — patchstack.com/database
- Wordfence Intelligence — wordfence.com/threat-intel
Урок 4: Отсутствие патча = время деактивировать
Если прошло более 2–4 недель с момента публикации CVE, а патча нет — не ждите. Либо найдите альтернативу, либо реализуйте функциональность самостоятельно.
Урок 5: Периодически аудируйте список плагинов
Раз в несколько месяцев проходитесь по списку установленных плагинов и задавайте себе вопросы:
- Этот плагин ещё нужен?
- Когда последнее обновление? Если более года — плагин может быть заброшен.
- Можно ли заменить его кодом?
Заключение
CVE-2025-63063 в плагине Яндекс.Метрики — хороший пример того, что угроза безопасности может прийти откуда не ждёшь: от официального плагина крупного вендора, который к тому же не торопится её устранять.
Правильная реакция на такую ситуацию состоит из трёх шагов:
- Удалить уязвимый плагин (не деактивировать, а именно удалить)
- Восстановить функциональность безопасным способом — в данном случае через Must-Use Plugin
- Задокументировать изменения, чтобы не забыть что и почему было сделано
Хорошая новость: в данном конкретном случае решение занимает буквально 10 минут и не требует никаких специальных знаний. А сайт после этого становится чуть более защищённым и чуть более быстрым — плагин больше не создаёт накладных расходов при каждом запросе.