сервер
15 статей с этим тегом
Ядро Linux CVE-2026-98432: use-after-free в TCP, вызываемый по сети (CVSS 9.8). Установите исправленное ядро, перезагрузитесь и проверьте MPTCP
CVE-2026-98432 — use-after-free в коде IPv4 TCP ядра Linux, опубликованный 15 октября 2026 года. CNA проекта ядра оценивает его в CVSS v3.1 9.8 (сеть, без привилегий, без действий пользователя). Исследователи одной ИИ-компании, как сообщается, в лабораторных условиях и по собственному отчёту продемонстрировали удалённое выполнение кода с правами root на сервере со слушающим сокетом Multipath TCP (MPTCP). BleepingComputer пишет, что удалённое выполнение кода на обычных TCP-серверах публично не показано, а эксплуатация в реальных атаках не подтверждена; этот сайт 1 ноября не нашёл CVE в каталоге KEV от CISA. Исправления из основной ветки есть в 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 и 7.2.10 и более поздних. На 1 ноября у Debian есть исправленные ядра, у SUSE — часть, а Ubuntu и Red Hat указывают исправления как находящиеся в работе. Одного отключения MPTCP недостаточно. Вывод этого сайта: обновляйте доступные из интернета серверы Linux по мере выхода исправлений, перезагружайтесь и пользуйтесь временной мерой поставщика только до тех пор.
Что проверить после экстренного обновления PHP: веб-PHP и PHP в командной строке, set -e и коды возврата diff, а также повторная проверка на взлом
Во время реагирования в октябре 2026 года на критические уязвимости PHP на сайте, которым управляет оператор этого сайта, обновили веб-PHP, но PHP в командной строке, которым пользовался cron, по-прежнему указывал на старую версию. Проверяйте веб и CLI отдельно. При set -e утилиты diff и grep возвращают код выхода 1 для «найдены различия» или «совпадений нет», и это останавливает скрипт; коды 0, 1 и 2 нужно обрабатывать отдельно. После обновления запустите один и тот же чек-лист проверки на взлом на каждом сервере и разрешите подозрительную запись в журнале, сравнив живые файлы с эталонной копией, которая была развёрнута.
VMware ESX CVE-2026-41709 (CVSS 2.7): CISA включила уязвимость с низкой серьёзностью в журналировании в список эксплуатируемых; примените весь VMSA-2026-0006 и проверьте свои хосты
CVE-2026-41709 — уязвимость недостаточного журналирования в VMware ESX (CVSS 2.7, Low): злоумышленник, уже имеющий права администратора, может выполнять определённые операции так, что они не попадают в журналы. Broadcom исправила её в бюллетене VMSA-2026-0006 29 июля 2026 года, обходного решения нет. 28 октября 2026 года (по времени США) CISA добавила её в каталог Known Exploited Vulnerabilities (KEV) со сроком 11 ноября для федеральных агентств США. В отчёте об угрозах одной компании по безопасности сказано, что связанная с Китаем группа использовала её как zero-day в нескольких проникновениях в американские организации, вплоть до начала 2026 года, а SecurityWeek описывает цель как снижение видимости аудиторского следа; этот сайт независимо этот отчёт не проверял. Сама по себе уязвимость не даёт входа, но означает, что в журналах затронутого хоста может не быть следов действий злоумышленника. В тот же бюллетень входят две уязвимости vCenter с оценкой 9,8, одну из которых (CVE-2026-59310) CISA внесла в список эксплуатируемых 18 августа, поэтому если исправить только уязвимость ESX, точки входа останутся открытыми. Вывод этого сайта: обновите ESX и vCenter до исправленных сборок по всему бюллетеню, отправляйте журналы хостов на отдельный сервер и ищите признаки компрометации, не полагаясь только на журналы.
Fragnesia в ядре Linux (CVE-2026-46300): CISA внесла её в список эксплуатируемых со сроком 31 октября; обновите PHP и ядро, затем перезагрузитесь
CVE-2026-46300, получившая название Fragnesia, — уязвимость в ядре Linux, позволяющая локальному пользователю с низкими привилегиями получить root (CVSS v3.1 7.8, локальный вектор атаки). Когда ядро перемещает фрагменты данных между сетевыми буферами, оно может потерять метку, говорящую, что данные используются совместно с файлом в памяти, и тогда код IPsec ESP может расшифровать данные поверх кэшированной копии файла, доступного только для чтения. Проект ядра опубликовал CVE 23 мая 2026 года, а исправления есть в ядрах 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 и 7.0.10 и новее. 28 октября 2026 года (по времени США) CISA внесла её в каталог Known Exploited Vulnerabilities (KEV) на основании свидетельств активной эксплуатации, со сроком 31 октября для федеральных ведомств США. В описании CISA сказано, что её можно связать с PHP-уязвимостями CVE-2026-109618 и CVE-2026-109619, чтобы внедрить PHP-веб-шеллы и выполнять команды от имени root. Компания по безопасности сообщила, что эта цепочка использовалась против 25 серверов (в основном межсетевых экранов), а SecurityWeek повторил это сообщение; этот сайт независимо не проверял числа. Ubuntu, Red Hat и Debian выпустили исправленные ядра, а обновление ядра действует только после перезагрузки. Вывод этого сайта: если вы запускаете PHP-сайты на Linux, обновите PHP и ядро, перезагрузитесь и проверьте наличие веб-шеллов.
Уязвимость CVE-2026-110447 во встроенном сервере CODE Collabora в Nextcloud используется в атаках: кто затронут и что делать
14 октября 2026 года разработчики Collabora Online раскрыли CVE-2026-110447, неаутентифицированную уязвимость инъекции команд ОС в приложении Nextcloud Collabora Online - Built-in CODE Server (ID приложения richdocumentscode). Через proxy.php приложения команды могут выполняться от имени пользователя веб-сервера. Условие: встроенный сервер CODE не запущен, что может произойти после перезапуска контейнера, обновления или сбоя. Затронуты версии до 26.4.303; версия 26.4.303 вышла 11 сентября. Разработчики заявляют, что отключение приложения не устраняет проблему, и просят обновить или удалить его. На Nextcloud 29 и более ранних версиях обновите Nextcloud или удалите приложение. По словам разработчиков, отдельные серверы Collabora Online, Docker-образы, пакеты RPM/DEB и Nextcloud All-in-One не затронуты. Оценка CVSS v4.0 — 9.2. 23 октября CISA добавило уязвимость в каталог известных эксплуатируемых уязвимостей (KEV) со сроком до 26 октября. Пользователи сообщали об атаках примерно с 10 сентября в репозитории разработчиков, а по данным СМИ, были установлены веб-шеллы. Вывод этого сайта: если установлено встроенное приложение CODE, даже отключенное, сегодня проверьте его версию, обновите или удалите его, затем проверьте следы с 10 сентября.
GitLab CVE-2026-110264 (CVSS 10.0) и эксплуатируемая CVE-2026-97229: как проверить и обновить самостоятельно развёрнутый GitLab
21 октября 2026 года GitLab выпустил критические патч-версии 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 и 18.11.13 для Community Edition (CE) и Enterprise Edition (EE). Самая серьёзная уязвимость, CVE-2026-110264 (CVSS 10.0), представляет собой целочисленное переполнение при компиляции специально сформированного регулярного выражения, которое при определённых условиях может позволить неаутентифицированному пользователю выполнить произвольный код на сервере GitLab. Затронуты почти все версии начиная с 7.0. 29 октября CISA добавила родственную уязвимость CVE-2026-97229 (CVSS 10.0, CWE-190) в каталог известных эксплуатируемых уязвимостей (KEV) со сроком 1 ноября. Это ошибка того же рода (целочисленное переполнение в компиляторе регулярных выражений CI/CD, доступное неаутентифицированному пользователю); GitLab исправил её раньше, 12 октября, в версиях 19.4.2, 19.3.5 и 19.2.8, и затронуты только 19.2.0–19.2.7, 19.3.0–19.3.4 и 19.4.0–19.4.1. Кто всё ещё на версиях ниже 19.4.2, 19.3.5 или 19.2.8, подвержен эксплуатируемой уязвимости. Обновление до рекомендованных здесь версий (19.5.1, 19.4.3, 19.3.6, 19.2.9) исправляет и CVE-2026-97229. GitLab.com уже исправлен; самостоятельно развёрнутые установки нужно обновить. Тот же выпуск от 21 октября исправляет две уязвимости высокой степени серьёзности (CVSS 8.2 и 7.5) и другие, но эти исправления есть только в ветках 19.3.6, 19.4.3 и 19.5.1. Корень проблемы — в движке регулярных выражений Ruby (Onigmo); 23 октября Ruby выпустил 4.0.9, 3.4.12 и 3.3.13. Затронуты приложения, которые компилируют regexp из строк, контролируемых злоумышленником, а Regexp.timeout от этих ошибок не защищает. В уведомлениях GitLab не сказано, что CVE-2026-110264 эксплуатировалась, и на 30 октября её нет в KEV. Alpine Linux сообщила, что на ее собственном GitLab 20 и 21 октября была попытка атаки через CVE-2026-97229 и что одно лишь обновление GitLab (до 19.3.6) не закрыло уязвимость, потому что для исправления нужен был еще и пропатченный Ruby; она пересобрала инстанс и не нашла свидетельств того, что код злоумышленника выполнялся. Вывод этого сайта: обновите самостоятельно развёрнутый GitLab сегодня, проверив обязательные остановки, доведите установку до 19.3.6 или новее, а если вы собираете GitLab сами или используете собственный Ruby, проверьте, что и Ruby не ниже 3.3.13, 3.4.12 или 4.0.9. Ruby-приложениям нужно перейти на исправленный Ruby и перестать формировать regexp из пользовательского ввода.
Уязвимость CVE-2026-106931 в SiteGuard Server Edition используется в атаках: кого она касается и что делать
14 октября 2026 года EG Secure Solutions раскрыла CVE-2026-106931 — уязвимость внедрения команд ОС в функции статистики SiteGuard Server Edition, своего межсетевого экрана веб-приложений (WAF) уровня хоста, и сообщила, что эксплуатация уже подтверждена. Эксплуатация может позволить выполнять произвольные команды ОС с правами root или SYSTEM на сервере, где работает продукт. Затронуты версии Ver2.20 и новее с включённой функцией статистики (по умолчанию она включена): выпуски для Apache, Nginx и IIS до Ver8.00 Update5 и выпуски для FreeBSD Apache и Nginx до Ver7.00 Update6. Выпуск для IIS с Ver3.10 по Ver4.00 Update4 не затронут. Исправления — Ver8.00 Update5 и Ver7.00 Update6; для систем, которые нельзя обновить, доступен патч, в том числе для версий, снятых с поддержки. Производитель оценивает уязвимость как локальный вектор атаки с низкими требуемыми привилегиями (CVSS v3.0 7.8, v4.0 8.5). JPCERT/CC выпустил предупреждение, сообщив, что подтвердил широкое использование продукта в Японии, и что отключение функции статистики позволяет избежать проблемы. CISA добавила уязвимость в каталог известных эксплуатируемых уязвимостей (KEV) 20 октября со сроком 23 октября. Вывод этого сайта: если вы используете Server Edition, сегодня же проверьте версию и функцию статистики, сохраните диагностические данные перед обновлением, затем установите исправленную версию или патч.
[Срочно] Уязвимости PHP CVE-2026-109618 и CVE-2026-109619 уже эксплуатируются и добавлены в каталог KEV CISA. Обновите до 8.5.12, 8.4.27, 8.3.36 или 8.2.35 немедленно
21 октября 2026 года команда безопасности PHP выпустила PHP 8.5.12, 8.4.27, 8.3.36 и 8.2.35, которые устраняют две критические уязвимости, позволяющие выполнять удаленный код без аутентификации (RCE), и призвала всех пользователей немедленно обновиться. CVE-2026-109618 связана с обработкой нехватки памяти, CVE-2026-109619 связана с устаревшим внутренним состоянием, сохраняющимся между запросами; обе оценены в 9,2 по CVSS v4.0. Под угрозой находятся все установки PHP, обрабатывающие веб-запросы (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). Команда считает mod_php наиболее опасным вариантом, ссылаясь на продемонстрированный эксплойт, в котором запрос без аутентификации запускает атаку до выполнения какого-либо кода приложения. Официальных обновлений для PHP 8.1 и более старых версий не выпущено; команда предоставила минимальные бэкпорты исходного кода для 7.4, 8.0 и 8.1. Дистрибутивы Linux получили патчи заранее. Полного способа защиты нет, обновление — единственный безопасный вариант. 22 октября IPA и JPCERT/CC Японии выпустили предупреждения, а JVN опубликовала JVNVU#99905564. CISA, которая не наблюдала эксплуатацию на момент первой публикации своего предупреждения, 26 октября добавила обе уязвимости в каталог Known Exploited Vulnerabilities (KEV) и установила для федеральных гражданских ведомств США срок до 29 октября. По сообщениям СМИ, на honeypot-системах исследователя безопасности с неисправленным PHP 8.4.26 под mod_php 24 октября было зафиксировано успешное удаленное выполнение кода. Honeypot-системы крупного облачного провайдера фиксировали попытки эксплуатации начиная с 17 октября, за четыре дня до раскрытия. Насколько удалось установить этому сайту, по состоянию на 27 октября ни один взлом за пределами honeypot-систем не был обнародован. Большинство крупных японских провайдеров общего хостинга сообщили, что исправление применено, однако некоторые, например KAGOYA, этого не сделали. 23 октября команда PHP раскрыла третью проблему (CVE-2026-115560), которую выпуски от 21 октября не устраняют. Она может привести к выполнению кода только при определенном сочетании конфигурации и кода приложения; команда считает такой сценарий маловероятным на практике, исправление и полное описание выйдут со следующим регулярным релизом, а до тех пор рекомендуется установить session.upload_progress.enabled=0. Затронутые версии и оценка CVSS не опубликованы, сообщений об эксплуатации нет. По состоянию на 29 октября (проверено на php.net) исправленный релиз для этой проблемы еще не вышел. 28 октября CISA также внесла уязвимость ядра Linux CVE-2026-46300 в KEV (срок для федеральных ведомств США — 31 октября) и сообщила, что её можно использовать в цепочке с этими двумя уязвимостями, чтобы внедрять PHP-веб-шеллы и выполнять команды с правами root. Мнение этого сайта: эксплуатация теперь подтверждена, поэтому выясните, обновляете ли PHP для каждого сайта вы или ваш провайдер, и перейдите на исправленную версию сегодня. Также проверьте логи с 17 октября и далее на признаки взлома. На общем хостинге проверьте уведомление провайдера о завершении работ на его официальном сайте.
Влияет ли безопасность сайта на SEO? Уязвимости, взломанные сайты, HTTPS и позиции в поиске по официальной документации Google
Google не называет уязвимости фактором ранжирования. Ущерб появляется, когда уязвимостью воспользовались. Спам-страницы после взлома приводят к пометке «This site may be hacked» (Этот сайт может быть взломан) в результатах поиска, вредоносное ПО или фишинг вызывают в Chrome предупреждение «Dangerous site» (Опасный сайт), другие браузеры показывают свои предупреждения Safe Browsing, а сайты, нарушающие правила о спаме, могут занимать более низкие позиции или вовсе не появляться в результатах. HTTPS в 2014 году был объявлен «очень лёгким» сигналом, а нынешняя документация Google о качестве взаимодействия со страницей говорит, что, кроме Core Web Vitals, остальные его аспекты напрямую не поднимают сайт в рейтинге. Позиция этого сайта: ради SEO тратьте время на то, чтобы вас не взломали и чтобы вы быстро это заметили, если взломают, а не на повышение оценки безопасности.
Как проверить, не взломан ли ваш сайт или сервер: пошаговые проверки для виртуального хостинга, WordPress и VPS и что делать в первую очередь, если вы что-то нашли
Проверка сайта на вторжение — это внешние признаки и следы внутри. Признаки: отчёт «Security issues» (Проблемы безопасности) в Search Console, пометка «This site may be hacked» (Этот сайт может быть взломан) в поиске, уведомление от хостинга, незнакомые администраторы, перенаправления только на мобильных или только из поиска. Следы: администраторы, изменённые файлы ядра (wp core verify-checksums), история входов, authorized_keys, cron, прослушиваемые порты, недавно изменённые файлы. Позиция этого сайта: если вы ничего не нашли, это не доказывает, что всё чисто. Если нашли, сохраните улики до очистки, смените все учётные данные с чистого устройства, восстановитесь из резервной копии, сделанной до вторжения, или пересоберите сервер, закройте точку входа и только потом запрашивайте проверку.
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Всё, что в вашем webroot, любой может скачать по URL. Забытый JSON с токеном/учётными данными, .env или резервная копия означают мгновенную утечку — и если он пришёл из общего шаблона, тот же файл лежит на каждом сайте. Исправление: кладите в публичную директорию только то, чем можно публично делиться, держите секреты вне webroot с правами 600, а найдя один — проверьте каждый сайт и хост.
Инвентаризация безопасности: 7 проверок, которые упускают владельцы нескольких серверов
Для одиночек/малых операторов инциденты происходят не столько из отсутствующих мер, сколько из неотслеживаемого состояния. Граница — это ПК, хранящий ваши ключи. Расставьте приоритеты 2FA по тому, какой аккаунт может восстановить остальные (сначала почта), составьте список, какой SSH-ключ открывает какой сервер, и удалите дубликаты, неиспользуемые ключи и оставшиеся регистрации, уберите пароли открытым текстом из облака, устраняйте обратимо по одному и держите секреты вне реестра. Инвентаризация прежде добавления инструментов.
Самохостинг Git vs GitHub: что на самом деле безопаснее?
Самохостинг Git не делает вас «безопаснее» — он перемещает риск. Класс случайной публичной выставленности исчезает, но патчинг сервера, резервные копии и обнаружение секретов в pre-commit переходят на вас. Правильный выбор, если вы продолжаете выполнять эту работу; хуже GitHub, если её забрасываете. Взгляд этого сайта: самохостинг работает только в связке с компенсирующими мерами.
Наименьшие привилегии SSH-ключа: не храните root-ключи продакшена в эфемерных средах, которые можно скомпрометировать
Регистрация root-ключа в продакшене из эфемерной, компрометируемой среды (под GPU, раннер CI, одноразовая ВМ) означает, что в тот миг, когда среда скомпрометирована, атакующий получает root в продакшене. Исправление: никаких root-ключей в эфемерных средах; убирать ключи, когда не используются; если снова нужно — пользователь не root плюс ключ с ограничением команды, ограничивающий ключ одной операцией. Относитесь к переиспользуемому ключу как к самому критичному активу и никогда не стройте конфигурацию, где один утёкший ключ открывает все серверы.
Как держать .env вне публичного веба на общем хостинге
Основное исправление: тело приложения вне docroot, наружу только public/. Сначала закройте доступ через .htaccess, сделайте это постоянным реструктуризацией, затем самопроверка. Взгляд этого сайта: это не оплошность одного человека, а опасная раскладка, ставшая стандартом во всей отрасли, — чините процессом, а не бдительностью. bootstrap-redirect лучше симлинка.