Ключевые улучшения

Проблемы оригинальной версии

Оригинальный скрипт эксплойта использовал requests.post(files=...) для формирования multipart-запросов. Несмотря на удобство, этот подход создавал критические проблемы с надёжностью:

• Автоматическая генерация boundary: библиотека requests автоматически генерирует boundary и добавляет собственный заголовок Content-Type
• Трансформация содержимого: может экранировать или преобразовывать содержимое полезной нагрузки (например, кавычки, переводы строк, JSON-структуры), нарушая тонкий механизм десериализации протокола Flight, ожидаемый сервером
• Совместимость с окружением: в средах со строгим парсером, прокси или WAF это приводит к некорректным запросам или тихим сбоям
• Сбои обнаружения: режим --check часто ошибочно сообщал «не уязвим» из-за расхождений в форматировании полезной нагрузки

Решение

Эта версия обеспечивает совместимость и надёжность за счёт следующих подходов:

✅ Ручное формирование multipart: собрано из сырых байтов, что сохраняет точную семантику полезной нагрузки

✅ RFC-совместимый boundary: автоматически генерируется с помощью uuid.uuid4() для создания корректного boundary

✅ Корректный Content-Type: заголовок Content-Type явно задаётся в соответствии с сырым телом запроса

✅ Без автоматического экранирования: сохраняет целостность полей _prefix и prototype pollution

✅ Единообразное применение: используется одна и та же логика сырого multipart в обоих методах:

• метод execute() (для выполнения команд)
• метод check_vulnerability() (для точного обнаружения)

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