phpMyAdmin EUVD-2026-113809

Requires an already-authenticated phpMyAdmin session - either the attacker's own account or, per the description, a hijacked session (PR:L), so this is not remote-unauthenticated. The concrete trigger is a POST to the /config/set route (SetConfigController) carrying key=2fa with a null JSON value, reachable because the controller performed no re-authentication before applying the change. The attack only yields value when the target account actually has two-factor authentication enabled (otherwise there is nothing to strip); there is no user-interaction requirement (UI:N) and no non-default configuration beyond having 2FA configured. The practical limiting factor is obtaining the valid/hijacked session in the first place.

This is a medium-severity, authentication-dependent flaw rather than a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N, score 5.3) confirms a network-reachable, low-complexity issue but with PR:L - an attacker must already hold an authenticated (or hijacked) phpMyAdmin session - and only a Low integrity impact (VC:N, VA:N), consistent with CWE-620 (missing re-authentication) rather than code execution or data theft. There is no CISA KEV listing and no EPSS score in the provided data, so there is no evidence of active or widespread exploitation; the vuln.today Decision label is 'this_month', not act_now/emergency, which aligns with a patch-on-normal-cadence posture. A public technical writeup/advisory reference exists (abraxaslabs research and the VulnCheck advisory), but the input does not mark it as confirmed working exploit code. The main nuance: the pre-conditions (valid session + target having 2FA enabled) mean this is a privilege/defense-in-depth weakening that is only valuable to an attacker who has already achieved session access, so real-world urgency is moderate and should be weighted by whether 2FA is widely relied upon in the deployment.

An attacker who has stolen or hijacked a valid phpMyAdmin session (for example via a leaked session cookie or XSS) sends a POST to index.php?route=/config/set with key=2fa and a null JSON value, which SetConfigController accepts without requiring re-authentication. This silently strips the account's two-factor authentication, so any subsequent login - including by the legitimate user or the attacker - needs only the MySQL password, removing the second factor. A public technical reference describing the technique exists, but it is not verified as working exploit code in the provided data.