2FA Bypass and Deactivation Attack in MyTaag

written by Pius Walter
03 · 04 · 2025

Abstract

This blog post delves into critical security vulnerabilities found in MyTaag, a popular digital business card platform used by over 70,000 professionals worldwide. Specifically, the post highlights two major weaknesses in MyTaag’s two-factor authentication (2FA) mechanism: a 2FA bypass attack (CVE-2025-25451) and a 2FA deactivation attack (CVE-2025-25450). The first vulnerability allows attackers to bypass 2FA altogether by manipulating data stored in the browser’s Local Storage, while the second vulnerability enables attackers to deactivate 2FA entirely through API requests, leaving user accounts unprotected. In addition to these flaws, the post also touches on issues such as insecure password storage using SHA-1 (CVE-2025-25452) and insecure handling of session tokens, which further compromise user security. Through a detailed analysis of the technical aspects of these vulnerabilities, the post underscores the significant risks they pose to MyTaag users and the importance of robust security practices in online platforms.

What is MyTaag?

MyTaag is a digital business card platform designed to help users create, manage, and share their professional identity online. With MyTaag, you can easily create a personalized digital business card in just a few minutes and start networking right away. The platform offers real-time updates, allowing you to modify your contact information, links, and social media profiles instantly. MyTaag also supports an unlimited number of links, enabling you to showcase all your important contact details, portfolios, and online presence on a single, easily accessible card. Trusted by over 70,000 customers across more than 70 countries, MyTaag has become a powerful tool for professionals worldwide, helping them streamline their networking and efficiently share their digital identity.

„Erstelle Sie Ihre digitale Visitenkarte in 2 Minuten und fangen Sie direkt an sich zu vernetzen […] Änderen Sie die Informationen Ihrer digitalen Visitenkarte in Echtzeit […] Fügen Sie unendlich viele Kontaktinformationen, Social Media Profile und Links zu Ihrer Visitenkarte hinzu“

https://mytaag.com/pages/features

Vulnerabilities in MyTaag

MyTaag contains two critical vulnerabilities related to its two-factor authentication (2FA) mechanism. The first vulnerability allows attackers to bypass 2FA entirely, granting unauthorized access to user accounts without requiring the second factor (CVE-2025-25451). The second vulnerability is even more severe, as it enables attackers to completely disable the 2FA mechanism, leaving user accounts unprotected (CVE-2025-25450). This post will first explore the 2FA Bypass Attack, followed by the Deactivation Attack, highlighting the technical details and potential risks associated with both issues.

2FA Bypass Attack in MyTaag (CVE-2025-25451)

The initial situation involves a user account with two-factor authentication (2FA) enabled.

MyTaag account with activated 2FA

When the MyTaag website is accessed for the first time, the following data records are created in the browser’s Local Storage.

Data in the browser’s Local Storage after first website visit

The attacker must first obtain the victim’s login credentials to carry out the attack. Various methods, such as phishing, can be used to acquire this information. Once in possession of the victim’s email address and password, the attacker can log in to the account.

Data in the browser’s Local Storage before logging in

After clicking „Anmelden“ and completing the login process, additional data records are created in the browser’s Local Storage. Of particular interest is the first entry, 2fa_authorized, which has a value of 0, indicating that the second factor has not yet been authenticated. In the browser, the prompt for entering the 6-digit verification code is displayed.

Data in the browser’s Local Storage after logging in with email address and password

Instead of entering the verification code, which the attacker does not have access to, the value of 2fa_authorized stored in the Local Storage can simply be changed from 0 to 1.

Updated value of 2fa_authorized in the browser’s Local Storage

After reloading the website, the manually updated value is read from Local Storage. Since it is set to 1, the system assumes that the second factor has been correctly entered, and the victim’s account is granted access.

User account of the victim without entering the second factor

In reality, however, the weakness is much more profound. The cause of the issue is explained in more detail below.

2FA Deactivation Attack in MyTag (CVE-2025-25450)

The starting point here is also a user account with two-factor authentication (2FA) enabled.

To understand the attack, the network traffic during the login process must be analyzed.

MyTaag account with activated 2FA

When logging in with email address and password, a POST request is sent to https://api.taag.co/session. This request contains the email address (form data key email), the password, and the origin of the request, which is, in this case, web. Presumably, app would appear as the origin when a login is performed through the MyTaag app.

Request of the login to the API endpoint

The response contains a session token (form data key session_token) and other parameters that are not directly relevant to the attack (e.g. form data keys id, user_id and web_redirect). However, this is where the vulnerability lies. A valid session token is returned, which grants access to modify user settings. This token can then be used in the next step to target the MyTaag API endpoint and deactivate 2FA for the user account.

Response from the login API endpoint

This is accomplished using the deactivate-2fa.py Python script. You will find the source code afterwards.

Running the Python script for deactivating 2FA

As a result, it becomes possible to log in without the need for 2FA, and the deactivated 2FA status is reflected in the account settings.

Deactivated 2FA in the MyTaag user account settings

Source Code of the 2FA Deactivation Script

The script consists of two main components: the login function and the request in the main function that deactivates the 2FA setting. The login function sends a request to the API to obtain a new session token using the email address and password. This token is valid for the user and allows them to modify settings. In the main function, the token is then used to send a PUT request that updates the user settings to deactivate 2FA.

#!/usr/bin/env python3

import requests
from getpass import getpass


def login(username, password):
  body = {
    "email": username,
    "password": password,
    "origin": "web"
  }
  res = requests.post("https://api.taag.co/session", body)
  return res.json()["session_token"]


if __name__ == "__main__":
  print("For which user account do you want to deactivate 2FA?")
  username = input("username: ")
  password = getpass("password: ")

  session_token = login(username, password)

  body = {
    "session_token": session_token,
    "field": "2fa",
    "value": 0
  }

  res = requests.put("https://api.taag.co/user", body)
  
  if res.status_code == 200:
    print("\nIt worked! You can now log in without 2FA.")

Note: This source code is not written according to best practices and is intended solely as a simplified representation of the attack.

Insecure Password Storing in MyTaag (CVE-2025-25452)

After logging in, a user object is returned in response, displaying the user’s data. Upon inspecting the data for the password, it becomes apparent that 5baa61e4c9b93f3f0682250b6cf8331b7ee68fd8 is the SHA-1 hash of the string password.

Of course, SHA-1 is not a secure algorithm for storing passwords, as it has been proven vulnerable to collision attacks.

User object with SHA-1 password hash

Small note: Obviously, the password „password“ was used here solely for demonstration purposes!

Insecure Session Token Handling

There is also room for improvement regarding the session tokens used in API requests. On one hand, these tokens are provided in the URL rather than in the request header. On the other hand, they don’t expire when the user logs out, meaning the session token remains valid even after logout and could potentially be exploited by attackers.

Additional Resources and References


History and Updates

The process and how to contact the BSI CERT and MyTaag team is described below.

11/09/2024 21:50 CET

Reporting vulnerabilities to the German Federal Office for Information Security (Bundesamt für Sicherheit in der Informationstechnik, BSI) to contact the manufacturer and coordinate the Coordinated Vulnerability Disclosure (CVD) process.

11/25/2024 12:43 CET

Confirmation of the vulnerabilities by the manufacturer. A corresponding fix should be available in the next days.

03/04/2025 15:00 CET

Public Disclosure of the vulnerability.


Pius Walter

Pius Walter

Related Posts

Multiple Critical Vulnerabilities in CADClick

Multiple Critical Vulnerabilities in CADClick

This blog post uncovers several critical vulnerabilities within the CADClick web application, including SQL Injection, Reflected XSS, and Local File Inclusion (LFI). These security issues pose significant risks not only to the application itself but also to its customers, potentially compromising sensitive data and operational integrity.

Multiple Vulnerabilities in Feripro

Multiple Vulnerabilities in Feripro

This blog post describes three vulnerabilities in Feripro. These include two Incorrect Access Control vulnerabilities (CVE-2024-41517, CVE-2024-41518) and a Stored Cross-Site Scripting vulnerability (CVE-2024-41519). Feripro is a management software for vacation programs.

Comments

1 Kommentar

  1. Nice catch!

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert