---
title: "Повідомлення про безпеку: неавтентифіковане ін'єктування команд у Backpack\\CRUD"
url: https://laravelukraine.com/blog/povidomlennia-pro-bezpeku-neavtentifikovane-injektuvannia-komand-u-backpackcrud
author: "Олексій Бабінцев"
date: 2026-06-22
---

# Повідомлення про безпеку: неавтентифіковане ін'єктування команд у Backpack\CRUD

Команда 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

## Що робити

Негайно оновіть пакет до пропатченої версії:

```bash
composer update backpack/crud
```

Цього достатньо, щоб закрити вразливість.

## Наскільки це небезпечно

За словами команди, «практична експлуатація вимагала рідкісного поєднання умов, яких немає у більшості стандартних розгортань Laravel». Для атаки одночасно мали виконуватися дві передумови:

1. **Увімкнена функція PHP `exec()`** - це типово для VPS та серверів Laravel Forge, але зазвичай вимкнено на шаред-хостингах.
2. **Незмінений заголовок HTTP Host** - CDN на кшталт Cloudflare та системи WAF, як правило, нормалізують заголовки ще до того, як запит дійде до PHP.

Іншими словами, проєкти за Cloudflare чи подібним сервісом мали додатковий захист, тоді як «голі» VPS без CDN були під вищим ризиком. Команда не виявила жодних ознак того, що вразливістю скористалися в реальних атаках.

## Як перевірити, чи не зламали сервер

В оригінальному повідомленні наведено шість кроків перевірки. Важлива примітка від авторів: Linux за замовчуванням не логує читання файлів, тому виявити факт компрометації постфактум буває складно.

### Крок 1. Чи були ви вразливі

Перевірте, чи доступна функція `exec()` та які функції вимкнено:

```bash
php -i | grep disable_functions
php -m | grep curl
```

Також варто переглянути конфігурацію PHP-FPM на предмет статусу `exec()`.

### Крок 2. Спроби «промацування» в логах nginx

Пошукайте підозрілі запити в access-логах і проаналізуйте коди відповідей - це допоможе зрозуміти, чи були запити заблоковані:

```bash
grep "'" /var/log/nginx/access.log
```

### Крок 3. Підозрілі файли

Перегляньте нещодавно змінені файли та все незвичне у тимчасових каталогах:

```bash
ls -lat /tmp | head -40
find /var/www -name "*.php" -newer /var/www/html/index.php
```

### Крок 4. Несподівані cron-завдання

Переконайтеся, що в розкладі немає сторонніх завдань:

```bash
crontab -u www-data -l 2>/dev/null
crontab -u forge -l 2>/dev/null
```

### Крок 5. Несподівані вихідні з'єднання

Перевірте мережеву активність та останні входи:

```bash
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) за відповідальне розкриття.