Total
5 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-23647 | 1 Goauthentik | 1 Authentik | 2024-02-06 | N/A | 8.8 HIGH |
| Authentik is an open-source Identity Provider. There is a bug in our implementation of PKCE that allows an attacker to circumvent the protection that PKCE offers. PKCE adds the code_challenge parameter to the authorization request and adds the code_verifier parameter to the token request. Prior to 2023.8.7 and 2023.10.7, a downgrade scenario is possible: if the attacker removes the code_challenge parameter from the authorization request, authentik will not do the PKCE check. Because of this bug, an attacker can circumvent the protection PKCE offers, such as CSRF attacks and code injection attacks. Versions 2023.8.7 and 2023.10.7 fix the issue. | |||||
| CVE-2023-48228 | 1 Goauthentik | 1 Authentik | 2024-02-05 | N/A | 9.8 CRITICAL |
| authentik is an open-source identity provider. When initialising a oauth2 flow with a `code_challenge` and `code_method` (thus requesting PKCE), the single sign-on provider (authentik) must check if there is a matching and existing `code_verifier` during the token step. Prior to versions 2023.10.4 and 2023.8.5, authentik checks if the contents of `code_verifier` is matching only when it is provided. When it is left out completely, authentik simply accepts the token request with out it; even when the flow was started with a `code_challenge`. authentik 2023.8.5 and 2023.10.4 fix this issue. | |||||
| CVE-2024-21637 | 1 Goauthentik | 1 Authentik | 2024-02-05 | N/A | 5.4 MEDIUM |
| Authentik is an open-source Identity Provider. Authentik is a vulnerable to a reflected Cross-Site Scripting vulnerability via JavaScript-URIs in OpenID Connect flows with `response_mode=form_post`. This relatively user could use the described attacks to perform a privilege escalation. This vulnerability has been patched in versions 2023.10.6 and 2023.8.6. | |||||
| CVE-2023-36456 | 1 Goauthentik | 1 Authentik | 2024-02-04 | N/A | 7.3 HIGH |
| authentik is an open-source Identity Provider. Prior to versions 2023.4.3 and 2023.5.5, authentik does not verify the source of the X-Forwarded-For and X-Real-IP headers, both in the Python code and the go code. Only authentik setups that are directly accessible by users without a reverse proxy are susceptible to this. Possible spoofing of IP addresses in logs, downstream applications proxied by (built in) outpost, IP bypassing in custom flows if used. This poses a possible security risk when someone has flows or policies that check the user's IP address, e.g. when they want to ignore the user's 2 factor authentication when the user is connected to the company network. A second security risk is that the IP addresses in the logfiles and user sessions are not reliable anymore. Anybody can spoof this address and one cannot verify that the user has logged in from the IP address that is in their account's log. A third risk is that this header is passed on to the proxied application behind an outpost. The application may do any kind of verification, logging, blocking or rate limiting based on the IP address, and this IP address can be overridden by anybody that want to. Versions 2023.4.3 and 2023.5.5 contain a patch for this issue. | |||||
| CVE-2023-26481 | 1 Goauthentik | 1 Authentik | 2024-02-04 | N/A | 6.5 MEDIUM |
| authentik is an open-source Identity Provider. Due to an insufficient access check, a recovery flow link that is created by an admin (or sent via email by an admin) can be used to set the password for any arbitrary user. This attack is only possible if a recovery flow exists, which has both an Identification and an Email stage bound to it. If the flow has policies on the identification stage to skip it when the flow is restored (by checking `request.context['is_restored']`), the flow is not affected by this. With this flow in place, an administrator must create a recovery Link or send a recovery URL to the attacker, who can, due to the improper validation of the token create, set the password for any account. Regardless, for custom recovery flows it is recommended to add a policy that checks if the flow is restored, and skips the identification stage. This issue has been fixed in versions 2023.2.3, 2023.1.3 and 2022.12.2. | |||||