🐧 В Linux обнаружена критическая уязвимость «Dirty Frag», позволяющая получить root-доступ.

Исследователь Hyunwoo Kim опубликовал детали новой LPE-уязвимости после срыва embargo. Проблема затрагивает ядра Linux начиная примерно с 2017 года и уже сопровождается публичным PoC-эксплойтом.
Источник

«Dirty Frag» — это цепочка из двух багов в подсистемах xfrm-ESP и RxRPC ядра Linux. Локальный пользователь может мгновенно повысить привилегии до root без race condition и с очень высокой вероятностью успеха. Под ударом оказались Ubuntu, Debian, Fedora, RHEL, CentOS, openSUSE и другие дистрибутивы.
Источник

Особую опасность представляет то, что:
• на момент раскрытия патчей почти не было;
• exploit уже распространяется публично;
• атака может использоваться для container escape и компрометации серверов с Kubernetes и AI-инфраструктурой.
Источник

Временная мера защиты — отключение модулей esp4, esp6 и rxrpc, если они не используются:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

Эксперты уже называют Dirty Frag наследником Dirty Pipe и Copy Fail — одной из самых опасных Linux-уязвимостей последних лет.
Источник

Hermes Agent, OpenClaw, n8n и Coolify (который мы спонсируем кстати) теперь предустановлены на is*hosting VPS от $10.19/месяц.

Hermes (вот гайд)
OpenClaw (гайд)
n8n (гайд) - от $5.94
Coolify (гайд)

Запускаются и настраиваются за несколько минут.

⚠️ Критическая уязвимость в WordPress — проверьте свой сайт

17 июля WordPress выпустил экстренные обновления 6.9.5 и 7.0.2, закрывающие уязвимость *wp2shell* — цепочку в ядре CMS, которая позволяет выполнять код на сервере *без авторизации и без единого плагина*. Уязвимы стандартные установки версий 6.9.0 – 7.0.1

Случаев эксплуатации пока не зафиксировано, но проблема настолько серьёзна, что WordPress впервые за долгое время принудительно раскатал патч даже на сайты с отключёнными автообновлениями. Обычно между таким патчем и рабочим эксплойтом проходят считанные дни — проверьте сайт сегодня.

Что сделать:

1. Админ-панель → Консоль → Обновления — убедитесь, что версия *6.9.5 / 7.0.2 или новее*
2. Автообновления отключены в wp-config.php или панели — обновитесь вручную
3. Несколько WordPress-сайтов на сервере? Проверьте *каждый*, включая тестовые и staging — они уязвимы так же, как боевой

📄 Официальный анонс WordPress

Не уверены в версии или нужна помощь с обновлением — напишите в поддержку, проверим вместе.

Нам нужно ваше мнение! Присоединяйтесь к закрытому альфа-тесту нового продукта.

Мы создаем новое продуктовое решение is*hosting Workspaces. Платформу с 100+ самых популярных self-hosted приложений для работы и экспериментов.

Вы сможете установить любое из них в 1 клик на наших серверах.

Но нам нужна ваша помощь. Перед официальным запуском мы хотим получить обратную связь от реальных пользователей — от вас.


Если вы:
• Используете наши сервисы больше года
• Работаете с инструментами аналитики и хотите держать данные у себя
• Запускаете автоматизации на своём сервере
• AI-креатор, которому нужен быстрый доступ к инструментам
• Строите техническую инфраструктуру: от баз данных до мониторинга
• Просто хотите попробовать трендовые приложения в 1 клик
• Устали настраивать всё вручную
...присоединяйтесь к альфа-тесту.


Условия:
→ Вы получаете месяц закрытого доступа к is*hosting Workspaces
→ Изучаете приложения, пробуете, экспериментируете
→ Делитесь обратной связью: что работает, что нет, чего не хватает (заполните простую форму после теста)


Взаимная выгода:
→ Мы получаем реальный опыт от людей, которым доверяем, чтобы сделать продукт лучше
→ Вы получаете участие в создании нового продукта + бесплатный период с is*hosting Workspaces после запуска + секретный бонус


Сроки:
• Приём заявок открыт, регистрация закроется в конце августа - начале сентября
• Отбор и тестирование — в сентябре 2026
• Количество мест ограничено

Если хотите присоединиться, заполните короткую форму и мы вам напишем

⚠️ В PHP две критические уязвимости (CVSS 9.2), которые могут привести к удалённому выполнению кода.

Уязвимости в самом PHP, а не в CMS или плагинах. PHP не опубликовал список уязвимых версий, поэтому считайте уязвимым любой сервер с PHP.

Релиз безопасности запланировал на сегодня, 21 октября, 14:00 UTC, но может выйти раньше.

Что сделать:
• Проверьте версию PHP на сайте. Она видна в настройках PHP в панели управления
• Сделайте бэкап
• Обновите PHP до исправленной версии своей ветки (8.2–8.5), как только она станет доступна. Затем перезапустите PHP и веб-сервер
• На PHP 8.1 или более старой версии? Запланируйте переход на поддерживаемую ветку: минимум 8.2, рекомендуем 8.4
• Это миграция, а не простое обновление пакета. Сначала проверьте совместимость CMS и плагинов на тестовой копии

Как снизить риск до обновления:
• Выставьте session.upload_progress.enabled = Off и перезапустите PHP. Мера неофициальная: утёкшая информация связывает уязвимость с этим механизмом
• Включите WAF. Поможет лишь частично: это способ выиграть время до патча, а не закрыть дыру
• Приложения на версиях, которые не получат исправление, лучше убрать из открытого доступа: за VPN или WAF

Правка php.ini — неофициальная временная мера до патча, а не замена ему.


Неподтверждённое:
• Возможно, у ИБ-компании Calif есть рабочий эксплойт.
• Джина Питер Баньярд, разработчица ядра PHP в PHP Foundation: единственная мера — патч или обновление PHP. По её словам, если можно выключить сервер на день, это, возможно, самый разумный вариант.


Анонс PHP: https://www.php.net/archive/2026.php#2026-10-20-1
Нужна помощь? Напишите нам: https://ishosting.io/ru/support

⚠️ PHP выпустил исправление

Что сделать:
• Сделайте бэкап, обновите PHP и перезапустите PHP и веб-сервер
• PHP из дистрибутива, от LTS-вендора или из панели: берите обновлённые пакеты у вендора, патчи они получили заранее
• Официальные сборки: 8.5.12, 8.4.27, 8.3.36 или 8.2.35
• rpms.remirepo.net 21 октября обновлений не получит: PHP советует перейти на пакеты дистрибутива или собрать PHP из исходников
• PHP 8.1 и более старые версии: уточните у вендора, есть ли бэкпорт, или переходите на поддерживаемую ветку (минимум 8.2, рекомендуем 8.4). До этого такие приложения лучше убрать из открытого доступа: за VPN или WAF

Контекст: CVE-2026-109618 и CVE-2026-109619 могут позволить удалённо выполнить код без аутентификации, самый высокий риск PHP видит у mod_php. Полностью защищает только обновление.

Пост PHP: https://www.php.net/archive/2026.php#2026-10-21-5
Нужна помощь? Напишите нам: https://ishosting.io/ru/support

⚠️ В ядре Linux критическая уязвимость CVE-2026-98432 (CVSS 9.8).

Удалённый злоумышленник без учётных данных может уронить необновлённый сервер через любой открытый IPv4 TCP-порт. Red Hat предупреждает, что уязвимость может привести и к удалённому выполнению кода. Anthropic описала эксплойт, который получает root на серверах с листенером Multipath TCP (MPTCP).

Затронуты Linux-серверы с ядром 4.4 и новее, то есть практически все. У VPS на KVM собственное ядро, независимое от нашего хоста: обновлять его и перезагружаться нужно внутри VPS.
Не затронуты: RHEL 7, CentOS 7, CloudLinux 7 (не гибридный), Windows, FreeBSD и другие не-Linux системы.

Реальных атак на 2 ноября не зафиксировано, но исправление публично и доступно для анализа.

Что сделать:
• Исправление вышло: Debian 12/13, RHEL 8/9/10, AlmaLinux 8, SLES 16.0, openSUSE Leap 16.0, SLES 15 SP4/SP5/SP6 LTSS, Proxmox VE. Сделайте бэкап, обновите ядро и перезагрузитесь. Новое ядро защищает только после перезагрузки
• Исправление в тестировании или раскатывается: AlmaLinux 9/10, CloudLinux 7h/8/9/10, SLES 15 SP7. Примените временную защиту и обновитесь после выхода в стабильный репозиторий
• Исправления пока нет: Ubuntu 26.10/26.04/24.04/22.04, Rocky Linux 8/9/10. Ubuntu 20.04/18.04/16.04: только через Ubuntu Pro / ESM, сроков нет. Debian 11 и старше: только платная LTS. CentOS 8 / Stream 8 и другие снятые с поддержки версии: исправления не будет, переходите на поддерживаемую версию. Примените временную защиту сейчас

Как обновить ядро:

Debian 12/13, Ubuntu (после выхода исправления), Proxmox VE:

sudo apt update && sudo apt full-upgrade
sudo reboot

RHEL 8/9/10, AlmaLinux, Rocky Linux, CloudLinux:

sudo dnf --refresh updateinfo info --cves CVE-2026-98432
sudo dnf update 'kernel*'
sudo reboot

openSUSE / SLES:

sudo zypper refresh && sudo zypper patch && sudo reboot

Временная защита:
• Отбрасывайте входящие IPv4 TCP-пакеты с IP-опциями, обычный трафик их не использует. Правило опубликовал Red Hat (RHSB-2026-016), он советует сначала проверить его на вашем трафике.

Создайте каталог:

sudo mkdir -p /etc/nftables.d

Сохраните правило в /etc/nftables.d/cve-2026-98432.nft:

table inet cve_2026_98432 {
    chain input {
        type filter hook input priority -310; policy accept;
        ip protocol tcp ip hdrlength > 5 counter drop
    }
}

Загрузите и проверьте:

sudo nft --check --file /etc/nftables.d/cve-2026-98432.nft
sudo nft --file /etc/nftables.d/cve-2026-98432.nft
sudo nft list table inet cve_2026_98432

Если сервер маршрутизирует трафик в Docker или LXC, замените хук на prerouting. Не применяйте фильтр в сетях с метками безопасности CIPSO / NetLabel

• Чтобы правило сохранилось после перезагрузки, добавьте строку include "/etc/nftables.d/cve-2026-98432.nft" в /etc/nftables.conf (Debian/Ubuntu) или /etc/sysconfig/nftables.conf (семейство RHEL) и выполните sudo systemctl enable nftables

• На системах только с iptables:

sudo iptables -t raw -I PREROUTING -p tcp -m u32 --u32 "0>>24&0x0F=6:15" -j DROP

• Отключите Multipath TCP, если он не нужен:

sudo sysctl -w net.mptcp.enabled=0
echo 'net.mptcp.enabled = 0' | sudo tee /etc/sysctl.d/99-cve-2026-98432.conf

Затем перезапускайте сервисы, которые показывает эта команда, пока её вывод не станет пустым:

sudo ss -lnMp

Это сужает атаку, но не устраняет уязвимость: ошибка не специфична для MPTCP

Временная защита снижает риск, но не заменяет обновление ядра.

Бюллетень Red Hat: https://access.redhat.com/security/vulnerabilities/RHSB-2026-016
Статус исправления для Ubuntu: https://ubuntu.com/security/CVE-2026-98432

Нужна помощь? Напишите нам: https://ishosting.io/ru/support

⚠️ Критическая уязвимость в OpenSSH на Alpine Linux: вход по SSH без пароля

Злоумышленник, у которого есть доступ к SSH-порту сервера, может войти, не зная пароля. Хватает одного подключения, атака срабатывает каждый раз. CVE на 5 ноября не присвоен.

По данным OpenSSH, уязвимы Linux-системы на musl libc, где sshd работает без PAM. Среди них Alpine Linux: затронуты версии с 3.16 по 3.24 и edge.

Сервер на Alpine уязвим, если выполнены все условия:
• sshd из пакета openssh-server (собран без PAM) или из openssh-server-pam с UsePAM no
• PasswordAuthentication yes, это значение по умолчанию
• есть аккаунт с * в поле пароля. Так по умолчанию выглядит root, а также пользователи, которые входят только по ключу
• есть хотя бы один аккаунт с паролем (хеш $5$ или `$6$`)

