Коллеги, добрый день!
На сегодняшний день ситуация стабилизировалась. Экстренная фаза завершена, и мы переходим к детальному разбору произошедшего. Хотим рассказать о дальнейших шагах.

Полное раскрытие технических деталей сейчас преждевременно. Стабилизация ситуации не означает, что все процедуры завершены: публичные каналы доступны не только нашим клиентам, и детали, раскрытые до завершения всех необходимых мероприятий, могут создать дополнительные риски.

В течение нескольких дней мы официально опубликуем результаты расследования инцидента. Мы расскажем, что представляла собой уязвимость, как она эксплуатировалась и какие меры мы приняли.

Что можно сказать уже сейчас: инцидент связан с уязвимостью в одной из сборок VMmanager 6. Обновления безопасности выпущены, а следующие дополнительно повысят устойчивость продукта к подобным уязвимостям. Рекомендации по закрытию контура опубликованы и при необходимости дополняются. Техническая поддержка работает в усиленном режиме и помогает с каждой конкретной инсталляцией.

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

Национальный координационный центр / ЦМУ ССОП (Роскомнадзор) уведомил о критических уязвимостях в интерпретаторе PHP — CVE-2026-109618 и CVE-2026-109619 (CVSS 9.2, удалённое выполнение кода). Уязвимы практически все версии PHP, начиная с 5.4.

Если на вашем сервере/VPS используется PHP, необходимо в кратчайший срок:

• 1. Обновить PHP до исправленной версии: 8.5.12, 8.4.27, 8.3.36 или 8.2.35 (либо пакет дистрибутива с исправлением). Версии 8.1 и старше больше не поддерживаются — требуется переход на 8.2+.
• 2. Если обновить сразу невозможно — временно установить в php.ini (для PHP-FPM/Apache) параметр:
• session.upload_progress.enabled = Off
• и перезапустить PHP-FPM/веб-сервер.
• 3. Ограничить доступ к административным панелям (Bitrix, WordPress, phpMyAdmin и т.п.) доверенными IP-адресами.
• 4. Проверить сервер на признаки взлома: неизвестные .php-файлы, подозрительные процессы и исходящие соединения.

Важно: взломанные ресурсы, используемые для атак, могут быть заблокированы ЦМУ ССОП на уровне сети.

Если сервер обслуживается нашими специалистами или вам нужна помощь с обновлением — ответьте на это письмо.

С уважением, FirstVDS

Ранее мы сообщали в письме о двух критических уязвимостях в ядре PHP — CVE-2026-109618 и CVE-2026-109619.

Также ранее выпустили патчи к актуальным версиям PHP: 8.2.35-1781

• 8.3.36-1781
• 8.4.27-1781
• 8.5.12-1781

Сообщаем, что, кроме этого, выпустили сборки, которые исправляют уязвимости в устаревших версиях PHP:

• 5.4.45-1794
• 5.5.38-1794
• 5.6.40-1786
• 7.0.33-1786
• 7.1.33-1786
• 7.2.34-1786
• 7.3.33-1786
• 7.4.33-1782
• 8.0.30-1782
• 8.1.34-1782

Выпустили «нативные» PHP с поддержкой модуля лимитирования для Alma 9/10:

• 8.0.30-8.el9.alma.1.857351
• 8.3.36-1.el10.857351

Через панель ispmanager

• Для установки обновленных версий PHP через панель, выполните следующие шаги:
• Перейдите в раздел Конфигурация ПО
• Выберите пункт Обновить
• Выберите пункт Обновить список доступного ПО, а затем пункт Обновить ПО
• Нажмите Обновить
• Дождитесь окончания обновления и перейдите в раздел Службы

Выберите следующие службы:

• Перезапустите службы, нажав на Перезапустить службу в меню над списком.

Фактические версии PHP и их значение в панели могут отличаться сразу после обновления — чтобы устранить несоответствие, перезагрузите сервер или перезапустите панель:

/usr/local/mgr5/sbin/mgrctl -m ispmgr -R

Вручную через пакетный менеджер
Обновить PHP можно вручную через системный пакетный менеджер:
Debian-based системы
Обновите все пакеты isp-php, выполнив команды:

apt update
apt install --only-upgrade $(dpkg-query -W -f='${Package}\n' 'isp-php*' php 2>/dev/null)

