The broker accepted a session identifier presented by the client at the start of the authentication flow and reused it after a successful login rather than issuing a fresh one. Any position allowing a cookie to be written on a shared parent domain was therefore sufficient to take over an account, with no interaction beyond the victim logging in normally.
We found this during a routine application security engagement for a client who had deployed the broker in front of forty internal services. The bug was in the broker, not in their configuration, so we took it to the vendor.
The vendor shipped a fix in 4.6.2 which rotates the identifier on privilege transition. If you cannot upgrade, terminating sessions at a reverse proxy that issues its own identifier is an effective mitigation.
