Уязвимость на сайте компании: что делать в первые 24 часа

Приходит письмо от хостинга, предупреждение CERT Polska (польской группы реагирования на компьютерные инциденты) или сообщение от исполнителя: в программном обеспечении Вашего сайта есть уязвимость, и её нужно закрыть. Уязвимость — это ошибка в коде, через которую посторонний может захватить сайт, дописать в него собственный код или получить доступ к данным клиентов. Когда информация становится публичной, её знают и преступники, а уязвимые сайты они ищут с помощью ботов. Поэтому откладывать дело на следующую неделю рискованно.

Ниже Вы найдёте план на первые сутки в порядке, который защищает от типичных ошибок: проверка, копия, исправление, пароли и следы, а в конце оценка утечки данных и уведомления. Большинство шагов Вы выполните без программиста, а для остальных я подсказываю, что поручить хостингу или исполнителю. Я пишу о ситуации на 7 ноября 2026 г. Фрагменты о GDPR (RODO) и законе о KSC (ustawa o krajowym systemie cyberbezpieczeństwa, польский закон о национальной системе кибербезопасности) являются общей информацией, а не юридической консультацией.

Часы в заголовках ориентировочные. Если Вы с самого начала подозреваете, что кто-то получил доступ к данным клиентов, сразу прочитайте раздел о UODO (Urząd Ochrony Danych Osobowych, польское Управление по защите персональных данных), потому что срок в 72 часа отсчитывается с момента обнаружения нарушения.

Часы 0–2: проверьте, касается ли уязвимость Вашего сайта

Прежде чем что-либо менять, установите три вещи: какого программного обеспечения касается уязвимость, в каких версиях и с какой версии есть исправление. Берите их из сообщения производителя (например, php.net, nodejs.org, страница плагина в каталоге WordPress.org) или из базы признанной компании, для плагинов, например, Wordfence или Patchstack. Статьи в СМИ часто упрощают номера версий.

Затем сравните это со своим сайтом:

• WordPress: в консоли откройте Инструменты → Здоровье сайта → Информация. Там Вы найдёте версию WordPress, PHP, темы и плагинов. Версии плагинов видны также в списке в меню Плагины.
• Виртуальный хостинг: версию PHP показывает панель хостинга, обычно в настройках домена или PHP.
• Сайт, написанный на заказ, например на Next.js или Node.js: спросите исполнителя. Готовое сообщение Вы найдёте ниже.

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

Проверьте также, атакуют ли уязвимость на практике. Американское агентство CISA ведёт каталог KEV, то есть список уязвимостей, которые использовались в реальных атаках. Если номер CVE из сообщения там есть, ускорьте все следующие шаги. Кроме того, в сервисе moje.cert.pl, который ведёт CERT Polska, можно заказать бесплатное сканирование своего домена. Это не заменит проверку версий, но бывает хорошей второй парой глаз.

Час 2: резервная копия перед изменениями

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

Подпишите копию датой и временем, например BEFORE-PATCH-2026-11-07-10-00. Если Вы подозреваете, что кто-то уже проник на сайт, эта копия служит также доказательством: не восстанавливайте её потом как «чистую» версию. Почему одной копии мало и как проверить восстановление, я описываю в статье о резервной копии сайта и правиле 3-2-1.

Часы 2–6: обновление или обходное решение

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

Если исправления ещё нет или Вы не можете сразу его установить, примените обходное решение, то есть временную защиту, описанную в сообщении производителя. Это может быть отключение плагина, отключение одной функции в конфигурации или правило файрвола веб-приложений (WAF) у хостинга. Обходное решение даёт время, но не закрывает вопрос, поэтому сразу внесите в календарь срок полного обновления.

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

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

Часы 6–12: учётные записи, пароли, логи и новые файлы

Обновление закрывает дверь, но не говорит, не вошёл ли кто-то до Вас. Поэтому проверьте следы.

Учётные записи администраторов. В WordPress откройте Пользователи и выберите роль «Администратор». Каждая учётная запись, которую никто в компании не узнаёт, служит тревожным сигналом: запишите логин, e-mail и дату создания и только потом удалите её. Просмотрите также пользователей панели хостинга и Google Search Console.

Пароли. Смените пароли к панели сайта, хостингу, FTP/SFTP и базе данных, а также ключи API (например, для платежей или отправки писем), если они хранились на сервере. Делайте это с компьютера, в котором Вы уверены, и включите двухэтапный вход везде, где это возможно.

Логи. Попросите хостинг предоставить логи доступа и ошибок со дня раскрытия уязвимости, пока они не перезаписаны. Ищите повторяющиеся запросы к адресам, которых касается уязвимость, и входы в панель с незнакомых IP-адресов.

Новые и изменённые файлы. В файловом менеджере отсортируйте файлы по дате изменения. Подозрительны изменения, которых никто не вносил, а также PHP-файлы в каталогах для изображений (в WordPress это wp-content/uploads).

Если Вы найдёте следы взлома, переходите к плану из статьи Взломанный WordPress: что делать в первый час. Большинство шагов подходит и для сайтов на другом программном обеспечении.

Утечка данных: UODO, клиенты и CERT Polska

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

UODO за 72 часа (ст. 33 GDPR)