Перезапустите службы Apache и PHP-FPM, выполнив команды:

systemctl restart apache2 'apache2-isp@*' 
systemctl restart 'php*fpm*'

RHEL-based системы
Обновите все пакеты isp-php, выполнив команды:

dnf clean metadata
dnf update 'isp-php*' php

Перезапустите службы Apache и PHP-FPM, выполнив команды:

systemctl restart httpd 'httpd-isp@*'
systemctl restart 'php*fpm*'

В ядре интерпретатора PHP обнаружены две критические уязвимости (9,2/10 баллов по CVSS 4.0) с идентификаторами CVE-2026-109618 и CVE-2026-109619. Общее название — PHP2Shell.

Эксплуатация уязвимости может привести к удаленному выполнению произвольного кода (RCE), несанкционированному доступу к информации, нарушению функционирования системы, а также использованию вашего сервера в проведении компьютерных атак.

Уязвимостям подвержены все версии PHP, ниже 8.2.35, 8.3.36, 8.4.27, 8.5.12. В том числе сайты, приложения и популярные CMS на базе PHP, среди которых — WordPress, Drupal, OpenCart, 1С-Битрикс, а также фреймворки вроде Laravel. Уязвим сам интерпретатор PHP, поэтому обновление любого из перечисленных приложений проблему не решает.

Появилась информация о первых попытках эксплуатации уязвимости. Эксплойт показан в действии на веб-серверах с WordPress, MediaWiki, phpBB, Magento, Joomla, Laravel, Symfony, Drupal и WHMCS.

Разработчики PHP опубликовали параметры конфигурации, которые снижают риски отдельных сценариев эксплуатации. Однако обновление — единственное решение для закрытия уязвимости.
www.php.net/archive/2026.php#2026-10-21-5

Что нужно сделать
1. Обновите версию PHP. Уязвимость устранена в сборках 8.2.35, 8.3.36, 8.4.27, 8.5.12. Дефекты не могут быть устранены средствами прикладного кода — исправление возможно только путем обновления PHP на сервере. Компенсирующие меры помогают только от некоторых векторов атак.
2. Перезапустите сервисы: PHP-FPM или веб-сервер, обработчики очередей и Apache с mod_php, чтобы в памяти не остался старый код.
3. Проверьте установленную версию с помощью команд php -v и php-fpm-<ВЕРСИЯ> -v.
4. Проверьте систему на признаки взлома. После обновления убедитесь в отсутствии посторонних файлов, изучите журналы событий и, при необходимости, смените пароли, ключи и токены.

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

Команда Selectel.

На текущий момент создание бакетов S3 хранилища закрыто во всех пулах.

Мы будем открывать возможность создания бакетов по мере появления достаточного объёма ресурсов в пулах.

https://selectel.ru

Как вы, вероятно, уже слышали из СМИ, в PHP были обнаружены две критические уязвимости. Разработчики PHP выпустили обновления безопасности для устранения этих проблем. Данные обновления призваны предотвратить выполнение злоумышленниками вредоносного кода в затронутых системах при определенных условиях.

Поскольку вы используете выделенный сервер и/или облачный сервер, вы самостоятельно несете ответственность за установку обновлений безопасности. Если вы используете PHP, мы настоятельно рекомендуем как можно скорее установить доступные обновления безопасности на соответствующие системы: www.php.net/archive/2026.php#2026-10-21-5

Кроме того, внимательно следите за своими системами на предмет подозрительной активности и возможных признаков атаки.

Дополнительную информацию и актуальные сведения можно найти на нашем сайте о состоянии сервисов: status.hetzner.com/incident/f4144d55-38c3-48d1-8664-7a3429355cd7

Благодарим вас за сотрудничество.
С уважением,
Hetzner Online

13 октября 2026
DDoS, боты и BGP-инциденты в 3 квартале 2026 года: статистика и тренды

curator.pro/library/blog/ddos-boty-i-bgp-incidenty-v-3-kvartale-2026-goda-statistika-i-trendy/

15 июля 2026
DDoS, боты и BGP-инциденты во 2 квартале 2026 года: статистика и тренды

curator.pro/library/blog/ddos-boty-i-bgp-incidenty-vo-2-kvartale-2026-goda-statistika-i-trendy/

21 апреля 2026
DDoS, боты и BGP-инциденты в 1 квартале 2026 года: статистика и тренды

curator.pro/library/blog/ddos-boty-i-bgp-incidenty-v-1-kvartale-2026-goda-statistika-i-trendy/#preobladaiushhie-vektory-ddos-atak-v-1-kv-2026-goda

14 января 2026
DDoS, боты и BGP-инциденты в 2025 году: статистика и тренды

curator.pro/library/blog/ddos-boty-i-bgp-incidenty-v-2025-godu-statistika-i-trendy/

05 декабря 2025
Исследование устойчивости национальных сегментов Интернета в 2024 году

curator.pro/library/blog/resilience-of-national-internet-segments-in-2024/

17 октября 2025
DDoS, боты и BGP-инциденты в 3 квартале 2025 года: статистика и тренды

curator.pro/library/blog/ddos-boty-i-bgp-incidenty-v-3-kvartale-2025-goda-s/

10 июля 2025
DDoS, боты и BGP-инциденты во 2 квартале 2025 года: статистика и тренды

curator.pro/library/blog/ddos-boty-i-bgp-incidenty-vo-2-kvartale-2025-goda/

21 апреля 2025
DDoS-атаки, боты и BGP-инциденты в 1 квартале 2025 года: статистика и тренды

curator.pro/library/blog/ddos-ataki-boty-i-bgp-incidenty-v-1-kvartale-2025/

26 мая 2026 Компания Qrator Labs представляет поддержку единого входа (SSO) для централизованного управления доступом
Компания Qrator Labs добавила поддержку единого входа (SSO) в свою панель управления, что позволяет клиентам интегрировать платформу с существующими корпоративными системами управления идентификацией и доступом (IAM).
Реализация поддерживает федерацию идентификации через OAuth 2.0 и OpenID Connect (OIDC), позволяя организациям аутентифицировать пользователей через внешних поставщиков идентификации вместо управления отдельными учетными данными внутри самой платформы. Поддерживаемые поставщики включают Keycloak, Okta, Microsoft Entra ID, Google Workspace и другие решения, совместимые с этими стандартами.
Благодаря включенной функции единого входа (SSO) организации могут использовать существующую инфраструктуру аутентификации для управления доступом к панели управления Qrator Labs без создания отдельных учетных записей пользователей. Платформа также поддерживает сопоставление внешних групп пользователей с внутренними группами панели управления, что позволяет администраторам централизованно управлять разрешениями пользователей с помощью существующих процессов управления идентификацией и доступом (IAM).

24 марта 2026 Компания Qrator Labs успешно отразила DDoS-атаку мощностью более 2 Тбит/с, направленную на кипрскую платформу для онлайн-игр, на фоне всплеска подобных инцидентов в регионе
В то время как комиссар по связи подтверждает недавнюю волну DDoS-атак, затронувших организации на Кипре в середине марта, компания Qrator Labs отразила масштабный UDP-флуд, направленный на кипрскую платформу для онлайн-игр. Пиковая нагрузка атаки превысила 2 Тбит/с, и, что необычно для такого типа атак, интенсивный трафик сохранялся более 40 минут.
В общей сложности во время инцидента было зафиксировано 11 всплесков трафика, четыре из которых превысили 1 Тбит/с, что указывает на устойчивый и многоэтапный характер атаки, а не на единичный кратковременный всплеск. Атака также выделялась по скорости передачи пакетов, достигнув почти 1 миллиарда пакетов в секунду в пиковый период.


