On 27 October 2026 a researcher published a claimed bypass of the second login step in phpMyAdmin 5.2.3, the multi-factor authentication that uses WebAuthn. There is no CVE id and no phpMyAdmin advisory yet, as of 28 October 2026.
We read the source code and the official release archive ourselves. By our reading, the signature check is missing in one code path only. By that reading, the official download, and the official Docker image going by its Dockerfile, use a different path, so the exposure looks narrower than the post suggests.
Three things must be true at once:
- The user has turned on WebAuthn as a second factor.
- The attacker already knows that user’s MySQL password.
- The install runs without the web-auth/webauthn-lib library.
If a database port is open to the internet, the password alone already opens the database, with no phpMyAdmin involved. We did not run the researcher’s code and did not test any live install. Everything below comes from reading code, the release archive and public pages.
Last updated: 28 October 2026. We update this page if phpMyAdmin publishes an advisory or a CVE id is assigned.
Which phpMyAdmin Installs Can Skip the Signature Check?
WebAuthn is a W3C web standard for signing users in with public-key credentials. A login can use it as a second factor.
When a user logs in, phpMyAdmin picks its WebAuthn server class. If the web-auth/webauthn-lib library is present, it uses the library. If not, it falls back to its own class, called CustomServer.
In the 5.2.3 source, the fallback checks the credential id, the type, the challenge, the origin host, the RP ID hash and the user-present flag. By our reading, it never checks the signature itself.
| Install type | Server class used | Signature checked? | Our status |
|---|---|---|---|
| Official 5.2.3 download (all-languages archive) | The library server. The archive contains vendor/web-auth/webauthn-lib 3.3.12. | By the library. We did not review the library. | Not affected by this claim, by code reading. |
| Official Docker image, version 5.2.3 | The library server. The Dockerfile unpacks the same official archive. | By the library. We did not review the library. | Not affected by this claim, from the Dockerfile. We did not pull the image. |
| Git checkout or Composer install set up without dev packages (composer update –no-dev) | CustomServer. The library is only a development dependency, so –no-dev leaves it out. | No. | Affected path present, by code reading. |
| Debian unstable package (5.2.4 development snapshot) | Probably CustomServer. Its dependency list names no WebAuthn library. | Probably not. | Unclear. We did not unpack or run the package. |
| Debian stable and oldstable packages (5.2.2 and 5.2.1) | Not checked. | Not checked. | Not checked. We saw only the version numbers. |
| Ubuntu, Fedora, Alpine and hosting control panels | Not checked. | Not checked. | Not checked. |
How to read this table: “Not affected by this claim” means the code path in question is not the one that runs. It does not mean phpMyAdmin has no other bugs. “Affected path present” means the unsigned fallback runs for any user who has WebAuthn on. “Not checked” means we have not looked.
One-minute self check: Open the phpMyAdmin folder on your server and look for vendor/web-auth/webauthn-lib. The code asks whether the library’s server class exists. If the folder is there, the library is used. If it is missing, check how your package or panel provides the library before you draw a conclusion.
What Does the Researcher Say, and Where Does the Source Differ?
The researcher posts as @abraxas_null on X and as abraxas on GitHub, under the name Abraxas Labs. The X profile says the author is former Mandiant and Trellix ARC, with more than 20 accredited CVEs. That is the author’s own description, and we did not verify it.
Post by @abraxas_null, 27 October 2026, 17:18 UTC: the post on X.
The post calls the flaw a “0day”, rates it CVSS 8.1 under CWE-347 and CWE-287, and points to a repository named abraxas/PMA-5.2.3-WebAuthn-2FA. We use “claimed bypass” because no vendor has confirmed it.
The README says no CVE exists yet. It says the attacker needs the MySQL password first, and that a crafted request then gives a normal session. It puts the impact at the data in the database, not a shell on the host.
On the signature check, our reading agrees. In CustomServer, the method that validates a login assertion only decodes the signature. The stored public key is never used to verify it. The same is true of the QA_5_2 branch and of master as of 27 October.
Where we differ is the root cause. The post says the distributed archive is built with composer install --no-dev, so the library is missing and the fallback runs.
We downloaded the official 5.2.3 all-languages archive and listed it, without running anything. It contains the library, and its class map lists the library’s Server class. By our reading, in the official archive the library path is the one that runs, not the fallback.
By its Dockerfile, the official Docker image is built from the same 5.2.3 release, in its .tar.xz form. Its Dockerfile downloads the 5.2.3 archive, checks its SHA-256 hash and removes a few folders such as setup and examples. The vendor folder is not among them.
The researcher’s own test lab removes the library first. The README says its Dockerfile deletes vendor/web-auth so that CustomServer is the code in play. That lab targets the fallback. It does not show that a default install is exposed.
The fallback class was added in December 2022 and is in the tags 5.2.1, 5.2.2 and 5.2.3. The 5.2.0 tag has no such file. We read the code of 5.2.3, of the QA_5_2 branch and of master. Version 5.2.3, released on 8 October 2025, is the latest tagged release as of 28 October 2026.
Where Does the Claim Stand Today?
As of 28 October 2026 the claim has public lab code from the researcher and some reach, but no vendor confirmation.
- Researcher’s repositoryYesabraxas/PMA-5.2.3-WebAuthn-2FA was made public on 20 September. Its README describes the bypass and a lab. We did not clone or run it.20 Sep
- XYesThe researcher’s post had 126 likes, 31 reposts and 11,249 views when we checked. An account with about 80,000 followers posted about it at 20:14 UTC.27 Oct
- CVE idNot seenNone published. The README says there is no CVE yet.28 Oct
- CISA KEVNot seenNot in the catalogue as of 28 October. There is no CVE id to list.28 Oct
- Vendor advisoryNot seenphpMyAdmin’s security page lists no 2026 announcement. The newest entry is PMASA-2025-3.28 Oct
At 20:47 UTC the researcher replied on X that the issue is unrelated to the PHP2Shell flaws and is a problem in phpMyAdmin itself.
- 20 Sep 2026Researcher’s repository becomes publicGitHub shows it public from 17:59 UTC.
- 29 Sep 2026phpMyAdmin changes CustomServerA commit changes how credentials are saved. It adds no signature check.
- 27 Oct 2026The researcher posts on XThe post is at 17:18 UTC. A larger account follows at 20:14 UTC.
- 28 Oct 2026No advisory yetphpMyAdmin’s security page lists no 2026 announcement, and no CVE id exists.
What Should You Do Today?
Treat phpMyAdmin’s own 2FA as one layer, not as the only one. In order:
- Limit who can reach it. Allow phpMyAdmin only from a VPN or a list of known IP addresses.
- Add a login at the web server. Basic authentication or single sign-on in front of phpMyAdmin works whatever phpMyAdmin’s 2FA does.
- Run the one-minute check. Do not rely on WebAuthn 2FA on an install that has no vendor/web-auth/webauthn-lib folder.
- Consider the researcher’s fix. The README suggests installing web-auth/webauthn-lib. phpMyAdmin 5.2 lists it as ^3.3.2 in its development requirements. This is the researcher’s suggestion, so back up first and test it before production.
- Change exposed passwords. The bypass needs the MySQL password, so rotate the passwords of accounts that may have leaked.
- Read the web server log. Look for POST requests that carry the parameter webauthn_request_response from addresses you do not know. Normal WebAuthn logins send it too, so compare against your users’ usual addresses.
- Keep database ports closed. An open MySQL port makes the password alone enough.
An exposed login page is the exploit public-facing application technique in ATT&CK. A known database password then falls under valid accounts. Both are why the network limits above matter more than the second factor.
To follow the story, watch phpMyAdmin’s security announcements and its releases on GitHub. We will update this page when an advisory or a CVE id appears.