> status: mostly fine. patch anyway.practical AI security · est. 2026

Calm down. · Builders

Calm down: the phpMyAdmin 5.2.3 WebAuthn "0day" skips a check the official download doesn't skip

By alkizz ·

On Oct 27, an X post from @abraxas_null, with a GitHub repo of write-up and test lab behind it, announced a "phpMyAdmin 5.2.3 WebAuthn 2FA bypass," and by Oct 28 it had a quote post from Florian Roth (@cyb3rops) that just said "Oh boy." That's the kind of reaction that sends people sprinting for their database admin panel, so it's worth slowing down long enough to read the code and the download.

The code part holds up. In phpMyAdmin's fallback WebAuthn code, CustomServer, the function that checks your security key's login response (parseAndValidateAssertionResponse()) only makes structural checks: the credential ID, the request type, the challenge, the origin, the site hash and the "user present" flag. It never checks the signature against the stored public key, which is the part that proves a real security key was there. That's true at the 5.2.3 release tag and on the current development branches, and the code first appeared in 5.2.1.

But phpMyAdmin only falls back to CustomServer when a library called web-auth/webauthn-lib isn't installed. When it is, phpMyAdmin uses WebauthnLibServer, which hands the whole check to the library. And the official 5.2.3 downloads ship that library: both the English and the all-languages tarballs include it. The claim says it doesn't. The release script refuses to build a release without it, and the repo's own test lab has to run rm -rf vendor/web-auth to reproduce the bypass. The README even concedes the point: "If you actually installed web-auth/webauthn-lib, you are on WebauthnLibServer and not this bug."

So the gap is real, and it bites the installs that are missing a library the official download includes. Calm down.

Claimed vs. confirmed

What the doom version says What the sources say
phpMyAdmin 5.2.3 has a WebAuthn 2FA bypass CustomServer really doesn't verify the signature, but 5.2.3 only uses CustomServer when web-auth/webauthn-lib is missing
"The distributed tarball is built with composer install --no-dev," so it lacks the library The official phpMyAdmin-5.2.3-english.tar.xz and all-languages tarballs contain vendor/web-auth/webauthn-lib/src/Server.php (v3.3.12), its autoloader maps Webauthn\Server, and the release script aborts with "Webauthn-lib should be installed, detection failed !" if the library is missing
Install 5.2.3 and you're open The claim's lab runs composer install --no-dev and then deletes vendor/web-auth, and its build fails if Webauthn\Server still exists
It's a 2FA bypass, so the password doesn't matter The claim's own README says you "still need the MySQL password." 2FA is opt-in per user, and only users who enrolled WebAuthn are affected
It's a CVSS 8.1 0day That score is the claim's own. As of Oct 28 there's no phpMyAdmin advisory (the newest PMASA is PMASA-2025-3), no CVE in an NVD search, no GitHub advisory, no acknowledging issue or PR, and no 5.2.4 release

The library isn't in phpMyAdmin's required dependencies, though, and that's where the real exposure is. In composer.json at the 5.2.3 tag, web-auth/webauthn-lib sits under suggest and require-dev, not require, which the claim gets right. phpMyAdmin's setup docs tell people installing from git to run composer update --no-dev, and the 2FA docs tell git users which TOTP and U2F libraries to add but never mention webauthn-lib. So if you installed from a git checkout or with composer's --no-dev, you could plausibly be on CustomServer without knowing it. So, very likely, are some distro packages. Debian's own phpmyadmin packages (bookworm, trixie and sid) ship the CustomServer code but not webauthn-lib, and Debian doesn't package that library at all, so a Debian install with WebAuthn turned on very likely runs the unchecked code. That's from Debian's package file lists, not a test, and Ubuntu, Red Hat and SUSE weren't checked.

There's no fix yet for that path either. A pull request merged on Sept 29 (milestone 5.2.4) changed CustomServer to look up stored credentials and save the counter, but it didn't add a signature check.

The boring lesson

You're exposed only if all three of these are true:

That last one is the real gate. (Opinion) If the attacker already has the password, the problem started well before the security key, and the 2FA headline mostly tells you how much weight that second factor was quietly carrying.

What to do:

Sources

Related

More briefs

← All briefs