PHP2Shell: Patch first, then reduce the attack surface

Martin Melmuk

Tags

PHP

PHP2Shell: Patch first, then reduce the attack surface

On 21 October 2026, PHP2Shell gave me a reason to review the software running on my server. The vulnerabilities could allow unauthenticated remote code execution. My first priority was to patch PHP. My second goal was to reduce the attack surface of the server.

I had already moved my main website to a static site in March 2026. Only one small PHP backend remained. This made it possible to replace the remaining PHP code with a drop-in Go service. I also used the opportunity to remove unused software from the server.

1. Patch the immediate vulnerability

  • In the first step, I updated PHP.
  • PHP2Shell affects the PHP runtime and can allow remote code execution without authentication.
  • I updated the server to PHP 8.3.36, which contains the fixes.
  • I then reviewed the Nginx and Apache logs for suspicious requests.
  • I also examined recent file changes for possible signs of an attack.
  • With PHP patched, I could focus on reducing the software exposed to similar vulnerabilities in the future.

2. The earlier move to a static website

  • In March 2026, I migrated my main website from my self-written PHP CMS to HydePHP.
  • The main motivation back then was to reduce the potential attack surface.
  • For this reason, I had already removed most request-time PHP execution from the main website.
  • Only one small PHP backend remained. It handled contact and newsletter submissions, stored records, and provided an authenticated administration interface.
  • This made the next step relatively simple. I only needed to replace a small and well-defined part of the website.

3. Replace the remaining PHP backend with Go

  • I decided to replace the small PHP backend with a Go service.
  • Memory safety was one reason for this choice. Go avoids many of the manual-memory errors that can lead to memory corruption.
  • The new service uses Go's standard-library FastCGI implementation. It requires no web framework.
  • Nginx communicates with the service through FastCGI over a local Unix socket.
  • The Go process runs as a dedicated systemd service.
  • After testing the replacement, I switched the backend to Go and disabled PHP-FPM.

The result is a small backend with a limited number of responsibilities. The frontend required no changes.

4. Remove the remaining unused software

The backend replacement also provided an opportunity to simplify the rest of the server.

  • I retired old web applications that were no longer needed.
  • I removed Apache because the active website only needed Nginx.
  • I archived unused project files and removed them from the server.

These changes reduced the number of services, dependencies, and applications that require maintenance.

Conclusion

The PHP update addressed the immediate vulnerabilities. Replacing the remaining backend with Go and removing unused software reduced the attack surface of the server.

The earlier static-site migration made this work much easier. It had already reduced the dynamic code to a small component that I could replace in a single maintenance effort.