Apache Camel Shiro CVE-2026-84181

Exploitation requires a route secured with the camel-shiro ShiroSecurityProcessor/ShiroSecurityPolicy to be deployed and in use. A legitimate subject for the targeted principal must have recently authenticated and remain bound to a pooled worker thread - a state made persistent when alwaysReauthenticate=false is configured, since subjects are then deliberately long-lived on shared threads. The attacker must send a ShiroSecurityToken naming exactly that in-use principal. Limiting factors: the outcome is non-deterministic (depends on thread-pool reuse timing and an exact principal-name match), it does not trigger on every request, and deployments not using the Shiro component or that clear the subject at end of each exchange are unaffected.

This is a genuine authentication-bypass flaw (CWE-287) in the Apache Camel camel-shiro component, but the signals converge on moderate rather than critical priority. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N, base 5.9) correctly captures the key tension: the attacker needs no credentials (PR:N) and can reach the flaw over the network (AV:N), yet success is NOT reliable (AC:H) because it depends on two conditions outside the attacker's direct control - a pooled worker thread must still carry a subject authenticated for the same principal, and the incoming principal name must match it. No EPSS score was provided, so statistical exploitation probability cannot be weighed. The CVE is NOT listed in CISA KEV and no public exploit code was supplied (the only source-code evidence is the vendor fix diff, not a weaponized PoC), so exploitation status is 'no public exploit identified at time of analysis.' The signals are therefore internally consistent: high confidentiality impact if hit, but low practical reliability. Realistic priority is elevated for deployments that actively use camel-shiro with long-lived thread-bound subjects (especially alwaysReauthenticate=false) and low for everyone not using the Shiro security processor at all.

An attacker repeatedly submits Camel exchanges to a Shiro-secured route presenting a ShiroSecurityToken that names a legitimate, actively-used principal (e.g. 'ringo') but carries no valid password. If the request lands on a pooled worker thread that still has that principal's authenticated subject bound from an earlier exchange, the credential check is skipped and the attacker's request is processed as that user. No public exploit code is known; success is probabilistic and tied to thread reuse timing rather than a deterministic single request.