CVE-2026-23552 - Принятие токенов между realm в camel-keycloak

Обзор

KeycloakSecurityPolicy в Apache Camel не проверяет утверждение iss (эмитент) JWT-токенов на соответствие настроенному realm. Это означает, что токен, выданный одним realm Keycloak, молча принимается политикой, настроенной для совершенно другого realm, нарушая изоляцию арендаторов.

Затронутые версии: 4.15.0, 4.16.0, 4.17.0

Отслеживается в: https://issues.apache.org/jira/browse/CAMEL-22854

Корневая причина

В KeycloakSecurityHelper.parseAccessToken(), когда открытый ключ явно не указан (что является конфигурацией по умолчанию), токен только декодируется из Base64 -- он никогда не проверяется:

public static AccessToken parseAccessToken(String tokenString, PublicKey publicKey)
        throws VerificationException {
    if (publicKey != null) {
        return TokenVerifier.create(tokenString, AccessToken.class)
                .publicKey(publicKey)
                .verify()
                .getToken();
    } else {
        // no signature verification, no issuer check
        return TokenVerifier.create(tokenString, AccessToken.class).getToken();
    }
}

Поскольку путь выполнения по умолчанию попадает в ветвь else, три вещи остаются непроверенными:

1. Подпись токена никогда не проверяется
2. Утверждение iss никогда не сравнивается с ожидаемым {serverUrl}/realms/{realm}
3. Открытый ключ JWKS никогда не запрашивается у Keycloak

Проверка ролей всё равно проходит, потому что она смотрит только на имена ролей в полезной нагрузке токена. Если имя роли (tenant-user) совпадает между realm -- что часто встречается в мультитенантных конфигурациях, -- запрос пропускается.

Воздействие

В мультитенантном приложении, где каждый арендатор сопоставляется с отдельным realm Keycloak, пользователь арендатора A может получить доступ к маршрутам, защищённым для арендатора B. А именно:

• Межарендаторный доступ к данным в мультитенантных SaaS-приложениях
• Повышение привилегий, когда в разных realm разные конфигурации ролей
• Полный обход изоляции безопасности на основе realm

Воспроизведение

Этот проект демонстрирует уязвимость с использованием Apache Camel 4.17.0 и локального экземпляра Keycloak.

Предварительные требования

• Java 17+
• Maven 3.9+
• Camel JBang CLI (jbang app install camel@apache/camel)
• Docker или Podman (используется camel infra под капотом)

Настройка

Запустите локальный Keycloak:

camel infra run keycloak

Это запускает Keycloak на localhost:8080 с учётными данными администратора admin/admin.

Запуск

mvn verify

Что происходит

Интеграционный тест (CrossRealmTokenBypassIT) делает следующее:

1. Подключается к локальному Keycloak и создаёт два realm: acme и globex
2. Создаёт конфиденциального клиента в каждом realm с включённым прямым предоставлением доступа (direct access grants)
3. Создаёт роль realm tenant-user в обоих realm
4. Создаёт пользователя alice (пароль alice123) в realm acme и назначает ей роль tenant-user
5. Настраивает маршрут Camel (direct:globex-protected), защищённый политикой KeycloakSecurityPolicy, привязанной к realm globex
6. Получает JWT-токен для alice из realm acme (эмитент: http://localhost:8080/realms/acme)

Запрос успешно выполняется. Токен acme проходит политику globex без каких-либо ошибок.

Ожидаемые результаты тестов на 4.17.0

В исправленной версии (4.18.0+) второй тест завершился бы ошибкой, а третий -- успешно.

Очистка

camel infra stop keycloak

Тест также удаляет realm acme и globex в @AfterAll.

Исправление

KeycloakSecurityPolicy должен отклонять токены, в которых утверждение iss не соответствует {serverUrl}/realms/{realm}. Исправление отслеживается в CAMEL-22854 и будет включено в Camel 4.18.0 (следующий выпуск LTS).