phpMyAdmin and PHP2Shell: No New phpMyAdmin CVE, but Your Install Is Still Exposed

Since the PHP2Shell disclosure on 21 October, we have been asked the same question several times: is there a phpMyAdmin CVE, and which version fixes it? The short answer is no on both counts. phpMyAdmin has published no security announcement in 2026, and 5.2.3 from October 2025 is still the latest release. But that does not mean phpMyAdmin is safe. Calif demonstrated code execution without a login against several PHP applications, and phpMyAdmin 5.2.3 was on the list. The flaw is in PHP, not in phpMyAdmin, so the fix is updating the PHP that phpMyAdmin runs on. That sounds simple until you discover that phpMyAdmin often runs on a different PHP from the rest of your sites.

What Is Actually Known

• PHP2Shell is CVE-2026-109618 and CVE-2026-109619, two use-after-free bugs in the PHP engine, each rated 9.2 under CVSS 4.0. Fixed releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, published on 21 October 2026.
• CISA added both CVEs to its Known Exploited Vulnerabilities catalogue on 26 October. Amazon's honeypots logged an attempt on 17 October, four days before the fix.
• According to Sansec, Calif reported that an attacker without a login can run code on phpMyAdmin 5.2.3, alongside other well-known PHP applications. Synology lists phpMyAdmin among its packages affected by PHP2Shell.
• phpMyAdmin itself has no related advisory. Its most recent announcements, PMASA-2025-1 to PMASA-2025-3, were fixed in 5.2.2 in January 2025: two moderate XSS bugs (CVE-2025-24530 and CVE-2025-24529) and a hardening for the glibc iconv bug CVE-2024-2961.

So when a scanner or a hosting provider reports "phpMyAdmin vulnerable", it means the PHP underneath. Reinstalling phpMyAdmin 5.2.3 changes nothing. Updating PHP and restarting the processes that run phpMyAdmin is the fix.

Why phpMyAdmin Deserves Priority

Every PHP site on an unpatched server is exposed, but a phpMyAdmin install is a particularly valuable target:

• It is easy to find. Bots have been requesting /phpmyadmin, /pma, and /phpMyAdmin on every IP address on the internet for twenty years, so an exposed install is in someone's list already.
• Its login does not help. phpMyAdmin's login screen, two-factor authentication, and login rate limits all run inside PHP. A bug in PHP itself cannot be stopped by code that PHP runs afterwards.
• A shell on that server usually means the database. The process can read config.inc.php, the controluser password if one is configured, and often the application .env files on the same machine. From there an attacker can talk to MySQL or MariaDB directly.
• It is often forgotten. phpMyAdmin is installed once for a migration or a support request and left running on an old server, an old Docker container, or an old NAS, long after anyone remembers it is there.

Find Out Which PHP Runs Your phpMyAdmin

Running php -v on the server is not enough. That shows the command-line PHP, which may differ from the PHP-FPM pool or Apache module serving phpMyAdmin, and on control panels it is a different PHP altogether. The most reliable check is phpMyAdmin itself: after logging in, the home page has a Web server panel showing the PHP version that is serving the page. Remember that Debian, Ubuntu, and RHEL backport fixes without changing the version number, so for distribution packages check the package changelog rather than the number.

The control panel rows are where most mistakes happen. On cPanel, updating ea-php83 fixes your customers' sites but not the phpMyAdmin opened from the cPanel interface, which runs on the PHP that ships with cPanel itself. cPanel published new cPanel & WHM builds (11.110.0.153, 11.134.0.66, 11.136.0.50, and 11.138.0.18) alongside the EasyApache fixes, so run /scripts/upcp as well. On Plesk, phpMyAdmin runs on the panel's sw-engine PHP, which Plesk updates through its own installer rather than through apt or dnf. Plesk has said every PHP version it ships is affected, so apply the latest Plesk update for your release.