Root защищён настройкой по умолчанию PermitRootLogin prohibit-password, если вы не меняли её на PermitRootLogin yes. Но она не спасёт, если с другого аккаунта с доступом по SSH можно получить root, например через doas.
Официальные облачные образы Alpine (tiny-cloud) с 3.18.11 по 3.24.3: в них есть пользователь alpine без пароля и с doas без пароля. Такой сервер становится уязвимым, как только на нём появляется хеш $6$, например после установки пароля для консоли.

Не затронуты: контейнеры без sshd, системы с PasswordAuthentication no или с openssh-server-pam и UsePAM yes, облачные образы, настроенные через cloud-init (он прописывает `PasswordAuthentication no`).


Что сделать:
• Сделайте бэкап, обновите openssh и перезапустите sshd. Обновление пакета не перезапускает работающий sshd:

apk upgrade -U -a
rc-service sshd restart

Исправленные версии openssh: Alpine 3.24 10.3_p1-r2, 3.23 10.2_p1-r1, 3.22 10.0_p1-r11, 3.21 9.9_p2-r1, edge 10.6_p2-r0. Для версий с 3.16 по 3.20 исправленные пакеты тоже вышли, номера есть в бюллетене Alpine

• Если обновиться пока нельзя, отключите вход по паролю. Сначала убедитесь, что вход по SSH-ключу работает, и не закрывайте текущую сессию, пока не проверите новый вход. Выполните от root:

mkdir -p /etc/ssh/sshd_config.d
echo 'PasswordAuthentication no' > /etc/ssh/sshd_config.d/00-no-passwords.conf
sed -i.bak -e '1i PasswordAuthentication no' \
  -e 's/^\(\s*PasswordAuthentication[^y#]*\)yes/\1no/i' \
  /etc/ssh/sshd_config
sshd -t && rc-service sshd restart
sshd -T | grep -i passwordauthentication

Последняя команда должна вывести passwordauthentication no. Чтобы вернуть как было, удалите /etc/ssh/sshd_config.d/00-no-passwords.conf и скопируйте /etc/ssh/sshd_config.bak обратно в /etc/ssh/sshd_config

• Проверьте, не было ли входа. Ищите в /var/log/messages строки sshd Accepted password for для аккаунтов без пароля (root, alpine, пользователи с входом по ключу). Проверьте, кто пользовался doas, не появились ли новые пользователи, файлы и SSH-ключи в authorized_keys. Если вход исключить нельзя, считайте сервер скомпрометированным
• Другие системы на musl без PAM: обновите OpenSSH до 10.6p2


Бюллетень Alpine: https://alpinelinux.org/posts/2026-11-05-openssh-password-authentication-bypass/

Нужна помощь? Напишите нам: https://ishosting.io/ru/support

⚠️ Уязвимость в WordPress: выполнение кода на сервере во время обновления.

28 октября вышел WordPress 7.1.4. Он закрывает уязвимость в механизме обновления самого WordPress: при обновлении полным пакетом новые файлы распаковывались в предсказуемую папку, доступную извне. На этом шаге злоумышленник может без авторизации выполнить код на сервере.

3 ноября CISA добавило уязвимость (CVE-2026-119977) в каталог Known Exploited Vulnerabilities, то есть её уже используют в реальных атаках.

Затронуты версии с 4.7 по 7.1.3, если сайт ещё не обновлён до исправленной версии своей ветки.

Что сделать:
• Сделайте бэкап и обновите WordPress: «Консоль» → «Обновления» → «Обновить сейчас», или скачайте 7.1.4 с wordpress.org.
• На сайтах с автоматическими фоновыми обновлениями обновление запустится само, но проверьте, что сайт уже работает на исправленной версии
• Исправленные версии: 7.1.4 (актуальная, WordPress активно поддерживает только её), для старых веток 7.0.8, 6.9.11, 6.8.12 и так далее до 4.7.39. Полный список по второй ссылке ниже
• WordPress 4.6 и более ранние версии обновлений безопасности больше не получают.

Релиз WordPress 7.1.4: https://wordpress.org/news/2026/10/wordpress-7-1-4/
Исправленные версии для всех веток: https://wordpress.org/documentation/wordpress-version/version-7-1-4/

Нужна помощь? Напишите нам: https://ishosting.io/ru/support