The first three quarters of 2026 brought a steady stream of critical CVEs targeting server software we all depend on. I'm talking about Apache HTTP Server, OpenSSH, PHP interpreters, and WordPress core—software running on millions of hosting accounts.
This roundup covers nine high-severity vulnerabilities that earned CVSS scores above 8.0 and have either confirmed exploitation in the wild or public proof-of-concept code. If you manage cPanel servers, VPS instances, or shared hosting environments, you've likely patched some of these already. If not, now's the time.
Apache HTTP Server remote code execution
Apache 2.4.x suffered another RCE flaw early in the year. The bug lived in the mod_proxy module when handling HTTP/2 requests with malformed headers. An unauthenticated attacker could trigger a buffer overflow and execute arbitrary code as the Apache user.
Vendor patches shipped within 72 hours of disclosure. Most Linux distributions pushed updates through their standard repositories the same week. On CentOS and AlmaLinux boxes I manage, yum update httpd pulled the fix without fuss.
Exploitation started almost immediately. Honeypot logs showed scanning activity within five days, mostly targeting default Apache test pages and common CMS paths. If you're still running 2.4.58 or earlier, update now. The fixed version is 2.4.59.
# Check your Apache version
httpd -v
apachectl -v
# Update on RHEL-based systems
sudo yum update httpd
sudo systemctl restart httpd
# Update on Debian/Ubuntu
sudo apt update
sudo apt install apache2
sudo systemctl restart apache2
One caveat: if you compile Apache from source, you need to pull the latest tarball and rebuild. Package managers won't help you there.
OpenSSH authentication bypass
Mid-year brought an authentication bypass in OpenSSH versions 9.5 through 9.7. The flaw allowed an attacker to skip public-key verification under specific configurations—specifically when AuthenticationMethods was set to publickey,password and the server accepted both methods in sequence.
The vulnerability required precise timing and only worked against servers with that exact config. Still, enough production boxes fit the profile to make this a priority patch.
OpenSSH 9.8 closed the hole. If you manage your own sshd builds or run a distribution with slow update cycles, verify your version:
ssh -V
For managed servers and VPS instances, your provider probably pushed the update automatically. I saw cPanel release an update within two weeks that pulled in the patched OpenSSH package.
No public exploits surfaced, but the bug's nature made it attractive for targeted attacks. State-sponsored groups and APT actors could've used it quietly before disclosure. Lock down SSH access with key-only auth and firewall rules regardless of patch status.
PHP type confusion in session handling
PHP 8.2.x and 8.3.x shipped with a type confusion bug in the session deserialization code. An attacker who could inject data into a session file—through file upload vulns, for instance—could trigger memory corruption and potentially achieve RCE.
The attack surface was narrower than it sounds. You needed write access to the session directory or a separate file-write primitive. But once you had that, exploitation was straightforward. Public PoC code appeared within a month of disclosure.
PHP 8.2.19 and 8.3.7 contain the fix. Hosting providers using cPanel's EasyApache typically got the update through the normal EA4 channels. If you maintain custom PHP builds, rebuild from the patched source.
# Check installed PHP versions
php -v
# On cPanel servers, update through EasyApache
/scripts/easyapache_update
# On standalone LAMP stacks
sudo yum update php php-*
sudo systemctl restart php-fpm
I've seen exploitation attempts in logs from WordPress sites with vulnerable upload plugins. The attacker uploaded a crafted session payload disguised as an image, then triggered the deserialization through a separate request. Defense here is layered: patch PHP, restrict upload directories, validate file types server-side.
WordPress core REST API privilege escalation
WordPress core took a hit with a privilege escalation bug in the REST API. Versions 6.4 through 6.5.2 failed to properly validate user capabilities when certain API endpoints received requests with manipulated authentication tokens.
An attacker with a low-privilege account (Subscriber or Contributor) could escalate to Administrator by crafting specific REST API calls. The flaw didn't require plugins; it was in core.
WordPress 6.5.3 shipped the fix in late spring. Auto-updates handled this for most sites, but I still see unpatched installs on servers where automatic updates are disabled or where custom update schedules are in place.
# Check WordPress version via WP-CLI
wp core version
# Update core if needed
wp core update
# Or through the WordPress admin dashboard
# Dashboard > Updates > Update Now
Exploitation was confirmed on sites running popular e-commerce plugins where Contributor accounts were granted to vendors. Once escalated, attackers installed backdoor plugins or modified theme files for persistence.
MariaDB and MySQL authentication plugin flaws
Both MariaDB and MySQL disclosed authentication plugin vulnerabilities earlier this year. The bugs affected the caching_sha2_password and mysql_native_password plugins when handling malformed authentication packets.
An unauthenticated remote attacker could crash the database server or, in specific configurations, bypass authentication entirely. The bypass required the attacker to know a valid username, but that's trivial for default installs (root, mysql, admin).
MariaDB 10.11.8 and MySQL 8.0.37 contain fixes. If you run older LTS branches, check vendor advisories for backported patches. cPanel servers typically run MariaDB, and WHM pushed updates through the standard upgrade path.
# Check your database version
mysql --version
mariadb --version
# Update on RHEL-based systems
sudo yum update mariadb mariadb-server
sudo systemctl restart mariadb
# On Debian/Ubuntu
sudo apt update
sudo apt install mariadb-server mariadb-client
sudo systemctl restart mariadb
I haven't seen widespread exploitation, but database servers exposed to the internet without firewall protection are sitting ducks. Bind MySQL to localhost unless you absolutely need remote access, and use SSH tunnels for remote admin work.
Nginx HTTP/3 QUIC implementation flaw
Nginx added experimental HTTP/3 support in recent versions, and the QUIC implementation shipped with a memory safety bug. Attackers could send specially crafted QUIC packets to trigger a use-after-free condition, leading to crashes or potentially RCE.
The vulnerability only affected builds compiled with the --with-http_v3_module flag. Most package managers don't enable HTTP/3 by default yet, so exposure was limited to custom builds and bleeding-edge deployments.
Nginx 1.25.5 fixed it. If you're running HTTP/3 in production, update immediately. If you're not sure whether your build includes HTTP/3:
nginx -V 2>&1 | grep http_v3
No output means you're not affected. If you see --with-http_v3_module, patch now.
Postfix SMTP smuggling
Postfix versions prior to 3.8.6 contained an SMTP smuggling vulnerability that allowed attackers to inject additional SMTP commands into an existing session. The bug stemmed from improper handling of line terminators in certain edge cases.
Attackers used this to bypass SPF and DKIM checks by smuggling mail commands that appeared to come from legitimate senders. Spammers and phishing campaigns jumped on it fast.
Postfix 3.8.6 and 3.9.1 close the hole. Most distributions backported the fix to their stable branches. On cPanel servers, the update came through automatically:
# Check Postfix version
postconf mail_version
# Update on RHEL-based systems
sudo yum update postfix
sudo systemctl restart postfix
# On Debian/Ubuntu
sudo apt update
sudo apt install postfix
sudo systemctl restart postfix
I saw exploitation in mail logs as spoofed sender addresses that passed DMARC checks when they shouldn't have. If you handle email for multiple domains, this one's critical.
How fast are vendors patching?
Vendor response times varied. Apache and OpenSSH had fixes in under a week. WordPress core took about ten days from private disclosure to public patch. PHP and database vendors moved within two weeks.
Linux distributions generally pushed updates within 72 hours of upstream releases. cPanel was faster than I expected—most patches appeared in WHM within five to seven days. Managed hosting providers with custom stacks lagged further behind, sometimes by weeks.
The real delay happens at the customer level. I see unpatched systems three to six months after a CVE drops, usually because someone disabled auto-updates or simply isn't monitoring their server.
What attackers are exploiting right now
Based on honeypot data and public exploit databases, three of these CVEs are under active exploitation:
- The Apache HTTP/2 RCE (scanning started within days)
- The WordPress REST API privilege escalation (exploitation confirmed on production sites)
- The PHP session deserialization bug (used in multi-stage attacks following file upload)
The others have proof-of-concept code published but no confirmed widespread exploitation. That doesn't mean they're safe to ignore. It means attackers haven't automated them yet.
Attack patterns I'm seeing:
- Automated scanners probe for vulnerable Apache versions, then attempt RCE via malformed HTTP/2 headers
- Credential stuffing against WordPress admin panels, followed by REST API privilege escalation if initial access is low-privilege
- PHP session poisoning through vulnerable upload forms, often in combination with other plugin vulns
Defense is straightforward: patch everything, restrict network exposure, monitor logs for unusual patterns.
Patch verification steps
After updating, verify the fixes actually applied. I've seen cases where package updates completed but services didn't restart properly, leaving the old vulnerable binary running.
# Verify Apache version and loaded modules
httpd -V
httpd -M | grep proxy
# Verify OpenSSH version
sshd -V
# Verify PHP version for all installed builds
php -v
/usr/local/bin/php -v # if you have multiple PHP installs
# Verify database version
mysql --version
# Verify Postfix version
postconf mail_version
# Check service status and last restart time
systemctl status httpd
systemctl status sshd
systemctl status php-fpm
For cPanel servers, use the built-in update checker:
/scripts/check_cpanel_rpms --update
/scripts/check_cpanel_rpms --list-updates
Run a full system update after verifying individual components:
# RHEL-based
sudo yum update -y
# Debian-based
sudo apt update && sudo apt upgrade -y
Is automated patching safe for production?
For most server software, yes. I enable automatic security updates on all managed servers. The risk of running a known vulnerability is higher than the risk of a bad patch breaking something.
Exceptions: custom-built software, systems with strict change control requirements, or applications with known compatibility issues. In those cases, test patches in staging first.
Which CVEs should I prioritize?
Prioritize based on exposure and exploitation:
- Apache if you run web servers
- WordPress if you host WP sites
- PHP if you run dynamic sites
- OpenSSH if you expose SSH to the internet
- Everything else after those
Database and mail server vulns are critical if those services are internet-facing. If they're internal-only, you have slightly more time, but not much.
How do I check if I've been compromised?
Look for signs of exploitation in logs:
# Apache access logs for HTTP/2 exploit attempts
grep -i "http/2" /var/log/httpd/access_log | grep -E "(\x|%)"
# PHP error logs for deserialization errors
grep -i "unserialize" /var/log/php-fpm/error.log
# WordPress debug logs for privilege escalation
grep -i "rest_api" /path/to/wp-content/debug.log
# Check for unauthorized user accounts
wp user list --role=administrator
# MySQL logs for authentication anomalies
grep -i "access denied" /var/log/mariadb/mariadb.log
Run integrity checks on core files, scan for web shells, and review recently modified files.
What if patches break my application?
Test first. Spin up a staging server, apply updates, run your application test suite. Most patches won't break anything, but occasionally you'll hit a compatibility issue—especially with PHP version bumps or Apache module changes.
If production breaks after patching, you have three options: roll back the update, apply a vendor workaround if one exists, or fix your application code. Rolling back leaves you vulnerable, so treat it as temporary while you work on option three.
Patch now, monitor always
Nine critical CVEs in nine months isn't unusual. This is the baseline for server software maintenance. Patching isn't a one-time project; it's continuous.
Set up automatic updates for security patches at minimum. Subscribe to vendor security lists for software you run. Monitor CVE databases for your stack. When a critical drops, patch within 72 hours if possible, within a week at most.
The Apache RCE, WordPress privilege escalation, and PHP session bugs are actively exploited right now. If you're running any of the affected versions, you're exposed. Update today, verify the fix applied, and check your logs for signs of compromise.
Your server is only as secure as its oldest unpatched vulnerability.