website: latest migration to new structure (#11522)

* first pass

* dependency shenanigans

* move blueprints

* few broken links

* change config the throw errors

* internal file edits

* fighting links

* remove sidebarDev

* fix subdomain

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* fix relative URL

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* fix mismatched package versions

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* fix api reference build

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* test tweak

* links hell

* more links hell

* links hell2

* yep last of the links

* last broken link fixed

* re-add cves

Signed-off-by: Jens Langhammer <jens@goauthentik.io>

* add devdocs redirects

* add dir

* tweak netlify.toml

* move latest 2 CVES into dir

* fix links to moved cves

* typoed title fix

* fix link

* remove banner

* remove committed api docs

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* integrations: remove version dropdown

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* Update Makefile

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* change doc links in web as well

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* fix some more docs paths

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* fix more docs paths

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* ci: require ci-web.build for merging

Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

* Revert "ci: require ci-web.build for merging"

This reverts commit b99a4842a9.

* remove sluf for Application

* put slug back in

* minor fix to trigger deploy

---------

Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Signed-off-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>
Co-authored-by: Tana M Berry <tana@goauthentik.com>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Marc 'risson' Schmitt <marc.schmitt@risson.space>

website/docs/security/cves/CVE-2022-23555.md

@@ -0,0 +1,31 @@
+# CVE-2022-23555
+
+_Reported by [@fuomag9](https://github.com/fuomag9)_
+
+## Token reuse in invitation URLs leads to access control bypass via the use of a different enrollment flow
+
+### Summary
+
+Token reuse in invitation URLs leads to access control bypass via the use of a different enrollment flow than in the one provided.
+
+### Patches
+
+authentik 2022.11.4, 2022.10.4 and 2022.12.0 fix this issue, for other versions the workaround can be used.
+
+### Impact
+
+Only configurations using both invitations and have multiple enrollment flows with invitation stages that grant different permissions are affected. The default configuration is not vulnerable, and neither are configurations with a single enrollment flow.
+
+### Details
+
+The vulnerability allows an attacker that knows different invitation flows names (e.g. `enrollment-invitation-test` and `enrollment-invitation-admin`) via either different invite links or via brute forcing to signup via a single invitation url for any valid invite link received (it can even be a url for a third flow as long as it's a valid invite) as the token used in the `Invitations` section of the Admin interface does NOT change when a different `enrollment flow` is selected via the interface and it is NOT bound to the selected flow, so it will be valid for any flow when used.
+
+### Workarounds
+
+As a workaround, fixed data can be added to invitations which can be checked in the flow to deny requests. Alternatively, an identifier with high entropy (like a UUID) can be used as flow slug, mitigating the attack vector by exponentially decreasing the possibility of discovering other flows.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2022-46145.md

@@ -0,0 +1,21 @@
+# CVE-2022-46145
+
+_Reported by [@sdimovv](https://github.com/sdimovv)_
+
+## Unauthorized user creation and potential account takeover
+
+### Impact
+
+With the default flows, unauthenticated users can create new accounts in authentik. If a flow exists that allows for email-verified password recovery, this can be used to overwrite the email address of admin accounts and take over their accounts
+
+### Patches
+
+authentik 2022.11.2 and 2022.10.2 fix this issue, for other versions the workaround can be used.
+
+### Workarounds
+
+A policy can be created and bound to the `default-user-settings-flow` flow with the following contents
+
+```python
+return request.user.is_authenticated
+```

website/docs/security/cves/CVE-2022-46172.md

@@ -0,0 +1,27 @@
+# CVE-2022-46172
+
+_Reported by [@DreamingRaven](https://github.com/DreamingRaven)_
+
+## Existing Authenticated Users can Create Arbitrary Accounts
+
+### Summary
+
+Any authenticated user can create an arbitrary number of accounts through the default flows. This would circumvent any policy in a situation where it is undesirable for users to create new accounts by themselves. This may also have carry over consequences to other applications being how these new basic accounts would exist throughout the SSO infrastructure. By default the newly created accounts cannot be logged into as no password reset exists by default. However password resets are likely to be enabled by most installations.
+
+### Patches
+
+authentik 2022.11.4, 2022.10.4 and 2022.12.0 fix this issue.
+
+### Impact
+
+This vulnerability could make it much easier for name and email collisions to occur, making it harder for user to log in. This also makes it more difficult for admins to properly administer users since more and more confusing users will exist. This paired with password reset flows if enabled would mean a circumvention of on-boarding policies. Say for instance a company wanted to invite a limited number of beta testers, those beta testers would be able to create an arbitrary number of accounts themselves.
+
+### Details
+
+This vulnerability has already been submitted over email, this security advisory serves as formalization towards broader information dissemination. This vulnerability pertains to the user context used in the default-user-settings-flow. /api/v3/flows/instances/default-user-settings-flow/execute/
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2023-26481.md

@@ -0,0 +1,27 @@
+# CVE-2023-26481
+
+_Reported by [@fuomag9](https://github.com/fuomag9)_
+
+## Insufficient user check in FlowTokens by Email stage
+
+### Summary
+
+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.
+
+### Patches
+
+authentik 2022.12.3, 2023.1.3, 2023.2.3 fix this issue.
+
+### Impact
+
+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.
+
+### Workaround
+
+It is recommended to upgrade to the patched version of authentik. Regardless, for custom recovery flows it is recommended to add a policy that checks if the flow is restored, and skips the identification stage.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2023-36456.md

@@ -0,0 +1,21 @@
+# CVE-2023-36456
+
+_Reported by [@thijsa](https://github.com/thijsa)_
+
+## Lack of Proxy IP headers validation
+
+### Summary
+
+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.
+
+### Impact
+
+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.
+
+### Details
+
+This poses a possible security risk when you have flows or policies that check the user's IP address, e.g. when you want to ignore the user's 2 factor authentication when the user is connected to the company network.
+
+Another security risk is that the IP addresses in the logfiles and user sessions is not reliable anymore, anybody can spoof this address and you cannot verify that the user has logged in from the IP address that is in their account's log.
+
+And the 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.

website/docs/security/cves/CVE-2023-39522.md

@@ -0,0 +1,27 @@
+# CVE-2023-39522
+
+_Reported by [@markrassamni](https://github.com/markrassamni)_
+
+## Username enumeration attack
+
+### Summary
+
+Using a recovery flow with an identification stage an attacker is able to determine if a username exists.
+
+### Patches
+
+authentik 2023.5.6 and 2023.6.2 fix this issue.
+
+### Impact
+
+Only setups configured with a recovery flow are impacted by this.
+
+### Details
+
+An attacker can easily enumerate and check users' existence using the recovery flow, as a clear message is shown when a user doesn't exist. Depending on configuration this can either be done by username, email, or both.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2023-48228.md

@@ -0,0 +1,61 @@
+# CVE-2023-48228
+
+_Reported by [@Sapd](https://github.com/Sapd)_
+
+## OAuth2: Insufficient PKCE check
+
+### Summary
+
+When initialising a OAuth2 flow with a `code_challenge` and `code_method` (thus requesting PKCE), the SSO provider (authentik) **must** check if there is a matching **and** existing `code_verifier` during the token step.
+
+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`.
+
+### Patches
+
+authentik 2023.8.5 and 2023.10.4 fix this issue.
+
+### Details
+
+The `code_verifier` is only checked when the user provides it. Note that in line 209 there is a check if the code_parameter is left out. But there is no check if the PKCE parameter simply was omitted WHEN the request was started with a `code_challenge_method`.
+
+This oversight likely did not stem from a coding error but from a misinterpretation of the RFC, where the backward compatibility section may be somewhat confusing.
+https://datatracker.ietf.org/doc/html/rfc7636#section-4.5
+RFC7636 explicitly says in Section 4.5:
+
+> The "code_challenge_method" is bound to the Authorization Code when
+> the Authorization Code is issued. That is the method that the token
+> endpoint MUST use to verify the "code_verifier".
+
+Section 5, Compatibility
+
+> Server implementations of this specification MAY accept OAuth2.0
+> clients that do not implement this extension. If the "code_verifier"
+> is not received from the client in the Authorization Request, servers
+> supporting backwards compatibility revert to the OAuth 2.0 [[RFC6749](https://datatracker.ietf.org/doc/html/rfc6749)]
+> protocol without this extension.
+
+Section 5, Compatibility, allows server implementations of this specification to accept OAuth 2.0 clients that do not implement this extension. However, if a `code_verifier` is not received from the client in the Authorization Request, servers that support backward compatibility should revert to the standard OAuth 2.0 protocol sans this extension (including all steps).
+
+It should be noted that this does not mean that the `code_verifier` check can be disregarded at any point if the initial request included `code_challenge` or `code_challenge_method`. Since Authentik supports PKCE, it **MUST** verify the code_verifier as described in Section 4.5 **AND** fail if it was not provided.
+
+Ofc verification can be skipped if the original authorization request did not invoke PKCE (no `code_challenge_method` and no `code_challenge`).
+
+Failure to check the `code_verifier` renders the PKCE flow ineffective. This vulnerability particularly endangers public or hybrid clients, as their `code` is deemed non-confidential.
+
+While not explicitly stated in the standard, it is generally recommended that OAuth2 flows accepting public clients should enforce PKCE - at least when redirecting to a non HTTPS URL (like http or an app link).
+
+### Impact
+
+The vulnerability poses a high risk to both public and hybrid clients.
+When for example a mobile app implements oauth2, a malicious app can simply also register the same in-app-link (e.g. `mycoolapp://oauth2`) for the redirect callback URL, possibly receiving `code` during callback. With PKCE working, a malicious app would still receive a `code` but the `code` would not work without the correct unhashed code-challenge.
+This is especially problematic, because authentik claims to support PKCE, and a developer can expect that the proper checks are in place. Note that app-links cannot be protected by HTTPS or similar mechanisms.
+
+Note also that this vulnerability poses a threat to confidential clients. Many confidential clients act as a proxy for OAuth2 API requests, typically from mobile apps or single-page applications. These proxies relay `code_challenge`, `code_challenge_method` (in auth request, which most libraries force and provide on default settings) and `code_verifier` in the token request unchanged and supplement the CLIENT_SECRET which only the relay knows. The relay can but does not have to check for an existing `code_verifier` as the standard does not define that PKCE can be ignored on confidential clients during the token request when the client requested PKCE during the authorization request.
+
+An attacker could potentially gain full access to the application. If the code grants access to an admin account, the confidentiality, integrity, and availability of that application are compromised.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2024-21637.md

@@ -0,0 +1,39 @@
+# CVE-2024-21637
+
+_Reported by [@lauritzh](https://github.com/lauritzh)_
+
+## XSS in Authentik via JavaScript-URI as Redirect URI and form_post Response Mode
+
+### Summary
+
+Given an OAuth2 provider configured with allowed redirect URIs set to `*` or `.*`, an attacker can send an OAuth Authorization request using `response_mode=form_post` and setting `redirect_uri` to a malicious URI, to capture authentik's session token.
+
+### Patches
+
+authentik 2023.8.6 and 2023.10.6 fix this issue.
+
+### Impact
+
+The impact depends on the attack scenario. In the following I will describe the two scenario that were identified for Authentik.
+
+#### Redirect URI Misconfiguration
+
+While advising that this may cause security issues, Authentik generally allows wildcards as Redirect URI. Therefore, using a wildcard-only effectively allowing arbitrary URLS is possible misconfiguration that may be present in real-world instances.
+
+In such cases, unauthenticated and unprivileged attackers can perform the above described actions.
+
+### User with (only) App Administration Permissions
+
+A more likely scenario is an administrative user (e.g. a normal developer) having only permissions to manage applications.
+
+This relatively user could use the described attacks to perform a privilege escalation.
+
+### Workaround
+
+It is recommended to upgrade to the patched version of authentik. If not possible, ensure that OAuth2 providers do not use a wildcard (`*` or `.*`) value as allowed redirect URI setting. (This is _not_ exploitable if part of the redirect URI has a wildcard, for example `https://foo-.*\.bar\.com`)
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2024-23647.md

@@ -0,0 +1,27 @@
+# CVE-2024-23647
+
+_Reported by [@pieterphilippaerts](https://github.com/pieterphilippaerts)_
+
+## PKCE downgrade attack in authentik
+
+## Summary
+
+PKCE is a very important countermeasure in OAuth2 , both for public and confidential clients. It protects against CSRF attacks and code injection attacks. Because of this bug, an attacker can circumvent the protection PKCE offers.
+
+## Patches
+
+authentik 2023.8.7 and 2023.10.7 fix this issue.
+
+## Details
+
+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. We recently fixed a downgrade attack (in v2023.8.5 and 2023.10.4) where if the attacker removed the `code_verifier` parameter in the token request, authentik would allow the request to pass, thus circumventing PKCE’s protection. However, in the latest version of the software, another downgrade scenario is still possible: if the attacker removes the `code_challenge’ parameter from the authorization request, authentik will also not do the PKCE check.
+
+Note that this type of downgrade enables an attacker to perform a code injection attack, even if the OAuth client is using PKCE (which is supposed to protect against code injection attacks). To start the attack, the attacker must initiate the authorization process without that `code_challenge` parameter in the authorization request. But this is easy to do (just use a phishing site or email to trick the user into clicking on a link that the attacker controls – the authorization link without that `code_challenge` parameter).
+
+The OAuth BCP (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics) explicitly mentions this particular attack in section 2.1.1: “Authorization servers MUST mitigate PKCE Downgrade Attacks by ensuring that a token request containing a code_verifier parameter is accepted only if a code_challenge parameter was present in the authorization request, see Section 4.8.2 for details.”
+
+## For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2024-37905.md

@@ -0,0 +1,27 @@
+# CVE-2024-37905
+
+_Reported by [@m2a2](https://github.com/m2a2)_
+
+## Improper Authorization for Token modification
+
+### Summary
+
+Due to insufficient permission checks it was possible for any authenticated user to elevate their permissions to a superuser by creating an API token and changing the user the token belonged to.
+
+### Patches
+
+authentik 2024.6.0, 2024.4.3 and 2024.2.4 fix this issue, for other versions the workaround can be used.
+
+### Details
+
+By setting a token's user ID to the ID of a higher privileged user, the token will inherit the higher privileged access to the API. This can be used to change the password of the affected user or to modify the authentik configuration in a potentially malicious way.
+
+### Workarounds
+
+As a workaround it is possible to block any requests to `/api/v3/core/tokens*` at the reverse-proxy/load-balancer level. Doing so prevents this issue from being exploited.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2024-38371.md

@@ -0,0 +1,23 @@
+# CVE-2024-38371
+
+_Reported by Stefan Zwanenburg_
+
+## Insufficient access control for OAuth2 Device Code flow
+
+### Impact
+
+Due to a bug, access restrictions assigned to an application were not checked when using the OAuth2 Device code flow. This could potentially allow users without the correct authorization to get OAuth tokens for an application, and access the application.
+
+### Patches
+
+authentik 2024.6.0, 2024.4.3 and 2024.2.4 fix this issue, for other versions the workaround can be used.
+
+### Workarounds
+
+As authentik flows are still used as part of the OAuth2 Device code flow, it is possible to add access control to the configured flows.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2024-42490.md

@@ -0,0 +1,31 @@
+# CVE-2024-42490
+
+_Reported by [@m2a2](https://github.com/m2a2)_
+
+## Insufficient Authorization for several API endpoints
+
+### Summary
+
+Several API endpoints can be accessed by users without correct authentication/authorization.
+
+The main API endpoints affected by this:
+
+-   `/api/v3/crypto/certificatekeypairs/<uuid>/view_certificate/`
+-   `/api/v3/crypto/certificatekeypairs/<uuid>/view_private_key/`
+-   `/api/v3/.../used_by/`
+
+Note that all of the affected API endpoints require the knowledge of the ID of an object, which especially for certificates is not accessible to an unprivileged user. Additionally the IDs for most objects are UUIDv4, meaning they are not easily guessable/enumerable.
+
+### Patches
+
+authentik 2024.4.4, 2024.6.4 and 2024.8.0 fix this issue.
+
+### Workarounds
+
+Access to the API endpoints can be blocked at a Reverse-proxy/Load balancer level to prevent this issue from being exploited.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2024-47070.md

@@ -0,0 +1,35 @@
+# CVE-2024-47070
+
+_Reported by [@efpi-bot](https://github.com/efpi-bot) from [LogicalTrust](https://logicaltrust.net/en/)_
+
+## Password authentication bypass via X-Forwarded-For HTTP header
+
+### Summary
+
+The vulnerability allows bypassing policies by adding X-Forwarded-For header with unparsable IP address, e.g. "a". This results in a possibility to authenticate/authorize to any account with known login or email address.
+
+Since the default authentication flow uses a policy to enable the password stage only when there is no password stage selected on the Identification stage, this vulnerability can be used to skip this policy and continue without the password stage.
+
+### Am I affected
+
+This can be exploited for the following configurations:
+
+-   An attacker can access authentik without a reverse proxy (and `AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRS` is not configured properly)
+-   The reverse proxy configuration does not correctly overwrite X-Forwarded-For
+-   Policies (User and group bindings do _not_ apply) are bound to authentication/authorization flows
+
+### Patches
+
+authentik 2024.6.5 and 2024.8.3 fix this issue.
+
+### Workarounds
+
+Ensure the X-Forwarded-For header is always set by the reverse proxy, and is always set to a correct IP.
+
+In addition you can manually change the _Failure result_ option on policy bindings to _Pass_, which will prevent any stages from being skipped if a malicious request is received.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/CVE-2024-47077.md

@@ -0,0 +1,25 @@
+# CVE-2024-47077
+
+_Reported by [@quentinmit](https://github.com/quentinmit)_
+
+## Insufficient cross-provider token validation during introspection
+
+### Summary
+
+Access tokens issued to one application can be stolen by that application and used to impersonate the user against any other proxy provider. Also, a user can steal an access token they were legitimately issued for one application and use it to access another application that they aren't allowed to access.
+
+### Details
+
+The proxy provider uses `/application/o/introspect/` to validate bearer tokens provided in the `Authorization` header:
+
+The implementation of this endpoint separately validates the `client_id` and `client_secret` (which are that of the proxy provider) and the `token` without validating that they correspond to the same provider.
+
+### Patches
+
+authentik 2024.6.5 and 2024.8.3 fix this issue.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)

website/docs/security/cves/GHSA-rjvp-29xq-f62w.md

@@ -0,0 +1,27 @@
+# GHSA-rjvp-29xq-f62w
+
+_Reported by [@devSparkle](https://github.com/devSparkle)_
+
+## Potential Installation takeover when default admin user is deleted
+
+### Summary
+
+In the affected versions, when the default admin user has been deleted, it is potentially possible for an attacker to set the password of the default admin user without any authentication.
+
+### Patches
+
+authentik 2023.8.4 and 2023.10.2 fix this issue, for other versions the workaround can be used.
+
+### Impact
+
+authentik uses a blueprint to create the default admin user, which can also optionally set the default admin users' password from an environment variable. When the user is deleted, the `initial-setup` flow used to configure authentik after the first installation becomes available again.
+
+### Workarounds
+
+Ensure the default admin user (Username `akadmin`) exists and has a password set. It is recommended to use a very strong password for this user, and store it in a secure location like a password manager. It is also possible to deactivate the user to prevent any logins as akadmin.
+
+### For more information
+
+If you have any questions or comments about this advisory:
+
+-   Email us at [security@goauthentik.io](mailto:security@goauthentik.io)