Уязвимости Minecraft серверов в 2026: разбор CVE и защита

Minecraft сервер, как и любая сетевая Java-программа, время от времени получает уязвимости. Некоторые из них мелкие и требуют нестандартных условий для эксплуатации. Другие в своё время парализовали весь сегмент индустрии. Админу важно не столько помнить наизусть номера CVE, сколько понимать классы уязвимостей и знать, как быстро проверить свой сервер на типовые проблемы.

В этой статье разберём основные классы уязвимостей, которые актуальны для Minecraft серверов в 2026 году. Покажем, как узнать, защищён ли ваш сервер, и что делать если в логах появились подозрительные записи. Без инструкций по эксплуатации - только защита.

Про формат статьи

Уязвимости в Minecraft серверах публикуются не только через классические CVE, но и через GitHub Security Advisories (GHSA) - это особенно частый формат у Paper и Velocity. Мы будем называть CVE там где они точно есть, и говорить о классе/адвизоре там где номер не имеет смысла.

Никаких конкретных payload-строк, команд эксплуатации или PoC-кода в статье не будет. Только описание класса атаки, версии где проблема закрыта, и способы самостоятельно проверить свой сервер.

Класс 1: Удалённое выполнение кода через логи (Log4Shell)

Самая известная уязвимость Minecraft-экосистемы. Зарегистрирована как CVE-2021-44228.

Что случилось. В декабре 2021 года обнаружили, что библиотека Apache Log4j 2.x, которую использует Minecraft для логирования, позволяет подставлять выражения в сообщения. Одно из выражений заставляло Log4j скачать и выполнить Java-класс с удалённого сервера. Любая строка, попавшая в лог, могла стать вектором атаки. А в логи Minecraft попадает буквально всё: сообщения чата, ники, команды, имена предметов.

Масштаб. Задело вообще всех: ванильные серверы, Paper, Spigot, BungeeCord, клиенты, launcher'ы. Mojang выпустил срочный патч 1.18.1 и hotfix-JAR для всех поддерживаемых версий. Paper и другие форки опубликовали свои обновления в тот же день.

Статус в 2026. Уязвимость полностью закрыта во всех актуальных версиях. Log4j версий 2.17.0+ проблемой не подвержен. Но осторожность нужна: если вы держите старый сервер на версии 1.17.x или 1.18.0 без патча - вы до сих пор уязвимы.

Как проверить ваш сервер.

# Узнать версию Log4j в server.jar
unzip -p server.jar META-INF/maven/org.apache.logging.log4j/log4j-core/pom.properties
# или найти файл log4j-core
find . -name "log4j-core*.jar"

Если видите версию ниже 2.17.0 - срочно обновляйтесь. Для Paper/Purpur/Folia просто скачайте последний билд под вашу версию MC. Для ванильного сервера - замените на актуальный jar с minecraft.net.

Как заметить попытку эксплуатации. В логах появляются аномально длинные сообщения с необычными символами в скобках (обычно в чатах, никнеймах, табах предметов). Паттерн: что-то похожее на URL или команду в фигурных скобках со знаком доллара. Любое такое сообщение - красный флаг.

Класс 2: Packet DoS - краш сервера через специальный пакет

Большой класс уязвимостей, где один специально сформированный Minecraft-пакет заставляет сервер либо зависнуть, либо потратить неадекватное количество ресурсов. Обычно закрываются через Paper Security Advisories (GHSA-номера), реже через CVE.

Что случалось. В разные годы Paper закрывал уязвимости такого типа: разбивка chunk-пакетов вызывала утечку памяти, аномальные entity spawn-пакеты роняли сервер, определённые комбинации inventory-действий приводили к зацикливанию. Публикации обычно идут через GitHub у PaperMC с детальным описанием какая версия затронута.

Почему это сложно защищать. Каждый новый класс пакетов-эксплойтов требует отдельного фикса. Ванильный сервер от Mojang исторически не валидирует пакеты так же строго, как Paper. Поэтому для продакшена всегда рекомендуем именно Paper или Purpur, а не ванильный jar.

Статус в 2026. Paper выпускает обновления регулярно - часто в тот же день, когда появляется уязвимость. Главная защита - держать сервер на актуальном билде.

Как проверить свою установку.

# В консоли сервера
version

# На Paper увидите что-то вроде
# This server is running Paper version git-Paper-xxx (MC: 1.21.4) (Implementing API version 1.21.4-R0.1-SNAPSHOT)

Зайдите в раздел Paper Downloads и сравните номер билда. Если ваш старше на несколько версий - пора обновляться. Paper держит совместимость API, обновление обычно проходит без проблем.

Как заметить попытку эксплуатации. Паттерны в логах:

• IOException: Invalid packet ID
• Packet too large: X bytes
• необычные стектрейсы в latest.log от NetworkManager или ServerGamePacketListenerImpl
• резкие скачки heap использования без видимой игровой причины

Включите watchdog с low early-warning (в paper-global.yml), чтобы при зависании сервер сам писал в лог полный thread dump.

Класс 3: Обход forwarding в прокси (BungeeCord legacy class)

Если у вас прокси-сеть на BungeeCord или Velocity, нужно понимать класс уязвимостей, связанных с передачей информации о клиенте на backend.

Что случалось. Классический BungeeCord по умолчанию передавал информацию о клиенте (IP, UUID, имя) на backend-сервер через специальное расширение handshake-пакета. Проблема в том, что backend никак не верифицировал подлинность этой информации. Если кто-то мог подключиться к backend-серверу напрямую (minуя прокси), он мог подделать любой UUID и попасть на сервер от имени произвольного игрока - включая администратора.

Эта особенность не всегда имеет CVE-номер, потому что формально это не баг, а конструктивное решение ранней BungeeCord. Но её эксплуатация - полноценная уязвимость класса "authentication bypass".

Статус в 2026. Современное решение - forwarding через "modern secret":

• Velocity использует signed forwarding: прокси подписывает данные о клиенте HMAC-ключом, известным только прокси и backend. Поддельная информация не пройдёт проверку
• BungeeCord + SpigotGuard / подобные тоже предлагают подписанный форвардинг
• Paper умеет проверять Velocity modern secret из коробки

Как проверить свою настройку.

# В config.yml Velocity
player-info-forwarding-mode: "modern"
forwarding-secret-file: "forwarding.secret"

# В paper-global.yml на backend
proxies:
  velocity:
    enabled: true
    online-mode: true
    secret: "...содержимое forwarding.secret..."

Если у вас до сих пор legacy forwarding - это риск. Подробнее о миграции - в статье про архитектуру proxy-сетей.

Главное правило. Backend-серверы никогда не должны быть доступны из публичного интернета напрямую. Только proxy. Закройте firewall'ом внешний доступ на порты backend-серверов:

# Разрешить только IP прокси
iptables -A INPUT -p tcp --dport 25566 -s PROXY_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 25566 -j DROP

Класс 4: Oversized NBT и переполнение ресурсов

NBT (Named Binary Tag) - формат данных, который Minecraft использует для всего: предметов, книг, сущностей, структур. NBT может быть вложенным и потенциально очень большим.

Что случалось. Периодически находили способы создать предмет с аномально большим NBT-деревом: книга с очень многими страницами, шалкер-коробка с тысячами вложенных предметов, карточки с миллионами точек данных. Передача такого предмета в inventory-пакете вызывала либо очень долгую сериализацию (лаги), либо полное зависание сервера на OutOfMemoryError.

Статус в 2026. Paper добавил настраиваемые лимиты для основных типов NBT-payload'ов. Они включаются в paper-global.yml:

item-validation:
  max-bytes: 128000
  book:
    title-max-length: 16
    author-max-length: 16
    page-max: 50
    max-book-page-size: 2560
  resolve-selectors-in-books: false
  book-size:
    page-max: 2560
    total-multiplier: 0.98

