SA-CONTRIB-2026-320: Critical severity composer/drupal/auth_login_plus vulnerability
This module enables you to require a second authentication factor (a time-based one-time password from an authenticator app) when users log in. The module doesn't sufficiently enforce the second factor for authentication providers that authenticate every request on their own. An attacker who knows the password of an account with two-factor authentication enabled can use that account's permissions through routes that accept such a provider, without providing the second factor. This vulnerability is mitigated by the fact that the attacker must know the account's password, a per-request authentication provider (such as the the HTTP Basic Authentication module) must be enabled, and an alternate authentication method (such as JSON:API or REST) must be enabled.
Credit
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/drupal/auth_login_plusto a version that resolves this vulnerability.Fixed in 1.0.3
Event History
Frequently Asked Questions
Which sites are exposed to this issue?
A site is exposed only if it uses this module, has a per-request authentication provider enabled (for example, HTTP Basic Authentication), and has an alternate authentication method enabled (for example, JSON:API or REST).
What does an attacker need to exploit it?
The attacker must know the password for an account that has two-factor authentication enabled. They can then use routes that accept the per-request authentication provider without supplying the time-based one-time password.
Are normal interactive logins affected?
The described bypass applies to authentication providers that authenticate each request independently and to routes accepting those providers. The data does not state that standard interactive login flows bypass the second factor.
What can be done if an update is not immediately available?
Disable per-request authentication providers or alternate authentication methods where operationally feasible, particularly combinations such as HTTP Basic Authentication with JSON:API or REST. This removes conditions identified as necessary for exploitation.