Корпоративните Java платформи остават атрактивна мишена, тъй като междинният софтуер (middleware) често разкрива пътища, които разработчиците са считали за вътрешни. Ново изследване, представено за Black Hat 2026, описва 12 недостатъка в различни продукти, включително бягство от изолирана среда и четири проблема, възникващи преди автентификация.

Най-сериозните констатации са две вериги за отдалечено изпълнение на код (RCE), засягащи Bonita BPM и Apache OFBiz. И двете вериги започват преди вход в системата и разчитат на връзки между маршрутизирането, кода за автентификация и функциите за изпълнение.

Изследователите заявиха, че всеки проблем е бил отговорен докладван чрез координирано оповестяване преди публикуването. Администраторите трябва да инсталират корекции за сигурност, да прегледат изложените услуги и да избягват тестване на системи без оторизация. Вътрешният междинен софтуер трябва да се третира като изложен на заплахи.

Версия 10.4.3 на Bonita BPM илюстрира как няколко малки дефекта могат да сринат границата на автентификация. Нейният публичен API изисква сесия и CSRF защита.

В същото време вътрешната API услуга на сървъра поддържа автентификация и обработва XStream XML. Изследователите са открили път, съдържащ кодирани точки и запетаи, които компонентите интерпретират по различен начин.

Един слой за сигурност е разглеждал заявката като част от публичния API, но по-късно Tomcat я насочва към serverAPI. Проверките с регулярни изрази, използващи Matcher.find, също са приемали безопасни поднизове.

И накрая, ограничението на serverAPI не е обхващало пренасочените заявки. Това е позволило на неавтентифицирана заявка да достигне до десериализация на XStream, където разрешенията за типове и верига от джаджи (gadget chain) могат да изпълняват команди.

Версия 24.09.05 на Apache OFBiz води до същия резултат. Платформата за планиране на ресурсите поддържа SSO токени, изобразяване на уиджети, Groovy и FreeMarker шаблони.

Изследователи от Novee.Security докладваха, че ключ за подписване, включен в конфигурацията по подразбиране, е бил използван за валидиране на HMAC-SHA-512 JWT токени. При инсталации, където администраторите не са заменили ключа, атакуващите биха могли да фалшифицират JWT и да се представят за администратор.

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

Защитата е неуспешна, тъй като OFBiz е използвал черен списък за проверка на изразите преди изпълнение. Шаблонът е бил чувствителен към регистъра на буквите и се е опитвал да блокира думи като „java“, „process“, „import“ и „class“. Семантиката на Groovy прави този подход ненадежден.

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

Тя се проследява като CVE-2026-31986 и е оценена като критична. Веригата показва защо подписаните данни трябва да бъдат валидирани по предназначение, тип, съдържание и граница на доверие, а не просто по подпис.

Защитниците трябва да търсят тези обвързани във верига слабости. Ограниченията за сигурност трябва да защитават пътищата за разпределяне REQUEST, FORWARD, INCLUDE и ERROR. Филтрите за автентификация и CSRF трябва да сравняват нормализирани пътища, вместо да приемат съвпадения на поднизове.

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

Ако сериализаторът е необходим, строгите бели списъци и филтрите JEP 290 могат да намалят излагането на риск. Потребителските предпочитания и настройки никога не трябва да разрешават оценяване от страна на сървъра.

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