Эти лимиты работают только если вы на актуальном Paper. Ванильный сервер по-прежнему уязвим.

Как проверить.

# Убедитесь что item-validation включён и лимиты разумные
# Значения выше "мягкие" - подходят для большинства серверов
# Для серверов с кастомными предметами (skyblock, RPG) можно поднять max-bytes

Как заметить эксплуатацию. В логах:

• OutOfMemoryError на main-thread
• аномальный размер playerdata/*.dat файлов (игроки могут протащить предмет в инвентарь)
• Packet rejected: item NBT too large

Если видите в playerdata файлы размером в сотни MB - это явный признак проблемы.

Класс 5: Pterodactyl и админ-панели

Отдельный класс уязвимостей - в панелях управления, которые стоят перед сервером (Pterodactyl, Crafty, Pelican, MCSManager). Большинство админов Minecraft их используют, и многие забывают их обновлять.

Что случалось. За несколько лет в Pterodactyl находили уязвимости позволяющие:

• выполнить код на хосте через уязвимость в обработке файлов (CVE в pterodactyl/panel были в 2021-2023 годах)
• обойти двухфакторную аутентификацию
• получить доступ к файлам других клиентов на общем хостинге
• выполнить команды в контейнере от имени root через некорректную обработку SFTP

Статус в 2026. Pterodactyl активно патчится, но не все хостеры и админы обновляют свои инсталляции. Если вы хостите сервер на собственной Pterodactyl-панели - вы полностью отвечаете за её безопасность.

Что делать.

1. Держите Pterodactyl на актуальной версии. Подробный гайд - в статье по Pterodactyl security
2. Включите двухфакторную аутентификацию для всех админов
3. Не выкладывайте панель в публичный интернет без Cloudflare или WAF
4. Мониторьте логи Wings (демона Pterodactyl) на подозрительные SFTP-соединения

Класс 6: Уязвимости плагинов

Самый массовый класс в 2026. Плагины часто пишут любители, код публикуется на SpigotMC без серьёзного код-ревью, и в них регулярно находят дыры.

Что случалось.

• SQL-инъекции в старых версиях AuthMe, CMI, Essentials через поле никнейма или команду /register
• Path traversal в плагинах, которые обрабатывают имена файлов (скины, кастомные ресурс-паки)
• Десериализация небезопасных YAML в плагинах, которые принимают пользовательский ввод
• Log4Shell-подобные уязвимости в плагинах, которые используют свой собственный логгер
• Удалённое выполнение через RCON-like команды в некоторых плагинах с недостаточной проверкой прав

Статус в 2026. Невозможно гарантировать безопасность, если вы ставите случайные плагины. Общие правила:

1. Ставьте только плагины с активной разработкой (последние коммиты не старше года)
2. Проверяйте рейтинг и отзывы на SpigotMC / Modrinth
3. Не ставьте плагины из сомнительных Telegram-каналов или "взломанные" (cracked) премиум-плагины - в них регулярно находят бэкдоры
4. Держите актуальные версии - включайте в плагинах автообновление где это безопасно

Подробнее про обязательные плагины и их безопасность - в статье про security plugins 2026 и must-have plugins.

Класс 7: Query/RCON порты

Последний класс - не совсем про packet exploits, но тесно связан. Minecraft имеет два дополнительных протокола: Query (UDP) и RCON (TCP). Оба часто оставляют открытыми по невнимательности.

Query. Позволяет любому в интернете узнать игроков на сервере, MOTD, список плагинов. Публично доступный query-порт часто используется для amplification-атак: атакующий шлёт query-пакет с поддельным source IP, сервер отвечает жертве. И ещё - это даёт атакующему полный список плагинов, который он потом использует для подбора известных уязвимостей.

# server.properties - отключить query если не нужен
enable-query=false

RCON. Удалённая консоль. Если пароль слабый или оставлен по умолчанию, атакующий может выполнять команды на сервере от имени оператора, включая /op для любого игрока.

# server.properties - либо отключить, либо поставить сложный пароль
enable-rcon=false
# или
rcon.password=ДлинныйСлучайныйПарольНеИзСловаря
# и ограничить доступ firewall'ом только с доверенных IP

Подробнее - в статье про whitelist vs online mode и анализ логов.

Базовый чек-лист hardening 2026

Минимум, который нужен всем серверам. Если здесь у вас что-то не закрыто - это потенциальный вектор.

Обновления

• Paper/Purpur/Folia на актуальном стабильном билде под вашу MC-версию
• Log4j версии 2.17.0+ (обычно автоматически с Paper, но проверить стоит)
• Все плагины обновлены
• Java на актуальной LTS-версии (Java 21 для MC 1.21+)

Конфигурация сервера

• item-validation в paper-global.yml включён с разумными лимитами
• watchdog включён с early-warning-delay: 10000
• enable-query=false если query не нужен
• enable-rcon=false или сложный пароль + firewall на RCON-порт
• online-mode=true для премиум-сервера

Сеть и прокси

• Backend-серверы закрыты от прямого доступа из интернета
• Velocity/BungeeCord использует modern secret forwarding
• Firewall настроен (подробнее - firewall iptables guide)
• DDoS-фильтр понимает Minecraft протокол (L7)

Мониторинг

• Логи архивируются и доступны для анализа
• Настроены алерты на аномалии (подробнее - monitoring attacks)
• Регулярный бэкап мира и конфигов (подробнее - backup strategy)

Админ-доступ

• 2FA на Pterodactyl/панели (подробнее - two-factor auth)
• SSH на сервер только по ключу, не по паролю
• Операторы (OP-list) только проверенные люди
• Регулярный аудит ops.json

Как получать информацию о новых уязвимостях

Хороший админ не ждёт пока его сервер сломают. Источники информации:

• PaperMC GitHub Security Advisories - github.com/PaperMC/Paper/security/advisories
• Velocity GitHub Advisories - аналогично для Velocity прокси
• Twitter/X #minecraft exploit - сообщество часто первым публикует находки
• Discord-сервера крупных хостингов и MineGuard - там часто идёт обсуждение, если что-то горит
• CVE.org - поиск по ключевому слову "minecraft"
• NVD (National Vulnerability Database) - официальный источник по CVE

Что делать при подозрении на взлом

Если подозреваете что сервер эксплуатировали:

1. Снимите полный снапшот. Мир, конфиги, логи, playerdata. Если окажется что атака была успешной - это ваш материал для восстановления
2. Проверьте ops.json. Не появились ли неожиданные операторы
3. Проверьте логи на подозрительные команды. Особенно op, deop, изменения прав
4. Проверьте файлы мира. Нет ли команд в command_blocks, аномальных структур
5. Остановите сервер и обновите всё. Minecraft, Paper, плагины, Java, OS
6. Смените пароли. RCON, панели управления, SSH
7. Если подтвердилась компрометация - разверните сервер с нуля. Атакующий мог спрятать backdoor в мире, плагине или даже jar-файле

Итог

Уязвимости Minecraft серверов в 2026 году делятся на несколько основных классов: RCE через логирование, packet DoS, обход forwarding в прокси, переполнения через NBT, уязвимости в плагинах и панелях. Для каждого класса существует понятный путь защиты:

• держать Paper и плагины в актуальных версиях
• использовать modern secret forwarding
• закрывать backend от публичного доступа
• включать item-validation и watchdog
• мониторить логи на аномалии
• поднимать сетевую защиту через фильтр, понимающий Minecraft протокол

MineGuard покрывает именно сетевой слой: отсекает malformed пакеты на уровне ядра, фильтрует volumetric атаки через XDP/eBPF и детектит bot-join трафик по поведенческим признакам (подробнее - bot-join детекция 2026). Но серверное hardening - всё равно задача администратора. Эта статья даёт базовый чек-лист.

Если нужна помощь с настройкой защиты или разбором подозрительной активности - наша поддержка готова помочь разобраться в конкретном случае.