Ory Kratos's `highest_available` setting does not properly respect code + mfa credentials
Key facts
- Attack vector
- Network
- Privileges required
- High
- User interaction
- None
- Attack complexity
- High
- Impact type
- Security bypass
- Confidentiality · integrity · availability
- High · None · None
- Fix status
- Fixed
Attack profile from CVSS 3.1 · CNA. Fix status from CNA and GitHub. Impact type from CWE-287.
Summary
Ory Kratos is an identity, user management and authentication system for cloud services. Prior to version 1.3.0, given a number of preconditions, the `highest_available` setting will incorrectly assume that the identity’s highest available AAL is `aal1` even though it really is `aal2`. This means that the `highest_available` configuration will act as if the user has only one factor set up, for that particular user. This means that they can call the settings and whoami endpoint without a `aal2` session, even though that should be disallowed. An attacker would need to steal or guess a valid login OTP of a user who has only OTP for login enabled and who has an incorrect `available_aal` value stored, to exploit this vulnerability. All other aspects of the session (e.g. the session’s aal) are not impacted by this issue. On the Ory Network, only 0.00066% of registered users were affected by this issue, and most of those users appeared to be test users. Their respective AAL values have since been updated and they are no longer vulnerable to this attack. Version 1.3.0 is not affected by this issue. As a workaround, those who require MFA should disable the passwordless code login method. If that is not possible, check the sessions `aal` to identify if the user has `aal1` or `aal2`.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| ory | kratos | before 1.3.0 | 1.3.0 | Patch available | CNA |
| — | github.com/ory/kratos (Go) | before 1.3.0 | 1.3.0 | Patch available | GHSA-wc43-73w7-x2f5 |
- kratos Vendorory Affected before 1.3.0 Fixed in 1.3.0 Patch available CNA
- github.com/ory/kratos (Go) Vendor— Affected before 1.3.0 Fixed in 1.3.0 Patch available GHSA-wc43-73w7-x2f5
Remediation
- Fix · CNA kratos (ory) Fixed in 1.3.0
- Fix · GHSA-wc43-73w7-x2f5 github.com/ory/kratos (Go) Fixed in 1.3.0 Advisory →
Timeline
- 2026-10-02 Threatist record created from CVE-2024-45042
- 2026-10-03 Alias added: GHSA-wc43-73w7-x2f5
References
More ory vulnerabilities
- TI-2026-25890 Ory Oathkeeper has a path traversal authorization bypass CVSS 3.1CRITICAL 10.0
- TI-2026-25902 DOM-Based XSS in Ory Polis Login Page CVSS 3.1HIGH 8.8
- TI-2020-11995 Ignored storage errors on token revokation in ORY Fosite CVSS 3.1HIGH 8.0
- TI-2020-11994 Replay of private_key_jwt possible in ORY Fosite CVSS 3.1HIGH 8.1
- TI-2021-12369 Possible bypass of token claim validation when OAuth2 Introspection caching is enabled CVSS 3.1HIGH 7.5
- TI-2026-25892 Ory Oathkeeper has an authentication bypass by cache key confusion CVSS 3.1HIGH 8.1
Sources
- CVE-2024-45042 · CVE Program
- CVE-2024-45042 · NVD
- FIRST EPSS
- GHSA-wc43-73w7-x2f5 · GitHub Advisory Database · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences