Восстановление PHP-сайта после взлома и сбоя в Казани

С какими неисправностями обращаются

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

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

Критические уязвимости PHP: что проверяем в октябре 2026 года

21 октября 2026 года проект PHP сообщил об исправлении CVE-2026-109618 и CVE-2026-109619, допускающих удалённое выполнение кода без авторизации. Первые исправленные upstream-релизы: PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Сверяем сообщения разработчиков PHP, версию пакета и исправления поставщика хостинга.

23 октября разработчики опубликовали дополнительное предупреждение о session upload progress при определённом сочетании настроек и кода приложения. Проверяем его применимость отдельно: одного номера версии для полной оценки недостаточно. PHP веб-сервера может отличаться от командной строки, поэтому проверяем нужный сайт, пул PHP-FPM и остальные затронутые сайты на сервере.

PHP 8.1 больше не получает штатную поддержку проекта PHP. Для старых веток проверяем доступные исправления поставщика и план перехода на поддерживаемую версию. Сам факт наличия уязвимой версии ещё не доказывает взлом; обновление PHP не удаляет уже внедрённый вредоносный код.

Что входит в диагностику за 5 000 ₽

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

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

Как восстанавливаем сайт после взлома

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

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

Обновление PHP без переключения вслепую

Проверяем совместимость версии CMS, модулей, шаблонов и собственного кода с выбранной веткой PHP. Изменения сначала испытываем на изолированной копии с закрытым внешним доступом и отключёнными реальными оплатами, письмами и обменами. Работу по обновлению сайта согласуем по найденным зависимостям.

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

Что будет с заказами, резервами и предупреждениями поисковиков

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

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

Что прислать для начала работы

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

Пароли и ключи в форму заявки не отправляйте. После согласования работ уточним необходимый объём прав и безопасный способ передачи временного доступа. Обращение можно оставить в любое время; команда отвечает с 08:00 до 16:00 по МСК.