Brief Summary: CVE-2026-49952 — Discuz! X5.0 Authentication Bypass via Cross-Context Cryptographic Key Reuse

Introduction

One line of configuration code shares a cryptographic key between two security contexts, and that is enough to allow pre-authenticated database exfiltration and, when chained with other flaws, full remote code execution on Discuz! X5.0 installations. A public exploit script already exists, and Discuz! is the dominant forum platform across Chinese web infrastructure, so CVE-2026-49952 puts a large number of deployments at risk.

Discuz! is a PHP-based internet forum platform originally developed by Comsenz Technology and acquired by Tencent Holdings in 2010 for more than US$60 million. It is the most popular internet forum software in China, used by most Chinese bulletin board system users. Because it dominates the Chinese market, critical vulnerabilities in Discuz! reach deep into Chinese-language web communities.

Technical Information

Root Cause: Cross-Context Cryptographic Key Reuse (CWE-323)

CVE-2026-49952 falls under CWE-323 (Reusing a Nonce, Key Pair in Encryption), which covers reusing cryptographic keys or nonces that are meant to be used only once or within a single context. The common consequences include letting attackers bypass protection mechanisms, gain privileges, or assume identities through replay or cross-context attacks.

The root cause in Discuz! X5.0 is in /config/config_ucenter.php, where the UC_KEY constant is initialized by directly copying the global authkey setting:

define('UC_KEY', $_config['security']['authkey']);

When Discuz! X5.0 is installed in "standalone mode" (the default configuration), this single line breaks a critical trust boundary. The same cryptographic key now serves two separate purposes: UCenter integration authentication and authorization for the /api/db/dbbak.php database backup API. Tokens generated for one context are accepted in the other, which is what makes the whole exploit chain possible.

The Encryption Oracle in logging_ctl::logging_more()

The logging_ctl::logging_more() method acts as an encryption oracle. When a login request includes the lssubmit parameter, this method encrypts the username parameter value using the global authkey via the authcode() function and reflects the resulting ciphertext back to the client in a JavaScript block.

An attacker exploits this by injecting a crafted command payload into the username parameter. For example, setting the username to:

method=export&time=9999999999&

This causes the application to encrypt what is effectively a database export command with the global authkey and return a valid "authcode" token. Because UC_KEY is identical to the global authkey, the database backup API at dbbak.php accepts this authcode as a legitimate authorization token.

Phase 1: Unauthorized Database Export

With the forged authcode in hand, the attacker sends a request to /api/db/dbbak.php with the method=export command encoded in the token. The dbbak.php script validates the authcode using UC_KEY (the same authkey that encrypted it), accepts it as legitimate, and exports the database backup. This gives unauthenticated access to the full database contents, including administrator credential hashes.

Phase 2: Race Condition for Arbitrary User Impersonation

The attack escalates from database access to user impersonation through a carefully timed race condition:

1. Data Acquisition: The attacker uses the database export to obtain the administrator's MD5 password hash from the exported data.
2. Payload Injection: The attacker registers a new account with a username containing tab-separated injection sequences: ADMIN_MD5_HASH\t1\tRANDOM.
3. Triggering the Race: The attacker initiates a database import via dbbak.php. During the window where the common_member table is dropped but the user still exists in ucenter_members, the attacker sends a login request.
4. Token Acquisition: The application runs authcode() on the malicious username payload and reflects a "session authcode" back to the attacker. This token contains the admin's credentials and allows full account impersonation.

The timing window exists because the database restoration process is not atomic. There is a gap between when common_member is dropped and when the user record is fully reconciled, and during that gap the authentication system falls back to ucenter_members data.

Phase 3: Remote Code Execution via Vulnerability Chaining

Once the race condition grants administrative access, the attacker exploits a separate administrative Local File Inclusion vulnerability (designated KIS-2026-11) to include unintended files and execute arbitrary PHP code on the server. This completes the chain from an anonymous visitor to pre-authenticated Remote Code Execution.

CAPTCHA Bypass Automation

The full attack chain is automated via a Python 3 exploit script (exploit.py) with a supporting OCR inference script (infer.py) that uses a CNN + LSTM + CTC architecture to bypass Discuz! image-based CAPTCHAs (designated KIS-2026-10). The developers had not fixed this CAPTCHA bypass at the time of publication, so the automation component still works even on systems patched for CVE-2026-49952.

CVSS Scoring

The CVSS v4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N) shows a network attack vector, low attack complexity, no prior privileges required, and no user interaction needed, with high impact on both confidentiality and integrity of the vulnerable system.

Affected Systems and Versions

The vulnerability affects Discuz! X5.0 releases 20260320 through 20260501, about 51 days of vulnerable releases.

Specifically:

• Affected: Discuz! X5.0 release 20260320 (initial X5.0 release) through release 20260501
• Fixed: Discuz! X5.0 release 20260510 and later
• Vulnerable Configuration: Standalone mode installation (the default configuration), where UC_KEY is derived from the global authkey

The latest available version at the time of publication is X5.1 (X5.1.40 Business), released June 1, 2026.

Vendor Security History

Discuz! has accumulated 13 published CVE records since 2006, 6 of them with known public exploits and none in CISA's Known Exploited Vulnerabilities catalog. Notable historical vulnerabilities include:

The record shows injection and access control vulnerabilities recurring across nearly two decades. CVE-2026-49952, with its CVSS of 9.1, is the most severe Discuz! vulnerability publicly disclosed to date. The unfixed CAPTCHA bypass (KIS-2026-10) and the repeating vulnerability classes suggest that security investment has not kept pace with feature development over the product's lifecycle.

References

• NVD: CVE-2026-49952
• KIS-2026-09: Discuz! X5.0 (UC_KEY) Cross-Context Token Reuse Vulnerability
• Karma(In)Security: Chaining Security Bugs in Discuz! X5.0: from Race Condition to Pre-Auth RCE
• VulnCheck Advisory: Discuz! X5.0 Authentication Bypass via dbbak.php Encryption Oracle
• Gitee Commit: 9962dad52c4c6999dabaf91ecd70377c680ff3c6
• CWE-323: Reusing a Nonce, Key Pair in Encryption
• Discuz! Official Download Page
• OpenCVE: Discuz CVEs and Security Vulnerabilities
• Discuz! Vulnerabilities: CVEs, CISA KEV and Security Advisories
• CISA Known Exploited Vulnerabilities Catalog
• Wikipedia: Discuz!