Атакуващ може да изпрати само една уеб заявка до Bonita сървър и да достигне до вътрешен API, за който се е предполагало, че е недостъпен. Заявката пристига без удостоверяване (unauthenticated).

Оттам киберпрестъпникът може да изпълни код на хоста. Bonita BPM обработва одобрения на кредити, застрахователни искове и въвеждане на служители за банки, застрахователи и правителствени агенции, като вътрешната му повърхност отговаря на външни лица.

Изследователи на уязвимости от Novee са открили този вектор на атака. Те го представиха днес на Black Hat USA 2026 в брифинг относно отдалечено изпълнение на код преди удостоверяване (pre-auth RCE) в корпоративни Java платформи.

Одитът обхваща четири корпоративни Java платформи. Той разкрива 12 уязвимости, сред които избягване на изолирана среда (sandbox escape) и четири дефекта, които работят преди всякакъв вход в системата.

Изследователите демонстрираха подробно две от веригите за компрометиране – една в Bonita и една в OFBiz. И двете следват един и същ модел. Маршрутизирането достига до повърхност, която се доверява на своите викащи, а приемникът за изпълнение (execution sink) превръща този достъп в работещ код.

Един уеб адрес заобикаля три защити

Bonita BPM 10.4.3 поддържа публична API повърхност и вътрешна API повърхност. Публичната изисква сесия и CSRF токен. Вътрешната приема базова аутентификация и подава всичко получено на XStream – библиотека, която превръща XML в активни Java обекти.

Три отделни проверки пазят границата между тях. Един-единствен уеб адрес ги преодолява наведнъж. Проверките работят независимо, като всяка се доверява на останалите, че са си свършили работата.

Първата проверка чете пътя по един начин, а диспечерът на Tomcat го чете по друг. Сегмент от пътя, написан като ..;, преминава през филтъра за сигурност като обикновено име. Tomcat премахва точката и запетаята, третира останалото като стъпка нагоре в директорийната структура и пренасочва заявката към вътрешната повърхност.

Втората проверка търси съвпадение по подниз. Измислено име на приложение в пътя удовлетворява филтъра за аутентификация. Същият подниз удовлетворява и CSRF филтъра. И двата филтъра спират четенето при съвпадението.

Последната проверка защитава директните заявки и пропуска пренасочените. Bonita декларира тази защита за един тип заявка и пропуска останалите. Заявка, пристигаща чрез вътрешно пренасочване, преминава недокосната.

Комбинирани, тези пропуски сриват бариерата за влизане в една-единствена POST заявка. Атакуващият се озовава вътре във вътрешния API без нужда от удостоверяване.

XStream приема всякакви типове. Изготвеният от злонамерения субект XML възстановява верига от джаджи (gadget chain) от класове на Commons Collections, пренасочва я през пряк път в паметта, който заобикаля обичайните проверки за сигурност, и достига до Groovy повикване, което изпълнява команда. Последователността се изпълнява в рамките на едно повикване към XStream, преди заявката да е приключила.

Атаката срещу Apache OFBiz

Apache OFBiz 24.09.05 подписва своите токени за еднократен вход (SSO) с ключ, съхраняван в конфигурационен файл. Този ключ се разпространява в публичното хранилище с изходен код. Всяка инсталация, която запазва настройките по подразбиране, подписва токените си с тайна, която всеки може да прочете.

Когато токенът е подписан с този ключ, OFBiz се доверява на твърденията в него. Чрез задаване на потребителя като администратор се генерира администраторска сесия. Киберпрестъпникът получава администраторски права с фалшифициран токен.

Същият ключ подписва и токените за обратно повикване (callback) на уиджета. Токенът носи поле, указващо коя област на екрана да се рендира. OFBiz чете полето от токена и го пренасочва към енджина за шаблони, който оценява Groovy код.

Предпочитание за достъпност определя дали това оценяване ще се изпълни. Администратор може да го активира. Фалшивият администратор го активира и след това изпраща токен, съдържащ Groovy команда на мястото на името на екрана.

Списък с блокирани обекти (denylist) се опитва да спре инжектирането на скриптове. Той търси съвпадения за текст с малки букви и известни префикси. Главното „P“ в ProcessBuilder го заобикаля. Автоматично импортиран клас няма нужда от префикс и също преминава без проблем.

Резултатът е уязвимост CVE-2026-31986 с критичен рейтинг. Две неудостоверени GET заявки водят до изпълнение на код на всяка инсталация на OFBiz с включен еднократен вход (SSO).

Всяка верига е изградена от части, които изглеждат безобидни сами по себе си: заблуден сегмент в URL адрес, грешен режим на съвпадение, липсващ ред в конфигурационен файл, ключ по подразбиране или регулярен израз без флаг за игнориране на регистъра на буквите.

Скенерът за сигнатури няма какво да засече. Генеричен модел чете кода и сигнализира за възможна десериализация, но липсва доказателство, че точката на приемане е достъпна. Експлойтът се крие в начина, по който елементите се свързват.

Novee докладва всички констатации на засегнатите проекти и работи с тях преди публикуването им.

„OFBiz пусна нови версии, които коригират тези уязвимости, а Bonita също издаде нова версия след нашето разкритие. Като цяло и двамата доставчици реагираха много бързо, особено OFBiz, които ни информираха по време на целия процес по отстраняване на уязвимостите. И двамата доставчици завършиха корекциите в рамките на стандартния 90-дневен срок за оповестяване“, сподели Лидор Бен Шитрит, изследовател на уязвимости от Novee, пред Help Net Security.

Имената на другите две платформи остават неразкрити.

„Другите две платформи също се считат за големи корпоративни платформи. Не сме получавали скорошни актуализации от нито един от доставчиците им. Можем обаче да споделим, че двете платформи, които обсъждаме, Bonita и OFBiz, имаха най-критично отражение“, каза Бен Шитрит.