Портал открывается, PHP дырявый. Ну красота
Вчера, 21 октября, обновляли PHP на клиентском портале. Стояла уязвимая 8.2.30, поставили 8.2.35. С виду разница в хвосте номера, а повод лезть на сервер вполне паршивый: команда PHP сообщила 21.10.2026 об уязвимостях, позволяющих выполнить чужой код без авторизации. В этом выпуске их исправили.
мы ночью вчера
Портал у клиента на Битриксе. И сразу коротко про волшебную кнопку: SiteUpdate серверный PHP не обновляет. Это отдельно пояснил сам Битрикс в инструкции от 21.10.2026. Все, лекцию про устройство продукта на этом закрываем.
Мы обновили PHP на сервере, перезапустили php-fpm и httpd. Затем проверили портал и уведомили сисадмина клиента. Вот весь кейс, без героической битвы за серверную и выдуманного «успели за секунду до взлома».
Но в этой короткой последовательности есть место, на котором легко срезать угол: пакет уже обновлен, а сайт еще могут обслуживать старые процессы PHP. Поэтому после установки надо проверить именно то, чем исполняется сайт. Сообщение «обновление завершено» само по себе этого не доказывает.
Нам тоже нравится момент, когда команда отработала и можно считать себя молодцами. Особенно нравится часть «можно закрыть задачу». Тут лучше придержать внутреннего красавчика и проверить результат.
Что унести из нашей возни с PHP
Если портал живет на вашем сервере, вот с чем идти к тому, кто его обслуживает. Для облачного Битрикс24 серверную часть обновляет провайдер.
• До работ узнайте фактическую версию PHP, которая обслуживает портал. Попросите показать ее в самом приложении. Ответ команды php -v полезен, но относится к PHP в консоли: у сайта может быть другая сборка. Сверьте оба результата.
• Подготовьте свежую резервную копию портала с базой и конфигурацией сервера. Уточните, как из нее восстановиться. Копия, про которую никто не знает, как ее поднять, в неприятный момент добавит отдельный квест.
• Выберите окно работ. Перезапуск служб может прервать текущие запросы, поэтому предупредите пользователей. Версию для обновления подбирайте с учетом совместимости проекта. Наша 8.2.35 здесь относится к конкретной ветке, слепо повторять ее на любом сервере не надо.
• После установки убедитесь, что все процессы php-fpm уже работают на исправленной сборке. Перезапустить один nginx для этого недостаточно. Попросите админа проверить все FPM-пулы и повторно посмотреть версию из работающего портала. Оставшийся старый процесс продолжит жить со старым PHP, как ни радуйся новому пакету.
• Затем пройдите рабочий маршрут. Выйдите и войдите заново. Загрузите файл и скачайте его обратно. В CRM откройте карточку и проверьте сохранение тестового изменения. Отправьте тестовое письмо. Запустите безопасный тест бизнес-процесса. Для интеграции проверьте прохождение тестового запроса до результата. Действия с реальными данными заранее согласуйте с ответственным.
Открылась главная страница? ЗБС. Но письмо может застрять уже после нее, поэтому рабочий маршрут и нужен целиком. После проверки стоит заглянуть и в журнал ошибок: свежая ошибка даст админу конкретную зацепку.
Мы из этой истории выносим простую привычку: закрывать обновление после проверки работающего портала. А то пакет новый, отчет красивый, и только старый PHP продолжает трудиться. Нихрена себе обновились.