Дыра в PHP: твой сайт на WordPress может быть открыт настежь

Пока ты думаешь про контент, взламывают фундамент

Есть такая категория новостей, которые проходят мимо большинства владельцев сайтов — потому что звучат скучно и технически. «Критическая уязвимость в PHP». Ну и что, скажешь ты, я же не пишу код, у меня сайт на WordPress, им хостинг занимается.

Вот только именно так и теряют сайты.

Search Engine Journal пишет о критических дырах в ядре PHP, которые затрагивают практически всё, что крутится на этом языке — а это огромная часть интернета, включая WordPress в любой его конфигурации. Не плагин, не тема, не твой криво написанный функции.php — само ядро. Это как найти трещину не в стене дома, а в фундаменте. Косметикой тут не отделаешься.

Почему это не «проблема хостинга»

Удобная позиция — спихнуть ответственность на провайдера. Отчасти она верна: патчи действительно ставит хостинг, а не ты лично. Но вот в чём ловушка — очень многие хостинги не обновляют PHP-версию автоматически на боевых сайтах, потому что боятся сломать клиентские проекты. Обновление версии PHP иногда ломает старые плагины и темы, и провайдеры предпочитают не трогать то, что работает, пока их не попросят.

Итог: патч существует, а твой конкретный сайт продолжает висеть на уязвимой версии месяцами. Никто не придёт и не сделает это за тебя по умолчанию.

Я давно придерживаюсь простого правила: безопасность — это не разовое действие, а процесс, который либо встроен в твою рутину, либо его нет вообще. Разовая «проверка после прочтения новости» закрывает одну дыру и оставляет тебя беззащитным перед следующей.

Что реально нужно сделать

Разложу по-честному, без воды.

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

Дальше — если у тебя не один сайт, а несколько проектов (свои или клиентские), заведи список: домен, версия PHP, дата последней проверки. Звучит скучно и по-бюрократически, но именно отсутствие такого списка приводит к тому, что в кризисный момент ты судорожно вспоминаешь, где у тебя вообще что крутится.

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

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

Это не разовая пожарная тревога

Критические уязвимости в PHP всплывают не в первый и не в последний раз. Разница между теми, кто теряет сайты, и теми, кто спокойно спит, — не везение, а наличие процесса. Мониторинг версии PHP, регулярная сверка с хостингом, документация техстека — скучные вещи, которые вспоминают только когда уже поздно.

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

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