Ранее мы сообщали в письме о двух критических уязвимостях в ядре 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/

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

21 октября 2026 года в PHP были исправлены уязвимости CVE-2026-109618 и CVE-2026-109619. Обе уязвимости имеют рейтинг CVSS v4.0 9.2 и могут допускать несанкционированное удаленное выполнение кода.

К числу затронутых сред относятся PHP-FPM, Apache mod_php, php-cgi, FrankenPHP и LiteSpeed. Наибольший риск существует для Apache mod_php

Версии PHP и наличие исправлений
Последние официальные релизы PHP, содержащие исправления, следующие:

Для более старых веток, перечисленных ниже, команда PHP предоставила исходный код через GitHub без предоставления предварительно собранных пакетов. aaPanel занимается упаковкой этих исправленных сборок.

Это исправленные сборки, предоставленные aaPanel, и их не следует путать с новыми официальными релизами от разработчиков.

Доступность может варьироваться в зависимости от вашего магазина приложений aaPanel. Пожалуйста, обновите список приложений, чтобы проверить наличие обновлений.

Версии PHP младше 7.4
Компания aaPanel планирует завтра опубликовать обновленные рекомендации по настройке для версий PHP младше 7.4. Правила WAF также будут обновлены для блокировки подобных атак.

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

Как обновить PHP в aaPanel

• Создавайте резервные копии своих веб-сайтов, баз данных и конфигураций.
• Откройте App Store > Установлено.
• При необходимости нажмите «Обновить список приложений», чтобы обновить список доступных версий.
• При наличии обновлений обновите все используемые версии PHP до соответствующих исправленных версий или сборок, предоставляемых aaPanel.
• Перезапустите затронутые службы PHP и убедитесь, что ваши веб-сайты работают должным образом.
• Для пользователей PHP 8.0: исправленная сборка aaPanel всё ещё находится на стадии тестирования. Пожалуйста, следите за обновлениями на официальном форуме, чтобы узнать о статусе её выпуска.

Проблема с обновлением OpenLiteSpeed ​​LSPHP
Из-за проблемы совместимости скрипта с OpenLiteSpeed, текущий скрипт aaPanel поддерживает установку LSPHP, но не его обновление.

На данный момент обновите существующие установки LSPHP с помощью системного менеджера пакетов.
CentOS / AlmaLinux / Rocky Linux

yum update 'lsphp*' -y

Debian / Ubuntu

apt-get update
apt-get install --only-upgrade 'lsphp*' -y

После обновления перезапустите затронутые службы и убедитесь, что ваши веб-сайты работают корректно.

Временные меры по смягчению последствий
Приведенные ниже настройки касаются только конкретных путей атаки для уязвимости CVE-2026-109619. Они не устраняют обе уязвимости и не заменяют обновления безопасности.

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

Для каждой затронутой версии PHP откройте «Настройки» > «Конфигурационный файл» (php.ini) и установите следующие параметры:

session.upload_progress.enabled = 0

Для PHP 8.5 также установите:

fatal_error_backtraces = 0

После сохранения изменений перезапустите все затронутые PHP-процессы.
Эти настройки должны вступить в силу до обработки запроса. Не полагайтесь на файлы ini_set()PHP-FPM .user.iniдля применения этих мер защиты.

Обновления безопасности Node.js
В Node.js исправлено 10 уязвимостей, в том числе четыре серьезные проблемы.

Обновите систему до одной из следующих исправленных версий:

• 22.23.4
• 24.22.1
• 26.12.1

Как обновить Node.js в aaPanel

• Откройте веб-сайт > Проект Node.js > Менеджер версий Node.js.
• Обновите список версий.
• Установите исправленную версию, подходящую для ваших проектов.
• Переключите каждый проект на обновленную версию Node.js.
• Перезапустите каждый проект и убедитесь, что он работает корректно.

Установка новой версии Node.js сама по себе не обновляет существующие проекты. Каждый проект необходимо переключить на новую версию и перезапустить.

Дальнейшие обновления
aaPanel продолжит отслеживать эти проблемы безопасности и предоставлять обновления по тестированию PHP 8.0, рекомендации по настройке для более старых версий PHP и изменениям правил WAF.

PHP выпустил серьёзные обновления безопасности для активных версий PHP 8.2, 8.3, 8.4, 8.5 community.centminmod.com/threads/php-8-5-12-8-4-27-8-3-36-8-2-35-critical-security-updates-and-eol-php-7-4-8-1-backports.33134/ и я перенёс их в версии PHP 7.2, 7.3, 7.4, 8.0, 8.1, остановившиеся на поддержке (EOL), для следующих активных веток Centmin Mod:

• 132.00стабильный
• 140.00beta01
• 141.00beta01

Если вы используете более старую версию Centmin Mod, обновите её, следуя инструкциям здесь: community.centminmod.com/threads/131-00stable-140-00beta01-release-with-almalinux-rocky-linux-support.25572/

Чтобы убедиться, что ваша версия PHP исправлена, вы можете запустить скрипт проверки безопасности по адресу community.centminmod.com/threads/php-8-5-12-8-4-27-8-3-36-8-2-35-critical-security-updates-and-eol-php-7-4-8-1-backports.33134/#post-110226

В связи с серьезностью этих уязвимостей безопасности PHP, если вы не уверены в своих силах и не можете самостоятельно выполнить обновления, я готов взяться за платную работу по обновлению ваших серверов. Свяжитесь со мной через личные сообщения по адресу community.centminmod.com/conversations/add?to=eva2000 если вас это заинтересовало. Платные заказы будут обрабатываться через систему тикетов Centmin Mod, которую я использую для платной работы с Centmin Mod.

Если вы больше не хотите получать эти письма, вы можете отписаться от рассылки по ссылке: community.centminmod.com/email-stop/mailing-list?u=2217&c=06edec8f2fd8a0a0fece9917f5b9f526 Однако в этом случае вы пропустите важные новости, касающиеся безопасности и исправлений ошибок. Чтобы гарантировать получение этих писем, добавьте фильтр разрешенных писем или добавьте мой адрес электронной почты в свой список контактов.

Джордж