Команда Backpack for Laravel опублікувала повідомлення про безпеку: у телеметрії пакета Backpack\CRUD виявлено вразливість, що дозволяла віддалене виконання коду (RCE) без автентифікації. Дослідник безпеки Vishal Shukla (@therawdev) відповідально повідомив про проблему 16 травня 2026 року, і команда розробників випустила виправлення менш ніж за 24 години.
Які версії під загрозою
Оновитися потрібно, якщо у вас одна з версій нижче за виправлену:
- CRUD v7 до v7.0.36
- CRUD v6 до v6.8.13
- CRUD v5 до v5.6.2
Що робити
Негайно оновіть пакет до пропатченої версії:
composer update backpack/crud
Цього достатньо, щоб закрити вразливість.
Наскільки це небезпечно
За словами команди, «практична експлуатація вимагала рідкісного поєднання умов, яких немає у більшості стандартних розгортань Laravel». Для атаки одночасно мали виконуватися дві передумови:
- Увімкнена функція PHP
exec() - це типово для VPS та серверів Laravel Forge, але зазвичай вимкнено на шаред-хостингах.
- Незмінений заголовок HTTP Host - CDN на кшталт Cloudflare та системи WAF, як правило, нормалізують заголовки ще до того, як запит дійде до PHP.
Іншими словами, проєкти за Cloudflare чи подібним сервісом мали додатковий захист, тоді як «голі» VPS без CDN були під вищим ризиком. Команда не виявила жодних ознак того, що вразливістю скористалися в реальних атаках.
Як перевірити, чи не зламали сервер
В оригінальному повідомленні наведено шість кроків перевірки. Важлива примітка від авторів: Linux за замовчуванням не логує читання файлів, тому виявити факт компрометації постфактум буває складно.
Крок 1. Чи були ви вразливі
Перевірте, чи доступна функція exec() та які функції вимкнено:
php -i | grep disable_functions
php -m | grep curl
Також варто переглянути конфігурацію PHP-FPM на предмет статусу exec().
Крок 2. Спроби «промацування» в логах nginx
Пошукайте підозрілі запити в access-логах і проаналізуйте коди відповідей - це допоможе зрозуміти, чи були запити заблоковані:
grep "'" /var/log/nginx/access.log
Крок 3. Підозрілі файли
Перегляньте нещодавно змінені файли та все незвичне у тимчасових каталогах:
ls -lat /tmp | head -40
find /var/www -name "*.php" -newer /var/www/html/index.php
Крок 4. Несподівані cron-завдання
Переконайтеся, що в розкладі немає сторонніх завдань:
crontab -u www-data -l 2>/dev/null
crontab -u forge -l 2>/dev/null
Крок 5. Несподівані вихідні з'єднання
Перевірте мережеву активність та останні входи:
ss -tnp | grep -v "127.0.0.1"
sudo last | head -30
Крок 6. Гірка правда про .env
Якщо зловмисник зміг виконати команду на вашому сервері, найімовірніше, перше, що він зробив, - прочитав файл .env. Тому за наявності будь-яких ознак компрометації ротуйте всі секрети: ключ застосунку, паролі до бази даних, токени стороніх сервісів та інші чутливі дані.
Хронологія розкриття
- 16 травня 2026 - отримано повідомлення про вразливість
- 17 травня 2026 - підтверджено та випущено виправлення
- 19 травня 2026 - клієнтів сповіщено електронною поштою
- 15 червня 2026 - опубліковано публічне повідомлення про безпеку
- 17 червня 2026 - опубліковано пост у блозі
Підсумок
Це гарний приклад відповідального розкриття: швидкий патч, прозоре повідомлення для користувачів та грейс-період у 30 днів перед публічним розкриттям, щоб дати час на оновлення. Якщо ви використовуєте Backpack\CRUD - просто оновіться до останньої версії, а за наявності «голого» VPS без CDN додатково пройдіться кроками перевірки вище.
Подяка досліднику Vishal Shukla (@therawdev) за відповідальне розкриття.
.jpg)
