Overview

Drupal is an open-source content management system known for its flexibility, robust features, and strong community support. Organizations of all sizes use it to build and manage dynamic websites and web applications.

TFA Basic Plugins extends Drupal 7 two-factor authentication workflows, including application setup and recovery code management. The module has an authorization-scope weakness in which sensitive TFA setup or recovery routes could be reached for other users under overly broad access checks.

Broken Access Control occurs when an application fails to properly enforce restrictions on what authenticated users are allowed to do, enabling attackers to access unauthorized functionality, data, or resources. It often stems from inadequate validation of user permissions, allowing someone to bypass intended security boundaries and perform actions beyond their assigned role.

Any of the following ramifications are possible:

Allowing arbitrary code execution
Complete system compromise
Data theft or exposure
Data manipulation or destruction
Privilege escalation, and
Denial of service.

This issue affects versions of the module from 7.1.0 through 7.1.2 (inclusive).

‍

Details

Module Info

Product: Drupal 7
Affected packages: TFA Basic Plugins module (support module for the TFA module)
Affected versions: >=7.1.0 <=7.1.2
Repository: https://git.drupalcode.org/project/tfa_basic
Project Page: https://www.drupal.org/project/tfa_basic
Package manager: composer
Fixed in: TFA Basic NES 7.1.3

‍

Vulnerability Info

This low-severity vulnerability is found in all versions of the Drupal TFA Basic module for Drupal 7 sites.

In affected versions before TFA Basic Plugins NES 7.1.3, the code used route access logic that let users with administer users act on another account’s TFA setup flows. Cross-account requests to /user/{uid}/security/tfa/app-setup, /recovery-codes, and /recovery-codes-list could succeed when they should be denied. This is broken access control in TFA setup and recovery.

The impact is that a privileged user could modify another user’s TFA enrollment or recovery state, and potentially access recovery-related data. Even with high privileges required, this breaks expected per-user isolation for authentication factors. Version 7.1.3 fixes this by restricting setup and recovery actions to the account owner and limiting admin access to intended admin paths.

‍

Steps To Reproduce

1. Create a Drupal 7 installation and install a TFA Basic module version that is vulnerable to the exploit, such as 7.1.2; (you will also need TFA, a dependency of TFA Basic).

‍

2. Enable the TFA and TFA Basic modules.

‍

3. To use the QR Library:

cd sites/all/modules/contrib/tfa_basic/includes/
git clone https://github.com/davidshimjs/qrcodejs.git

‍

The qrcode.min.js file should be at tfa_basic/includes/qrcodejs/qrcode.min.js.

4. Go to admin/config/people/tfa and:

Enable TFA.
Set Default validation plugin to TOTP (TFA Basic).
Enable Recovery codes as a fallback.

‍

5. Create two distinct users:

User A (Admin; attacker role): Has the administer users permission.
User B (Target): Create a non-admin role (for example, "TFA User") that grants "Set up TFA for account" permission and does not grant "Administer users". Assign this role to User B.
Record User B's UID from /user/<uid> for use in the test URLs.

‍

6. Target user baseline setup:

Log in as User B.
Navigate to user/[uid for User B]/security/tfa/app-setup.
You will be challenged for User B's password.
Complete the TOTP setup (scan QR code, verify seed).
Note: This ensures User B has active secrets to be accessed.

‍

7. Reproduce the vulnerability:

Log in as User A (Admin) and provide User A's password when challenged below.
Navigate to the Target User’s setup routes:
- Route 1 (App Setup): user/[uid for user B]/security/tfa/app-setup
- Route 2 (Recovery Codes): user/[uid for user B]/security/tfa/recovery-codes
- Route 3 (Recovery List): user/[uid for user B]/security/tfa/recovery-codes-list

‍

8. Actual Behavior (Affected): The Admin is granted access to these pages (Status 200). By entering their own password at the prompt, they can view User B's TOTP seed/QR code or capture their recovery codes, effectively bypassing the security boundary of User B's second factor.

‍

9. Verify the fix:

Install the NES version of the module (7.1.3)
Attempt to access the same routes as User A (Admin).
The routes in Step 7 must now return a 403 Access Denied status.
Specifically, tfa_basic_setup_access should now strictly enforce that only the account owner (or a system-level bypass) can view these secret-bearing pages.

‍

Addressing the Issue

Temporarily hard-block vulnerable routes until the module is patched or upgraded (at the WAF layer).
Restrict administer users and TFA setup permissions to minimum trusted roles only.
If patching is delayed, disable vulnerable TFA setup/recovery flows temporarily.
Sign up for post-EOL security support; HeroDevs customers get immediate access to a patched version of this module.

‍