| Package | Affected versions | Patched versions |
|---|---|---|
| org.eclipse.jetty:jetty-server | ≥ 10.0.0, < 10.0.3≥ 11.0.0, < 11.0.3< 9.4.41 | 10.0.311.0.39.4.41 |
| jetty | ≥ 10.0.0, ≤ 10.0.2≥ 11.0.0, ≤ 11.0.2≤ 9.4.40 | |
| e-series santricity os controller | ≥ 11.0, ≤ 11.70.1 | |
| autovue for agile product lifecycle management | = 21.0.2 | |
| communications element manager | = 8.2.2 | |
| communications services gatekeeper | = 7.0 | |
| communications session report manager | ≥ 8.0.0.0, ≤ 8.2.4.0 | |
| communications session route manager | ≥ 8.0.0, ≤ 8.2.4.0 | |
| rest data services | < 21.3 | 21.3 |
| siebel core - automation | ≤ 21.9 |
If an exception is thrown from the SessionListener#sessionDestroyed() method, then the session ID is not invalidated in the session ID manager. On deployments with clustered sessions and multiple contexts this can result in a session not being invalidated. This can result in an application used on a shared computer being left logged in.
There is no known path for an attacker to induce such an exception to be thrown, thus they must rely on an application to throw such an exception. The OP has also identified that during the call to sessionDestroyed, the getLastAccessedTime() throws an IllegalStateException, which potentially contrary to the servlet spec, so applications calling this method may always throw and fail to log out. If such an application was only tested on a non clustered test environment, then it may be deployed on a clustered environment with multiple contexts and fail to log out.
The application should catch all Throwables within their SessionListener#sessionDestroyed() implementations.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free