Rest Service в Oracle Data Integrator не требует аутентификации, а в JD Edwards нарушено управление привилегиями

Отсутствие проверки подлинности пользователя в Oracle Data Integrator позволяет удалённому нарушителю полностью распоряжаться платформой интеграции данных. Схожая по последствиям уязвимость обнаружена в финансовом контуре JD Edwards EnterpriseOne General Ledger: там нарушено разграничение прав, поэтому обладатель учётной записи способен захватить подсистему целиком. Производитель подтвердил обе проблемы, исправления доступны, а сведения о применении этих уязвимостей в реальных атаках пока уточняются.

Детали уязвимостей

Компонент Rest Service в Oracle Data Integrator не проверяет, имеет ли обращающийся право на выполнение критичной функции. Ошибка относится к классу "отсутствие аутентификации для критичной функции" (CWE-306). Иначе говоря, сервис отвечает на запросы без учётных данных. Для эксплуатации достаточно сетевого доступа к интерфейсу по протоколу HTTP. Ни логин, ни пароль, ни предварительное закрепление в инфраструктуре нарушителю не нужны. Базовая оценка уязвимости составляет 10 из 10 в версиях CVSS 2.0 и 3.1, что соответствует критическому уровню опасности. В международной базе уязвимость зарегистрирована под идентификатором CVE-2026-47056, в Банке данных угроз безопасности информации (BDU) - под номером BDU:2026-14581.

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

Во второй истории речь идёт о привилегиях. Компонент E1 Foundation в модуле финансового контура JD Edwards EnterpriseOne General Ledger небезопасно управляет правами доступа (CWE-269). Нарушитель, у которого уже есть учётная запись, повышает свои возможности и получает полный контроль над подсистемой. Оценка по CVSS 3.1 составляет 9,9, по CVSS 2.0 - 9. Уязвимость получила идентификаторы CVE-2026-46893 и BDU:2026-14585. Даты выявления у двух проблем разные: июнь и июль. Это значит, что исправления вошли в разные наборы обновлений, и часть организаций могла пропустить одно из них, установив только второе.

Финансовый контур - чувствительная часть ERP-системы (комплекса программ для управления ресурсами предприятия). В главной книге сходятся проводки, расчёты с контрагентами и данные отчётности. Значит, компрометация подсистемы даёт возможность не только читать финансовые документы, но и менять их. Кроме того, модули Oracle JD Edwards обычно связаны между собой. Лишние права в одном месте упрощают движение к соседним контурам: закупкам, складу, расчётам с персоналом. Для бухгалтерии и службы внутреннего контроля такой сценарий означает риск искажения отчётности. Расхождения при этом обнаруживаются не сразу, а по итогам сверки или аудита. В отличие от первой уязвимости, здесь нарушителю нужна действующая учётная запись. Поэтому основную угрозу составляет не внешний атакующий, а внутренний пользователь или подрядчик с завышенными полномочиями.

Исправления Oracle включила в два набора обновлений - июньский и июльский. Ссылки на рекомендации производителя опубликованы в бюллетенях по безопасности Oracle. Способ устранения в обоих случаях один: обновление программного обеспечения. Тем не менее установка исправления - только часть работы. Администраторам стоит проверить, какие интерфейсы платформы интеграции доступны за пределами защищённого контура, и ограничить доступ к ним. Затем имеет смысл пересмотреть права учётных записей в JD Edwards и привести их к принципу минимально необходимых полномочий. Наконец, полезно просмотреть журналы обращений к Rest Service. Если сервис долго работал без аутентификации, в них могут остаться следы посторонних запросов, а также признаков подготовки к выгрузке данных. Для тех, кто не может обновиться немедленно, разумная мера - изоляция сервиса на уровне сети и запрет прямых обращений из внешних сегментов.

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