26 ноября 2025 Компания Qrator Labs вошла в число претендентов на звание лидера в области защиты веб-приложений и API в рамках программы KuppingerCole Leadership Compass 2025
Компания Qrator Labs, глобальный поставщик решений в области сетевой безопасности и фильтрации трафика, сегодня объявила о том, что она была признана «претендентом» в недавно опубликованном отчете KuppingerCole Leadership Compass: Web Application and API Protection (WAAP) 2025. В отчете оценивались возможности 12 международных поставщиков в области защиты веб-приложений и API от современных угроз.
KuppingerCole Analysts AG — независимая европейская исследовательская и консультационная фирма, основанная в 2004 году в Германии, специализирующаяся на кибербезопасности, управлении идентификацией и цифровых рисках. Ее программа Leadership Compass представляет собой серию сравнительных исследовательских отчетов, оценивающих поставщиков технологий в конкретных сегментах кибербезопасности, анализируя функциональность продуктов, инновации и присутствие на рынке.
В отчете «Leadership Compass for Web Application and API Protection 2025» представлен обзор рынка WAAP и содержится информация, помогающая организациям определить решения, наилучшим образом отвечающие их потребностям. В нем рассматриваются интегрированные возможности обеспечения безопасности и соответствия требованиям, предназначенные для защиты облачных приложений на протяжении всего жизненного цикла разработки и производства, а также оценивается, насколько эффективно каждый поставщик позволяет организациям отслеживать, оценивать и управлять рисками для своих веб-приложений и API.
Включение Qrator Labs в раздел «Претенденты» отражает прочную технологическую основу компании и ее растущую роль на глобальном рынке WAAP. В отчете KuppingerCole выделяет ряд сильных сторон Qrator Labs, включая глубокую экспертизу в области защиты от DDoS-атак, надежные фундаментальные основы WAAP, эффективное использование ИИ для улучшения управления ботами и операционную надежность, поддерживаемую развитой глобальной инфраструктурой. Аналитики также подчеркивают сильные позиции компании на региональных рынках и хорошо развитую партнерскую экосистему.

24 апреля 2025 geevo и Qrator Labs сотрудничают в области кибербезопасности
Соглашение о сотрудничестве между Qrator Labs и geevo охватывает широкий спектр решений и возможностей, доступных теперь как существующим, так и новым клиентам. Это новое сотрудничество позволит еще больше расширить возможности в области кибербезопасности, предоставляемые всем потенциальным клиентам через geevo и Qrator Labs, при этом geevo® будет представлять интересы Qrator Labs на Кипре, в Греции и на Мальте.

18 апреля 2025 Компания Qrator Labs предотвратила крупнейшую DDoS-атаку 2025 года, потенциально связанную с историческим рекордом НХЛ
3 апреля Qrator Labs зафиксировала самую мощную DDoS-атаку в 2025 году. Атака, направленная на организацию в сегменте онлайн-ставок, достигла пиковой скорости в 965 Гбит/с — чуть меньше 1 Тбит/с.
Время инцидента убедительно указывает на связь с исторической вехой в НХЛ: 3 апреля Александр Овечкин из «Вашингтон Кэпиталз» забил свой 892-й гол, 5 апреля сравнялся с давним рекордом Уэйна Гретцки (894 гола), а 6 апреля превзошел его, забив свой 895-й гол. Эксперты Qrator Labs считают, что значимость этого события, вероятно, спровоцировала DDoS-атаку.
Рассматриваемый инцидент длился приблизительно 90 минут и развивался волнообразно. Он начался в 11:15 с интенсивностью 67 Гбит/с, резко возрос до 217 Гбит/с к 11:23, достиг пика в 965 Гбит/с в 11:36 и снизился до 549 Гбит/с к 12:41, после чего вскоре завершился.
Это была многовекторная DDoS-атака, пиковая интенсивность которой достигала 965 Гбит/с для UDP-флуда, 229 Гбит/с для SYN-флуда, 214 Гбит/с для IP-флуда и 169 Гбит/с для TCP-флуда.
Ранее Qrator Labs уже отмечала аналогичные всплески DDoS-атак на индустрию онлайн-ставок во время крупных спортивных событий. В частности, значительное увеличение объема атак было зафиксировано во время Чемпионата Европы по футболу 2024 года.

