Телеграм

is*hosting

@ishosting Кибербезопасность и приватность
РКН: проверяем Не иноагент
Канал компании is*hosting
https://ishosting.com

Статистика обновлена 14.11.2026 в 20:09 · 2 просмотра страницы · Хотите больше просмотров?

Подписчики6 579
Охват поста4 095 62% от подписчиков
ERR за месяц62,24%
ERR за 24 часа36,15%

Динамика за 30 дней

Рекламные публикации

Рекламных публикаций не найденоЗа последнее время мы не нашли на площадке ни одного рекламного поста.

Последние публикации

Все посты канала →
is*hosting tg6.6 тыс. подписчиков
Открыть пост ↗
⚠️ Уязвимость в 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
👁 2.4 тыс. ❤ 7🤬 5👍 3 ↻ 37 6 ноября
is*hosting tg6.6 тыс. подписчиков
Открыть пост ↗
⚠️ Критическая уязвимость в 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
👁 2.9 тыс. 🤯 23❤ 4😱 4 ↻ 77 5 ноября
is*hosting tg6.6 тыс. подписчиков
Открыть пост ↗
⚠️ В ядре 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
👁 4.4 тыс. 🤯 26👍 13❤ 3 ↻ 205 2 ноября