PHP Vulnerability Remediation on an Ubuntu Web Server

A homelab case study in identifying an outdated PHP package, restoring update access on a segmented server, applying updates, and bringing a website back online.

Overview

My Ubuntu web server runs Apache and PHP in a network-isolated DMZ behind OPNsense. After learning of a PHP vulnerability affecting the installed Ubuntu package revision, I stopped the Cloudflare tunnel as a precaution while I investigated and patched the server.

The initial package check showed PHP 8.3 packages with an Ubuntu revision ending in .11. The fixed revision identified for this system ended in .12. I restored access to the Ubuntu update repository, updated the server, checked the installed packages and services, and restored the tunnel. The website is back online.

The exact CVE identifier and full package versions can be added from the original advisory and recording. A package revision alone is not enough to identify a specific vulnerability.

Video walkthrough

php-remediation-terminal.mp4

A short recording documents the patching and service restoration process.

Environment

• Operating system: Ubuntu
• Web server: Apache HTTP Server with PHP 8.3
• Network: DMZ segmented with OPNsense
• External access: Cloudflare Tunnel (cloudflared)

Investigation and containment

I checked the PHP runtime and installed Ubuntu packages:

php -v
dpkg -l | grep php8.3

The installed package revision ended in .11; the fixed Ubuntu revision identified during the investigation ended in .12. Ubuntu can backport security fixes into its own package revisions, so the upstream version shown by php -v alone may not tell the full story.

I then checked the web server and tunnel:

systemctl status apache2
systemctl status cloudflared
ss -tnlp
apache2ctl -M

At the initial check, Apache was running and listening on 127.0.0.1:80, and the tunnel was stopped as a precaution. Apache's loaded modules included php_module.

Restoring update access

The server's network restrictions prevented it from reaching the update repository. I investigated DNS and the network access needed for maintenance. Before updating, I confirmed that archive.ubuntu.com resolved and that the repository returned HTTP 200 OK.

Applying the update

apt update
apt upgrade

The upgrade applies to all eligible packages, not only PHP. Afterward, I checked the installed PHP packages again:

dpkg -l | grep php8.3
php -v

The Ubuntu package revision is the relevant comparison with the fixed package identified in the advisory. The upstream PHP version may still appear as 8.3.6 after a backported fix.

Service restoration and validation

I checked Apache and the local site, then restored and checked the Cloudflare tunnel:

systemctl status apache2
curl -I http://127.0.0.1
systemctl start cloudflared
systemctl status cloudflared

I checked the website in a browser after restoration. The site is back online. A successful HTTP response confirms the server is responding; testing a PHP-powered page or feature provides an additional application-level check.

Additional details to add

• The Ubuntu security advisory and CVE identifier for the specific issue.
• The full before-and-after package versions from the recording.
• Any relevant notes on the temporary maintenance access and its removal.

What this demonstrates

• Linux package and service administration
• Identifying security updates using distribution package revisions
• Troubleshooting DNS and repository access in a segmented network
• Controlled service restoration and post-update verification

The separate Nginx server was outside the verified scope of this case study; its operating system and PHP package revision need their own checks.