15 октября 2024 Ожидается, что в связи с новой европейской директивой кипрские компании усилят свою кибербезопасность
Кипрские предприятия усиливают меры кибербезопасности в связи с вступлением в силу Директивы ЕС NIS 2 (Сетевая и информационная безопасность) во всех 27 европейских государствах 18 октября 2024 года. Новая директива направлена ​​на повышение киберустойчивости в более широком спектре отраслей, вводя более строгие требования к управлению рисками и ускорение процесса отчетности об инцидентах в условиях роста числа кибератак по всему миру.
Директива NIS 2 обновляет первоначальное законодательство 2016 года, которое было сосредоточено на защите критической инфраструктуры, такой как энергетический, медицинский и финансовый секторы. Однако сфера действия NIS 2 расширяется, охватывая больше отраслей, и обеспечивает соблюдение гармонизированных стандартов кибербезопасности по всему ЕС. Директива вводит более жесткие санкции за несоблюдение требований и делает акцент на безопасности цепочек поставок и улучшенном обмене информацией между государствами-членами ЕС.
Эта директива появляется в нужное время, поскольку число кибер-инцидентов в мире растет. Кипр не является исключением, отмечает Андрей Лескин, технический директор Qrator Labs, ведущего поставщика услуг по смягчению последствий кибератак. Почти половина местных компаний подверглась кибератакам в 2023 году, при этом половина фирм понесла убытки в среднем в размере 27 000 евро. Среди наиболее распространенных типов атак — DDoS-атаки, которые часто нацелены на финансовые, электронные коммерческие, IT- и телекоммуникационные компании и очень распространены на Кипре. Согласно последнему отчету Qrator Labs, именно эти компании столкнулись с наибольшим количеством DDoS-атак уровня L3-L4 (сетевое затопление) во втором квартале 2024 года.
В связи с ростом угроз компания недавно стала членом крупнейшей некоммерческой IT-ассоциации «The TechIsland» на Кипре, которая стремится превратить страну в центр технологий и инноваций. Qrator Labs теперь является активным членом ассоциации, что означает высокую вовлеченность в ее деятельность и планы по оказанию помощи местным предприятиям в повышении их устойчивости к киберугрозам и соблюдении нового европейского законодательства.

qrator.net

8 октября 2026 года в инфраструктуре Curator произошел сбой, который привел к полной недоступности всей сети фильтрации и защищаемых ресурсов клиентов. Инцидент продолжался 38 минут — с 15:32 до 16:10 UTC+3.

Причиной сбоя стало некорректное правило межсетевого экранирования, примененное во время релиза CControl. Из-за автоматической синхронизации конфигурации правило было применено на всех узлах, что в конечном итоге привело к недоступности всей сети фильтрации.

В этом посте подробно разберем, как развивался инцидент, почему изменение одного правила межсетевого экранирования привело к таким серьезным последствиям и что мы меняем в инфраструктуре и внутренних процессах, чтобы предотвратить повторение подобных сбоев.

Архитектура сети фильтрации Curator
Чтобы корневые причины инцидента были более понятны, сперва нам придется поговорить о нескольких важных особенностях архитектуры сети фильтрации Curator. Каждая из наших площадок состоит из нескольких узлов фильтрации, которые через высокопроизводительный коммутатор подключены к вышестоящим операторам.

Каждый узел подключен к коммутатору и взаимодействует с ним через два логически разделенных контекста маршрутизации — VRF external и VRF internal. В каждом из них устанавливается отдельная BGP-сессия для обмена маршрутной информацией.

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

Коммутатор, в свою очередь, поддерживает BGP-сессии с вышестоящим оператором и клиентами, подключенными по BGP.


Также каждый узел и коммутатор подключены к OOB-маршрутизатору, через который осуществляется независимый доступ к сети управления.

На каждом узле работает межсетевой экран внутренней разработки Curator, обеспечивающий обработку сетевого трафика непосредственно на уровне ядра Linux и использующий собственный синтаксис правил. Этот firewall оптимизирован для обработки экстремально больших объемов сетевого трафика, что необходимо для эффективной работы сети фильтрации.



Также на каждом узле работает watchdog — система проверки активности, которая для оценки состояния узла в том числе отслеживает обмен маршрутной информацией через BGP-сессии между узлом и коммутатором.

Наконец, для централизованного управления конфигурацией в сети Curator используется система распространения конфигурации СControl. Она позволяет быстро и согласованно применять изменения на всех узлах распределенной сети фильтрации. Через эту систему распространяются как пользовательские настройки, например параметры защиты отдельных ресурсов, так и инфраструктурные настройки Curator.



Механика инцидента
8 октября в 15:22 UTC+3 во время очередного релиза СControl — системы централизованного управления и распространения конфигураций — в конфигурацию межсетевого экранирования попало некорректное запрещающее правило.