Согласно ст. 33 GDPR администратор данных сообщает о нарушении Председателю UODO без неоправданной задержки, по возможности не позднее чем через 72 часа после его обнаружения. Уведомление не требуется, если нарушение вряд ли приведёт к риску для прав или свобод людей. К уведомлению, отправленному позже 72 часов, нужно приложить объяснение причин задержки.

Уведомление можно подать онлайн через форму на biznes.gov.pl, подписав его доверенным профилем (profil zaufany) или квалифицированной электронной подписью. Если срок истекает, а Вы ещё не знаете всех подробностей, отправьте предварительное уведомление и дополните его позже. Образец формы есть на сайте UODO, а по общим вопросам помогает горячая линия ведомства: 606 950 000, в рабочие дни с 10 до 14.

Пункт 5 статьи 33 GDPR требует документировать каждое нарушение, в том числе то, о котором Вы не сообщаете в UODO: что произошло, каковы последствия и что сделано. Заметки, которые Вы ведёте по этому плану, станут хорошим началом. Оценку риска в конкретном деле обсудите с юристом или инспектором по защите данных.

Уведомление клиентов (ст. 34 GDPR)

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

Здравствуйте, [дата] мы обнаружили несанкционированный доступ к нашему сайту. Могли быть раскрыты имя, фамилия, адрес e-mail и номер телефона, указанные при заказе. Мы закрыли уязвимость, сменили пароли и сообщили о случившемся в UODO. Просим Вас с осторожностью относиться к сообщениям, которые ссылаются на Ваш заказ и просят о доплате или данных для входа: мы не отправляем таких просьб. Вопросы просим направлять на адрес [e-mail].

CERT Polska

Об инциденте можно сообщить в CERT Polska через форму incydent.cert.pl. Команда работает в составе NASK (польского государственного исследовательского института) и принимает сообщения также от компаний, на которые не распространяется закон о KSC. Это не заменяет уведомления UODO: это два разных учреждения и две разные цели.

NIS2 и закон о KSC

Если Ваша компания является ключевым или важным субъектом в смысле закона о национальной системе кибербезопасности с поправками 2026 г. (Dz.U. 2026 поз. 252; Dz.U. — официальный вестник законов Польши), для неё действуют отдельные сроки сообщения о серьёзных инцидентах в соответствующую группу CSIRT, в том числе раннее предупреждение не позднее чем через 24 часа после обнаружения. На большинство малых компаний этот закон не распространяется. Как это проверить, я описываю в статье На кого распространяется NIS2?

Что поручить хостингу и исполнителю

У хостинга и исполнителя часто есть то, чего нет у Вас: логи сервера, технический доступ и копии за последние дни. Кто за что отвечает, зависит от вида хостинга и договора, о чём я пишу в статье о том, кто отвечает за обновление сайта. В первые сутки попросите конкретные вещи, лучше всего по e-mail, чтобы остался след:

Здравствуйте, в связи с уязвимостью [название и номер CVE] прошу: 1) сообщить, использует ли сайт [адрес] уязвимую версию и когда он будет обновлён; 2) предоставить копию файлов и базы данных до обновления; 3) предоставить логи доступа и ошибок с [дата раскрытия уязвимости]; 4) сообщить, видны ли следы эксплуатации уязвимости. Прошу ответить сегодня до [время].

Если хостинг или исполнитель обрабатывает данные Ваших клиентов от Вашего имени, п. 2 ст. 33 GDPR обязывает его уведомить Вас о нарушении без неоправданной задержки. Однако решение об уведомлении UODO принимаете Вы как администратор, поэтому не ждите пассивно их оценки.

Контрольный список на 24 часа для печати

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

1. У меня есть сообщение производителя: название программного обеспечения, уязвимые версии, версия с исправлением, номер CVE.
2. Я знаю, какую версию использует мой сайт и есть ли уязвимость в каталоге KEV.
3. Копия файлов и базы данных скачана за пределы сервера и подписана датой.
4. Исправление установлено или обходное решение включено, а срок полного обновления внесён в календарь.
5. Сайт, форма и заказы работают после изменений.
6. Список администраторов проверен, незнакомые учётные записи записаны и удалены.
7. Пароли и ключи API изменены, двухэтапный вход включён.
8. Логи и новые файлы просмотрены или их проверка поручена хостингу.
9. Оценено, могли ли утечь персональные данные. Если да: уведомление UODO в течение 72 часов и решение об уведомлении клиентов.
10. Записка о ходе событий сохранена.
11. Принято решение о сообщении в CERT Polska.

Итог

Порядок имеет значение: сначала установите, касается ли Вас уязвимость, затем копия, исправление, пароли и следы, а в конце оценка утечки и уведомления. Записывайте всё по ходу, потому что эти заметки пригодятся и ведомству, и исполнителю.

Если Вы предпочитаете, чтобы за этим следил кто-то другой, выберите техническую поддержку. В пакете «Дежурство» (от 149 зл без НДС в месяц) я проверяю сайт каждые 5 минут, раз в неделю делаю копию вне сервера, а срочные обновления безопасности устанавливаю за 2 дня. Standard (от 349 зл без НДС в месяц) означает ежедневные копии и реакцию в течение 1 рабочего дня, а Pro (от 749 зл без НДС в месяц) реакцию в течение 4 часов, при аварии и в выходные. После инцидента стоит заказать аудит безопасности с отчётом и исправлениями, от 990 зл без НДС. Если уязвимость касается Вашего сайта уже сейчас, напишите мне: отвечаю в течение 24 часов.