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

Introduction

A single line of configuration code sharing a cryptographic key between two security contexts has opened the door to pre-authenticated database exfiltration and, when chained with additional flaws, full remote code execution on Discuz! X5.0 installations. With a public exploit script already available and Discuz! serving as the dominant forum platform across Chinese web infrastructure, CVE-2026-49952 represents a significant risk to a large number of deployments.

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 a vast majority of Chinese bulletin board system users. Its dominance in the Chinese market means that critical vulnerabilities in Discuz! carry outsized impact across Chinese-language web communities.

Technical Information

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

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

The root cause in Discuz! X5.0 is found 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 creates a critical trust boundary violation. The same cryptographic key now serves two distinct 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, enabling the entire exploit chain.

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, this authcode is accepted as a legitimate authorization token by the database backup API at dbbak.php.

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 (which is the same authkey that encrypted it), accepts it as legitimate, and exports the database backup. This grants 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 executes authcode() on the malicious username payload and reflects a "session authcode" back to the attacker. This token contains the admin's credentials and enables 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, during which the authentication system falls back to ucenter_members data.

Phase 3: Remote Code Execution via Vulnerability Chaining

Once administrative access is achieved through the race condition, 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). This CAPTCHA bypass was not fixed by the developers at the time of publication, meaning the automation component remains functional 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) indicates 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. This represents approximately 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, with 6 having known public exploits and none appearing in CISA's Known Exploited Vulnerabilities catalog. Notable historical vulnerabilities include:

The track record reveals a pattern of injection and access control vulnerabilities spanning nearly two decades. CVE-2026-49952, with its CVSS of 9.1, represents the most severe Discuz! vulnerability publicly disclosed to date. The unfixed CAPTCHA bypass (KIS-2026-10) and the pattern of recurring vulnerability classes suggest that security investment has not kept pace with feature development across 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!