На тот момент релизы СControl выполнялись в рамках стандартной процедуры и не требовали выделенного окна обслуживания. Архитектура системы предусматривала автоматическую синхронизацию конфигураций между всеми узлами фильтрации.



В 15:30 это правило начало распространяться на узлы фильтрации через систему распространения конфигураций. В результате ошибочное правило затронуло интерфейс узлов фильтрации, через который трафик от узла фильтрации поступает к коммутатору (VRF internal), и заблокировало BGP (TCP/179), что привело к разрыву BGP-сессий между узлами фильтрации и коммутаторами.

При этом BGP-сессии между коммутаторами и вышестоящими операторами, а также клиентами, подключенными по BGP, оставались установленными.

Разрыв одной из BGP-сессий на узле фильтрации был воспринят системой проверки активности как признак сбоя, из-за чего узел автоматически выводился из ротации. Поскольку конфигурация была применена одновременно на всех узлах, этот сценарий повторился на всех фильтрующих узлах.

В результате в 15:32 UTC+3 из ротации были выведены все узлы фильтрации, что привело к полному прекращению обслуживания трафика на всех фильтрующих площадках и недоступности префиксов, анонсируемых через автономную систему Curator.



Восстановление работы
После определения причины сбоя мы приступили к откату изменений. Обычно восстановление предыдущей конфигурации занимает не более 3–5 минут. Однако в данном случае особенности состояния системы распространения конфигурации после релиза потребовали дополнительных действий для восстановления согласованности компонентов.

В результате вместо стандартного быстрого отката нам потребовалось выполнить последовательную процедуру восстановления, после которой стало возможным вернуть предыдущие правила межсетевого экранирования. Общее время восстановления составило около 38 минут.

Хронология инцидента

• 15:22 — выполнение очередного релиза CControl.
• 15:30 — синхронизация конфигурации на узлах фильтрации.
• 15:31 — прекращение обработки маршрутной информации, полученной через BGP-сессии с клиентами, подключенными по BGP.
• 15:32 — прекращение передачи маршрутной информации в сторону вышестоящих операторов.
• 15:40 — откат изменений, внесенных релизом.
• 16:02 — восстановление анонсов в сторону вышестоящих операторов связи и доступности ресурсов клиентов, подключенных через публичный интернет.
• 16:10 — восстановление доступности ресурсов клиентов, подключенных через BGP.
• 16:10 — полное восстановление работы сети фильтрации Curator.

Действия Curator по предотвращению повторения инцидента
Мы приносим извинения всем клиентам, которых затронул сбой 8 октября. Мы понимаем, насколько критична доступность защищаемых нами ресурсов, и работаем над тем, чтобы предотвратить повторение подобных инцидентов.

По итогам инцидента мы определили ряд необходимых изменений в архитектуре отдельных компонентов инфраструктуры и процедурах внесения изменений, которые могут повлиять на работу сети фильтрации.

В первую очередь мы планируем архитектурно разделить управление инфраструктурными компонентами и управление конфигурациями сети фильтрации. Это позволит снизить зависимость между системами, обеспечивающими работоспособность инфраструктуры, и компонентами, непосредственно участвующими в обслуживании клиентского трафика.

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

Для таких изменений будут предусмотрены дополнительные этапы технической проверки и отдельная процедура внедрения, учитывающая потенциальное влияние на работоспособность всей сети.

Непосредственной причиной сбоя 8 октября стала человеческая ошибка, однако наша задача — выстроить инфраструктуру и процессы таким образом, чтобы единичная ошибка не могла привести к подобным последствиям. Именно на это направлены перечисленные выше изменения.

Разработчики PHP сообщили о двух критических уязвимостях с уровнем опасности 9,2 из 10. Они представляют серьёзную угрозу для сайтов и сервисов, использующих PHP, вне зависимости от используемого хостинг-провайдера.

Официальное раскрытие разработчиками PHP подробностей и выпуск исправлений запланированы на 21 октября, 17:00 по московскому времени.

Виртуальный хостинг и выделенные серверы под нашим администрированием
Безопасность ваших сайтов — наш приоритет. Поэтому мы уже сейчас принимаем превентивные меры, опираясь на доступную информацию об уязвимостях.

В частности:

• Ограничиваем работу механизма upload_progress в PHP.
• Планируем временно ограничить обработку POST-запросов типа multipart/form-data, которые обычно используются для загрузки файлов на сервер.

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

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

