5 августа 2026 года исследователи компании Novee во главе с Лидором Бен Шитритом представили на Black Hat USA работу, в которой раскрыли двенадцать уязвимостей в четырёх корпоративных Java-платформах, включая две критические цепочки, позволяющие выполнить код на сервере вообще без входа в систему: в платформе бизнес-процессов Bonita BPM и в Apache OFBiz, ERP-системе с открытым исходным кодом. Практический вывод для любого владельца бизнеса: система, которую вы считаете защищённой, потому что она внутренняя, может быть достигнута двумя запросами из браузера, если она доступна извне и не обновлена. Настоящая защита начинается с инвентаризации того, что у вас работает, и с регулярной установки обновлений, а не с доверия к периметру сети.

Что именно обнаружили исследователи

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

Цепочка BadBonita: три слабых места дают одну полную компрометацию

Первая цепочка затрагивает Bonita BPM версии 10.4.3. Она начинается с обхода аутентификации, составленного из трёх связанных слабостей: обхода пути с помощью записи ..;, фильтра безопасности, который сверяет подстроку, а не полный путь, и внутренней логики перенаправления запросов. В результате запрос попадает во внутренний API, который никто извне вообще не должен был видеть. Этот API принимает недоверенный XML и передаёт его напрямую библиотеке XStream, которая его десериализует, и через хорошо известную цепочку гаджетов Commons Collections путь заканчивается выполнением команд Groovy на сервере.

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

OFBiz: ключ подписи, опубликованный в открытом репозитории

Вторая проблема, зарегистрированная как CVE-2026-31986 и оценённая как критическая, затрагивает Apache OFBiz версии 24.09.05 при включённом едином входе. Проблема в том, что ключи подписи по умолчанию находятся в публично опубликованном исходном коде, и поскольку многие установки оставляют настройки по умолчанию нетронутыми, атакующий может подделать действительный токен SSO от имени учётной записи администратора. Дальше запрос проходит через список запретов, который пытался блокировать такие слова, как java, process и import, но список учитывал регистр и проверял конкретные шаблоны, поэтому достаточно изменить регистр одной буквы или использовать другое имя автоматически импортируемого класса, чтобы проскочить. Итог: двух GET-запросов без аутентификации достаточно, чтобы дойти до выполнения кода на любой установке с SSO.

Почему это касается именно вас

Потому что ни то, ни другое не является второстепенным инструментом. OFBiz — это ERP-система с открытым исходным кодом, которую многие компании используют для управления складом, закупками и выставлением счетов, а Bonita — движок бизнес-процессов, на котором работают внутренние согласования и процедуры. Тот, кто добрался до этих двух мест, не просто читает данные, он стоит в центре вашего операционного цикла: заказы на закупку, цены поставщиков, данные сотрудников, история клиентов. Исследователи сообщили, что оба поставщика выпустили исправленные версии в рамках стандартного девяностодневного срока раскрытия, а значит, обновление существует, и ответственность теперь лежит на том, кто эксплуатирует систему, а не на том, кто её создал.

Настоящий пробел на рынке — не отсутствие исправлений, а отсутствие инвентаризации. У многих организаций нет актуального списка того, что у них реально работает, в какой версии и на каком домене. Поэтому старая тестовая копия два года висит на забытом поддомене и становится дверью, о которой никто не подумал.

Что сделать на этой неделе

  • Проведите инвентаризацию систем: письменный список всех систем, которые у вас работают, их версий, доступны ли они из интернета и кто конкретно за каждую отвечает.
  • Немедленно обновите Bonita и OFBiz до исправленных выпусков, если вы используете одну из них, и перед обновлением прочитайте официальную страницу безопасности Apache.
  • Замените каждый ключ шифрования или подписи по умолчанию, поставлявшийся с продуктом. Любое значение, напечатанное в документации, не является секретом.
  • Закройте административные входы от открытого интернета и обращайтесь к ним через частную сеть или короткий список разрешённых адресов.
  • Выведите из эксплуатации старые тестовые копии и неиспользуемые поддомены. Это самая лёгкая цель и наименее контролируемая.
  • Включите журналирование доступа и храните журналы. Без журналов вы потом не сможете ответить, проник ли вообще кто-нибудь.

Инженерный урок: внутренняя сеть — это не граница безопасности

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

Никогда не полагайтесь на список запретов для защиты опасной операции. Если вычисление выражений не требуется в каком-то участке кода, удалите его полностью, а не пытайтесь фильтровать.

Второе правило — никогда не ставить чувствительную операцию в зависимость от флага настроек или пользовательского параметра, который можно изменить изнутри системы. Третье — проверять логику фильтров аутентификации на любое сравнение по подстроке, потому что это самая повторяемая и самая легко эксплуатируемая ошибка этого класса. Когда мы в Origami строим новые бизнес-системы, мы применяем это по умолчанию: явная авторизация в каждой точке доступа и никакого доверия, основанного на том, где запрос находится в сети.

Регуляторный аспект в Саудовской Аравии

Если скомпрометированная система хранит персональные данные лиц, находящихся в Королевстве, вопрос перестаёт быть чисто техническим. Закон о защите персональных данных (PDPL) обязывает оператора принимать необходимые меры для защиты этих данных и сообщать об инцидентах, затрагивающих их конфиденциальность. Национальное управление кибербезопасности (NCA) публикует базовые меры контроля, охватывающие управление уязвимостями, установку обновлений и управление активами, и это именно те меры, которые остановили бы эту цепочку. Работа на старой версии продукта с известной и уже исправленной уязвимостью — позиция, которую трудно защитить на любой проверке.

Простое правило: относитесь к обновлениям безопасности как к ежемесячному операционному обязательству с ответственным и сроком, а не как к срочной задаче, выполняемой после инцидента.

Источники

  • Help Net Security — подробности о цепочках RCE без аутентификации и CVE-2026-31986: helpnetsecurity.com
  • Официальная страница безопасности Apache OFBiz: ofbiz.apache.org/security.html
  • Национальное управление кибербезопасности (NCA) — меры контроля и нормативные рамки: nca.gov.sa
  • Саудовское управление данных и искусственного интеллекта (SDAIA) — Закон о защите персональных данных (PDPL): sdaia.gov.sa