A newly published CVE covers a serious authentication flaw in Leantime, the open-source project management tool. The vulnerability lives in the verifyState() method of its OIDC login flow, which unconditionally returns true — meaning it never actually checks the state parameter. An attacker can craft a malicious callback URL carrying an attacker-controlled authorization code, trigger the login flow against a victim, and end up with the victim authenticated into the attacker's session. That's textbook session fixation.

This is a foundational OIDC implementation error. The state parameter exists for exactly one reason: to bind an authorization request to a specific user session and prevent cross-site request forgery during the OAuth/OIDC callback. When you skip that check entirely — not misconfigure it, skip it — you've removed the only thing standing between a crafted redirect and a full login CSRF. If your org runs Leantime with SSO enabled, your identity provider's MFA and conditional access policies don't save you here. The attacker never needs to authenticate at your IdP at all.

What makes this particularly worth flagging for IAM practitioners is that it's not a misconfiguration on the IdP side — it's a broken relying party. This is the category of bug that won't show up in your IdP's logs looking suspicious, because from the IdP's perspective, the authorization code exchange looks legitimate. The evil is entirely in what Leantime does after it gets the callback. Standard IdP-side controls won't catch it.

If you're running Leantime in your environment, check whether OIDC login is enabled — if it is, treat this as a critical exposure until a patched version is confirmed deployed. Beyond Leantime specifically, this is a good prompt to audit any internally built or less-scrutinized OIDC relying party integrations you own. The question to ask your team: does our verifyState equivalent actually compare the returned state value against what was stored in session before the redirect? If nobody can answer that without reading the code, that's your answer.

On Monday, pull the list of apps in your environment that implement their own OIDC callback handling rather than delegating it to a vetted library or middleware. Prioritize any that are internally developed or small open-source projects that haven't had a recent security audit. For Leantime specifically, if you can't patch immediately, disabling OIDC login and falling back to an alternative auth method is the right call — leaving session fixation open on a project management tool that likely holds sensitive roadmap and personnel data isn't a risk worth carrying.