Шесть уязвимостей затрагивают линейку банковских приложений Oracle версий 14.5-14.9. В неё входят Oracle Banking Branch, Oracle Banking Corporate Lending, Oracle Banking Corporate Lending Process Management, Oracle Banking Origination и Oracle Banking Treasury Management. Эти системы ведут обслуживание отделений, корпоративное кредитование, казначейские операции и подключение новых заёмщиков. Наивысшая оценка по шкале CVSS достигает 8,0 из 10, критическими уязвимости не признали. Две из шести используют удалённо по сети, без учётной записи и без участия человека. Успешная атака открывает доступ к чувствительным сведениям, позволяет создавать, удалять и менять данные, а также нарушает доступность сервисов.
Детали уязвимостей
Оценку 8,0 получили сразу две уязвимости. Первая, CVE-2026-87164, находится в компоненте отчётов Oracle Banking Branch. Для её использования нужна учётная запись с низкими правами, сетевой доступ по протоколу HTTP и действие со стороны другого человека, обычно сотрудника, который открывает отчёт. Итог получается тяжёлым: продукт переходит под полный контроль атакующего. Из-за смены области влияния пострадать могут и системы рядом, поэтому одной установкой обновления дело не ограничивается. В том же компоненте отчётов есть вторая уязвимость с оценкой 7,1 и похожим сценарием.
Иначе устроена CVE-2026-83081 в ядре Oracle Banking Corporate Lending. Здесь не нужны ни учётная запись, ни действие пользователя. Атакующему достаточно оказаться в том же сегменте сети, что и сервер с приложением. Дальше он читает и правит все данные, доступные внутри продукта, а последствия выходят за его границы из-за смены области влияния. Оценка тоже 8,0. Требование к позиции в сети снижает риск атаки извне, зато повышает ценность такого доступа для того, кто уже закрепился на соседнем узле.
Ещё одна уязвимость в Oracle Banking Origination затрагивает пакетные процессы, которые сопровождают подключение новых клиентов. Её оценка 7,5, учётная запись с низкими правами нужна, а действий от человека не требуется. Похожие условия у уязвимости в базовом компоненте Oracle Banking Corporate Lending Process Management с оценкой 7,1, только там сотруднику банка нужно открыть определённый раздел.
Шестая уязвимость пришла не из банковской логики, а из инфраструктурного компонента, который опирается на библиотеку журналирования Apache Log4j. Компонент, отвечающий за вывод журналов в формате XML, не отфильтровывает символы, запрещённые спецификацией XML 1.0. Как только в сообщении журнала или в служебном значении появляется такой символ, документ на выходе оказывается непригодным для разбора. Дальнейшее зависит от реализации потокового разбора XML. Версия, встроенная в среду исполнения Java, молча пропускает запрещённые символы в вывод, и разборщики, соблюдающие спецификацию, отбрасывают испорченную запись с фатальной ошибкой. Альтернативные разборщики, например Woodstox, выбрасывают исключение прямо во время записи журнала: событие не доходит до места назначения, о нём узнаёт только внутренний служебный журнал самой библиотеки. Оба сценария заканчиваются потерей части записей, а для банка это означает пробелы в мониторинге и разборе инцидентов. Оценка самой библиотечной уязвимости 6,9 по четвёртой версии CVSS, тогда как Oracle для затронутого банковского модуля приводит 7,5 с влиянием на целостность данных.
Критическими эти уязвимости не назвали, поскольку большинство из них Oracle относит к сложно эксплуатируемым. Для двух сценариев нужен доступ к сегменту сети рядом с сервером, для остальных действующая учётная запись с минимальными правами и в части случаев действие пользователя. Такие условия затрудняют массовые атаки и одновременно усиливают роль внутреннего нарушителя: рядового сотрудника с самыми скромными правами достаточно, чтобы подойти под описание. Сведений о реальных атаках в бюллетене нет. Оценки EPSS (сервис, который прогнозирует вероятность эксплуатации уязвимости) для всех шести держатся ниже одного процента.
Проблема с библиотекой журналирования задевает не только Oracle. Та же Log4j входит в продукты Red Hat, IBM, NetApp, SAP, Splunk и Hewlett Packard Enterprise. Производитель библиотеки устранил уязвимость в версии 2.25.4. До неё подвержены почти все выпуски второй ветки и предварительные сборки третьей. Исправления для своих продуктов уже выпустили Red Hat, Hewlett Packard Enterprise и Juniper Networks.
Обновления Oracle распространяет через службу поддержки, они открыты клиентам с действующим контрактом и покрывают линейку 14.5-14.9. Банкам приходится отслеживать не одну дату закрытия уязвимости, а весь путь исправления: от библиотеки до конкретного банковского модуля. Пока обновление не установлено, разумно ограничить сетевой доступ к затронутым серверам кругом доверенных сотрудников и убедиться, что средства мониторинга продолжают получать журналы целиком. Потеря части записей способна скрыть не только сбои самой библиотеки, но и следы чужой активности внутри инфраструктуры.
Ссылки
