PHP2Shell Vulnerabilities Enable Pre-Application Code Execution on Unpatched Servers

Security researcher Grigoriy Melnikov, creator of KillBot, has published a detailed explanation of how attackers can compromise servers through two known PHP vulnerabilities without needing administrative passwords or SSH access.

The flaws, tracked as CVE-2026-109618 and CVE-2026-109619 and collectively called PHP2Shell, allow any PHP code supplied by an attacker to execute inside the PHP process before the site’s own validators and security checks run.

Privilege and Impact

The attacker inherits the rights of the user under which PHP runs. On typical Ubuntu systems with Apache and mod_php this is the www-data user. From this position the attacker can read site source code, configuration files containing MySQL credentials, and, when write permissions allow, create new executable files inside the web root.

A concrete example shows an attacker reading a configuration file at /var/www/html/site.ru/config.php, extracting database credentials, and connecting directly to the MySQL server. If the database user possesses elevated privileges, the attacker can create additional accounts that persist even after the initial vector is closed.

Attack Sequence

• Confirm ability to execute arbitrary PHP code.
• Locate readable configuration files.
• Extract database connection parameters.
• Connect to the database and assess privileges.
• Perform allowed operations such as creating an administrator account or uploading files.

When PHP is permitted to write inside the site directory, the attacker can drop a file such as hack.php containing <?php echo shell_exec($_GET["c"]); ?> and then issue remote commands via URLs.

Hardening Recommendations

Even with strong configuration—separate ownership of source files, disabled dangerous functions, open_basedir restrictions, minimal MySQL privileges, and per-site system users—the attacker can still execute code inside PHP until the vulnerabilities are patched. The chance of establishing long-term persistence is significantly reduced.

When updating PHP is impossible, the only reliable mitigation is to place a hardened reverse proxy such as Cloudflare or a self-hosted proxy with the fix applied in front of the server and to block all direct inbound web traffic at the firewall except from the proxy’s IP addresses.

Administrators are urged to verify that no unauthorized files were left by previous exploitation attempts and to apply the available PHP patch immediately.