For Docker, the image you pulled last month still contains the old PHP. The official phpMyAdmin images are built on the php:8.3 base image and have been rebuilt; as of 28 October the latest, 5.2.3, apache, and fpm-alpine tags contain PHP 8.3.36. Pull, recreate the container rather than just restarting it, and confirm with docker exec <container> php -v.

If You Are Still on phpMyAdmin 4.9

phpMyAdmin 4.9 only supports PHP 5.5 to 7.4, and its last release, 4.9.11, came out in February 2023. That matters here because the PHP project only releases fixes for 8.2 and newer. PHP 7.4 is fixed only through vendor builds such as Debian, Ubuntu Pro, cPanel, Plesk, or commercial long-term support, and PHP 7.3 and older get no fix at all unless you pay for one. A server running phpMyAdmin 4.9 is very likely running a PHP that will never be patched. The realistic fix is moving it to phpMyAdmin 5.2.3 on PHP 8.2.35 or 8.3.36, which are within the range phpMyAdmin 5.2 officially supports.

A Stopgap That Costs Almost Nothing

Unlike a public website, phpMyAdmin usually has a handful of users. That makes it easy to protect at the web server, where requests are rejected before PHP ever sees them. Do this today, even if PHP is already patched:

1. 1Restrict access by IP address. In nginx, add allow lines for your office or VPN addresses followed by deny all inside the phpMyAdmin location block. In Apache, use Require ip with the same addresses. Everyone else gets a 403 from the web server, not from PHP.
2. 2If your team has no fixed IP, put HTTP basic authentication in front of phpMyAdmin at the web server level (auth_basic in nginx, AuthType Basic in Apache). This is a separate check from phpMyAdmin's own login, and it runs before the request is passed to PHP.
3. 3If you cannot do either right away, block multipart/form-data requests to the phpMyAdmin path. Sansec reports that every known PHP2Shell trigger uses that content type. phpMyAdmin's login form does not, so the only thing you lose is the Import page and file uploads into BLOB columns.
4. 4Better still, take phpMyAdmin off the internet altogether. Reach it through a VPN or an SSH tunnel, or use a desktop client such as DBeaver, HeidiSQL, or TablePlus over SSH. Renaming /phpmyadmin to an obscure path reduces log noise but is not protection.

Check Whether It Was Already Used

Attempts started before the patch existed, so a server patched on 22 October may already have been visited. Look back to at least 17 October:

• Files: list PHP files changed recently in the phpMyAdmin directory and web roots, for example find /usr/share/phpmyadmin /var/www -name "*.php" -newermt 2026-10-17. Check phpMyAdmin's temporary directory and any UploadDir or SaveDir you configured as well.
• Logs: look for POST requests to the phpMyAdmin path from addresses that are not your team's, and for PHP-FPM workers or Apache children that died with signal 11 (segmentation fault). Failed exploitation of memory bugs often crashes the worker.
• Database: run SELECT user, host FROM mysql.user and look for accounts nobody created, and check for unexpected triggers, events, or stored procedures. If the FILE privilege is granted and secure_file_priv is empty, check whether files were written through SELECT INTO OUTFILE.
• System: check the crontab of the web server user (www-data, apache, or nginx), and look for processes and outbound connections owned by that user that you cannot explain.

If you find anything, assume the database credentials on that server are known to the attacker. Rotate the passwords of every database account reachable from it, including the phpMyAdmin controluser, change blowfish_secret, and rotate application secrets stored in .env files on the same machine. If the databases hold personal data of Indonesian residents, the Personal Data Protection Law (UU PDP) requires you to notify affected people and the supervising authority in writing within 3 x 24 hours of a failure of data protection, so involve whoever owns that process early.

Where to Start

Make a list of every phpMyAdmin you have, including the ones on staging servers, old VPSs, NAS devices, and inside Docker Compose files. For each, record which PHP it actually runs on, update it, and restrict access at the web server. For most teams that is an hour of work per server, and the access restriction will keep paying off the next time a PHP flaw is announced. If you want a second pair of eyes across many servers, this is routine work for a managed service team.