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 only enable the password stage 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:
efpi-bot Reporter
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 only enable the password stage 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:
AUTHENTIK_LISTEN__TRUSTED_PROXY_CIDRSis not configured properly)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: