CVE-2026-56706: Adminer before 5.4.3 CSRF Token Secret Recovery via XOR Masking
Adminer before 5.4.3 uses a CSRF token scheme that transmits both the XOR mask and the masked value in every token (format (rand XOR secret):rand), allowing anyone who observes a single CSRF token (e.g., via network sniffing, log files, Referrer header, or XSS) to recover the session secret with a single XOR operation and forge unlimited valid tokens. The implementation is further weakened by a low-entropy session token (rand(1,1e6), ~20 bits) that permits blind brute-force, and by use of loose comparison (==) in token verification, enabling PHP type juggling. Exploitation enables cross-site request forgery against authenticated sessions, including execution of arbitrary SQL queries.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 5.4.3 - Configuration
Update Adminer’s CSRF token verification logic to use strict comparison (===) rather than loose comparison (==) to prevent PHP type juggling from bypassing validation.
Adminer CSRF token verification = Use strict comparison (===) instead of loose comparison (==) - Compensating control
Assume captured CSRF tokens may allow forging; monitor for suspicious cross-site requests/abnormal admin actions and restrict access where possible (e.g., limit exposure of the Adminer interface to trusted networks/users) until fixed.
Event History
Frequently Asked Questions
What does an attacker need to exploit this issue?
The attacker needs either one observed CSRF token from an authenticated session or a way to make a blind brute-force attempt against the low-entropy session token. Observed tokens may be obtained through network sniffing, log files, Referrer headers, or XSS.
Which users or deployments are exposed to the greatest impact?
Authenticated Adminer sessions are the target, because forged tokens can be used to perform cross-site request forgery against those sessions. The reported impact includes execution of arbitrary SQL queries through the affected authenticated session.
How can a single token lead to continued abuse of a session?
Each token includes both the XOR mask and masked secret in the form (rand XOR secret):rand. An observer can XOR those values to recover the session secret and then forge unlimited valid CSRF tokens for that session.
What can be done if updating is not immediately possible?
The available data does not provide a vendor workaround. Reduce opportunities for token exposure, including exposure through network traffic, logs, Referrer headers, and XSS, and limit access to authenticated Adminer sessions until an update can be applied.