SURIQ
If you turned on two-factor authentication for your self-hosted JetBrains Hub, you did the responsible thing, and it bought you almost nothing against this bug. JetBrains has patched CVE-2026-56141, a critical flaw in Hub where the account-recovery codes that back up 2FA were generated badly enough to be guessable. A guessable recovery code is a second factor an attacker already holds. The vendor scores it 9.8 and says no authentication is needed to pull it off.
This is not a bug tracker login problem. Hub is the identity broker that sits behind self-hosted JetBrains products, so the blast radius is bigger than it looks. If you run Hub, or YouTrack or TeamCity on your own servers, treat this as today's work: update, then reset every recovery code.
What JetBrains actually patched
The fix lands in JetBrains Hub. According to the CVE record, which JetBrains itself assigned as the CNA, the weakness is classified as CWE-338, use of a cryptographically weak pseudo-random number generator. In plain terms, the codes Hub handed out for account recovery were drawn from a random source that is fine for shuffling a list and useless for anything an attacker is trying to guess.
The CVSS 3.1 breakdown is the part that should move it to the top of your queue, a base score of 9.8. It is reachable over the network, low in attack complexity, needs no privileges and no user interaction, and yields full loss of confidentiality, integrity, and availability on the account. JetBrains shipped corrected builds and lists them as the fixed versions:
- Hub 2026.1.13757
- Hub 2025.3.148033
- Hub 2025.2.148048
- Hub 2025.1.148120
- Hub 2024.3.148430
- Hub 2024.2.148429
Anything older than the build on your release line is exposed. JetBrains has not published a full technical writeup of the predictability, and you do not need one to act: the vendor has confirmed the class of flaw, the score, and the patched builds, and that is enough to patch and rotate.
Why predictable recovery codes break the whole point of 2FA
Recovery codes are the part of two-factor authentication nobody thinks about until they lose a phone. In Hub they are short codes issued when a user enables 2FA, meant to get that user back in when the authenticator app is gone. The quiet truth is that a recovery code is a full second factor. Anyone holding a valid one can satisfy the 2FA prompt without the password and without the app.
So when the generator behind those codes is weak, the math flips against you. The accounts most exposed here are the ones that enabled 2FA, because those are the accounts that have recovery codes in the first place. The control you added to raise the bar became the path under it. That is the uncomfortable pattern: a security primitive treated as a low-stakes convenience feature, generated with the same casual randomness as a sort key, when it actually carries the weight of an authentication factor. We have written before about auth primitives that silently stop doing their job, and this is the same shape of failure in a different layer.
Hub is your identity layer, not a side service
The reason this rates urgent attention rather than a shrug is what Hub controls. Hub is the single-sign-on and user-management layer behind self-hosted JetBrains tooling. YouTrack and TeamCity lean on it for authentication. Take over a Hub account and you are not looking at one app, you are looking at whatever that identity unlocks across the stack: issue trackers full of internal detail, source-linked projects, and in the TeamCity case, the CI/CD pipelines that build and ship your software.
An attacker who lands a developer or administrator account on a build server is one step from the supply chain. That is the same reasoning that made the JetBrains plugin credential theft worth covering, and it is why an auth flaw in the identity broker is a bigger deal than its product name suggests. The auth stack is the blind spot precisely because teams audit the apps and trust the login layer underneath them.
What to do now
Patch first. Move self-hosted Hub to the fixed build for your release line, and update the YouTrack and TeamCity installs that depend on it. JetBrains Cloud customers are handled by JetBrains; the action items here are for teams running their own instances.
Then rotate, because patching alone is not the finish line. The update stops Hub from minting new predictable codes. It does not reach back and invalidate the codes already sitting in users' password managers and printouts, and those were generated by the weak code path. After you patch, force a recovery-code regeneration for every account, starting with administrators and anyone with access to TeamCity build configurations.
Then hunt. Pull Hub authentication logs and look for any sign-in that used a recovery code, especially from an unfamiliar address or close in time to a change in a user's 2FA settings or API tokens. A successful exploit looks like a legitimate recovery-code login followed by the attacker setting up their own persistence. Centralized authentication-log retention and search is exactly the kind of plumbing that makes this hunt possible after the fact, which is part of why we built Suriq on Wazuh rather than trusting that every team keeps clean auth logs on hand.
Being early on a critical means the exploit detail is still thin and the patch window is open. Close it before someone publishes the part JetBrains left out.