Наши рекомендации для владельцев облачных серверов
Если вы самостоятельно администрируете облачный сервер (VPS/VDS), рекомендуем дополнительно принять следующие меры безопасности:

• Обновите PHP до версии 8.2 или новее, предварительно убедившись в совместимости ваших сайтов и приложений.
• Временно ограничьте потенциально уязвимые механизмы PHP. Рекомендуем отключить session.upload_progress и по возможности ограничить обработку POST-запросов типа multipart/form-data, используемых для загрузки файлов. Перед применением ограничений учитывайте, что они могут повлиять на работу форм и других функций ваших сайтов.
• Установите официальные исправления безопасности сразу после их выхода. Следите за обновлениями PHP и своевременно применяйте патчи для используемой версии.

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

Как эти ограничения могут повлиять на сайты
Временно могут возникать проблемы с загрузкой файлов через сайты, работой отдельных форм и другими функциями, использующими соответствующие механизмы PHP.

Ограничения распространяются на виртуальный хостинг Beget и выделенные серверы под нашим администрированием.

Все ограничения носят временный характер. После выхода официальных исправлений мы в приоритетном порядке обновим поддерживаемые версии PHP и снимем ограничения, когда это станет безопасно.

Временные ограничения доступа к панелям управления облачными базами данных
В качестве дополнительной меры безопасности мы временно закрыли доступ к портам 80 и 443 для облачных баз данных. В связи с этим веб-интерфейсы управления базами данных Adminer (PostgreSQL) и phpMyAdmin (MySQL) будут временно недоступны.

Ограничение носит превентивный характер и будет снято после устранения угрозы безопасности.

Как обновить версию PHP
1. Виртуальный хостинг

• Авторизуйтесь в панели управления Beget.
• Перейдите в раздел «Сайты» → «Управление сайтами».
• Найдите нужный домен и нажмите на значок шестерёнки справа от него.
• В открывшихся настройках выберите версию PHP 8.2 или новее.
• Примените изменения и дождитесь обновления. Обычно это занимает до 10 минут.
• Проверьте работу сайта, включая формы, плагины и основные функции.
• Если у вас несколько сайтов, проверьте версию PHP для каждого домена и поддомена отдельно.

Подробная инструкция: Как обновить PHP на виртуальном хостинге Beget.
beget.com/ru/news/2026/php-8-5-chto-novogo

2. Облачные серверы (VPS/VDS)
На облачных серверах Beget способ обновления PHP зависит от установленного программного обеспечения и панели управления.

Если используется ispmanager:

• Авторизуйтесь в панели управления ispmanager вашего сервера.
• Перейдите в раздел «Сайты».
• Выберите нужный сайт и нажмите «Изменить параметры сайта».
• В настройках PHP выберите версию 8.2 или новее. Если нужная версия отсутствует, предварительно установите её через инструменты управления PHP в ispmanager.
• Сохраните изменения и проверьте работу сайта.

Если используется FASTPANEL:

• Авторизуйтесь в панели FASTPANEL.
• Перейдите в раздел «Настройки» → «Приложения» и установите нужную версию PHP, если она ещё не установлена.
• Откройте карточку нужного сайта и перейдите в его настройки.
• Выберите новую версию PHP и сохраните изменения.
• Проверьте корректность работы сайта.

Если сервер настроен самостоятельно, без панели управления:
Обновление PHP выполняется через операционную систему сервера или используемую систему контейнеризации. Перед обновлением рекомендуем создать резервную копию, проверить совместимость приложения и уточнить порядок обновления для вашей конфигурации.

Обратите внимание: Владельцы проектов на VPS несут самостоятельную ответственность за обновление PHP.

Важно для всех услуг: переход на PHP 8.2 или новее сам по себе не гарантирует устранение уязвимости. Необходимо также установить официальное исправление безопасности после его выхода. Если ваш сайт несовместим с новой версией PHP, рекомендуем обратиться к разработчику сайта или CMS для адаптации.

Что будет дальше
Мы внимательно следим за ситуацией и готовимся к оперативной установке обновлений сразу после их публикации.

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

Подробнее об уязвимости: habr.com/ru/news/1097016/

Спасибо за понимание!