oscerd/cve-2026-84181Рабочий proof-of-concept на Spring Boot и Quarkus, воспроизводящий обход аутентификации thread-bound-subject в Apache Camel camel-shiro, с уязвимым и исправленным вариантами для сравнения.
Запускаемый воспроизводитель proof-of-concept для уязвимости Apache Camel, при которой процессор безопасности Shiro пропускал
проверку учётных данных, когда Subject Shiro, уже привязанный к текущему потоку, нёс тот же principal, что и
входящий exchange. Поскольку поток, несущий exchange Camel, берётся из пула и переиспользуется между
exchange, subject, оставленный привязанным предыдущим аутентифицированным exchange, мог удовлетворять проверке для последующего exchange,
который предъявлял никаких собственных действительных учётных данных — пароль в этом последующем exchange никогда не проверялся. Атакующему
не нужно ничего, кроме отправки запроса с указанием principal, который в данный момент активно используется.
| Среда выполнения | Каталог | Стек |
|---|---|---|
| Camel Spring Boot | camel-spring-boot/ | Spring Boot 3.5.13 + camel-shiro 4.22.0 (уязвим; исправлено в 4.22.1) |
| Camel Quarkus | camel-quarkus/ | Quarkus 3.29.0 + camel-quarkus-shiro (Camel 4.15.0, уязвим; контроль с исправлением CQ 3.40.0 / Camel 4.22.1) |
Оба модуля демонстрируют как уязвимое, так и исправленное поведение.
Маршрут защищён ShiroSecurityPolicy, созданной с alwaysReauthenticate=false — документированный режим, в
котором аутентифицированный subject намеренно остаётся привязанным к (пуловому, переиспользуемому) рабочему потоку между exchange.
Драйвер эксплойта в рамках одного HTTP-рабочего потока выполняет два exchange по порядку:
ringo с правильным паролем starr — он аутентифицируется и оставляет Shiro
subject привязанным к этому потоку (как это сделал бы предыдущий аутентифицированный запрос в загруженном сервисе);ringo, но с неверным паролем not-starr, в том же
потоке.AuthenticationException, даже несмотря на то, что тот же пользователь всё ещё привязан к потоку.# Camel Spring Boot
cd camel-spring-boot
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected: wrong password reaches protected logic; >>> PROVEN
docker compose down
# Patched control
mvn clean package -Dcamel.version=4.22.1
java -jar target/cve-2026-84181-shiro-auth-bypass-0.0.1-SNAPSHOT.jar &
curl -s http://localhost:8080/exploit/attack # fixed: wrong password rejected; >>> Not exploited
# Camel Quarkus
cd camel-quarkus
mvn clean package
docker compose up -d --build
curl -s http://localhost:8080/exploit/attack # affected (Camel 4.15.0): wrong password reaches protected logic
docker compose down
# Patched control: CQ 3.40.0 ships Camel 4.22.1
mvn clean package -Dcamel-quarkus.version=3.40.0 -Dquarkus.platform.version=3.40.0
java -jar target/quarkus-app/quarkus-run.jar &
curl -s http://localhost:8080/exploit/attack # fixed: wrong password rejected
| Свойство | Значение |
|---|---|
| Компонент | camel-shiro (ShiroSecurityProcessor.authenticateUser) |
| CWE | CWE-287 (Некорректная аутентификация) |
| Уровень серьёзности | MEDIUM |
| Вектор атаки | Запрос, указывающий principal, в данный момент привязанный к переиспользуемому рабочему потоку, не несущий собственных действительных учётных данных |
| Воздействие | Обход аутентификации: неаутентифицированный запрос принимается как уже привязанный principal; его пароль никогда не проверяется |
| Затронутые версии | С 4.0.0 до 4.18.5, с 4.19.0 до 4.22.1 |
| Исправленные версии | 4.18.5, 4.22.1, 4.23.0 |
| JIRA | CAMEL-24439 |
| Благодарность | Claude Security Scan Tool |
Уведомление: https://camel.apache.org/security/CVE-2026-84181.html
ShiroSecurityProcessor.authenticateUser больше не пропускает вход в систему,
когда привязанный к потоку субъект уже несёт тот же principal. Предыдущий код завершался досрочно при
currentUser.isAuthenticated() && username.equals(currentUser.getPrincipal()); совпадение имени пользователя ничего не говорит о
пароле, предъявленном в этом обмене. Теперь процессор вызывает currentUser.login(token) при каждом обмене,
поэтому предъявленные учётные данные всегда проверяются. alwaysReauthenticate по-прежнему управляет временем жизни
rememberMe для субъекта, но больше не определяет, проверяется ли пароль.
Убедитесь, что субъект Shiro очищается из потока в конце каждого обмена (чтобы никакой субъект не мог быть унаследован
последующим) — например, с помощью onCompletion/процессора, вызывающего ThreadContext.unbindSubject() из Shiro, — пока
вы не сможете обновиться.
Этот репозиторий публикуется в образовательных и защитных целях: чтобы помочь пользователям Apache Camel понять уязвимость, проверить, затронуты ли они, и убедиться, что обновление её устраняет. Пользователи, пароли и ключи здесь — это инертные локальные фикстуры. Не используйте этот материал против систем, которыми вы не владеете и не управляете.