The last two weeks of October were unusually busy for security fixes across the stacks we maintain. Three separate waves landed: a critical PHP vulnerability that was being exploited in the wild, a batch of nginx fixes, and two WordPress core security releases. Here is what came out, what we did, and what to check if you run the same software.

PHP: unauthenticated remote code execution

CVE-2026-109618 and CVE-2026-109619 (together nicknamed PHP2Shell) let an attacker run code on a vulnerable PHP server without logging in, rated 9.2 out of 10. CISA added the bug to its Known Exploited Vulnerabilities catalog within days, which means real attacks were confirmed, not just possible.

We applied the interim hardening circulating at disclosure (disabling the PHP feature involved) on affected servers within hours, then moved every affected host in our fleet to a patched PHP release as fixed packages became available. One honest lesson from this one: later analysis showed that the widely shared interim mitigation did not actually block these specific bugs. Guidance published in the first days of a disclosure is often wrong. Treat mitigations as a stopgap at best; the upgrade is the fix.

nginx: five CVEs in one advisory

Ubuntu's USN-8955-1 fixed five nginx vulnerabilities. The two that mattered most for the configurations we run were CVE-2026-93479, a flaw in regex-based map directives that can crash the server and possibly lead to code execution, and CVE-2026-15176, a heap overflow rated 9.2.

We checked every nginx configuration we maintain against each CVE's preconditions the same afternoon, and upgraded the affected production servers about five hours after the fixed packages were published. A practical note: a fresh advisory often beats the fix to the package mirrors. Run an update and confirm the candidate version actually matches the advisory before calling a host patched, otherwise the upgrade silently installs nothing.

WordPress: two core releases, one actively exploited

WordPress 7.1.4 fixed 11 security issues, including a remote code execution weakness in the core upgrade process. The same week, the project shipped backported point releases (6.8.12 and others) for an unauthenticated remote code execution bug affecting every version from 4.7 through 7.1.3. Wordfence logged more than 18,500 exploit attempts in the first 21 hours after that disclosure.

We ran eight WordPress core updates across four servers, staging copies first, with a database export taken before each one. Sites on current branches were patched the day the release came out; the remaining branch-pinned site followed within a day. We also updated one form-builder plugin (Ninja Forms, CVE-2026-110899, a stored cross-site scripting bug) on the single site in our fleet still running an affected version.

If you run the same stacks

• Confirm your PHP is on a release that fixes CVE-2026-109618/109619, and do not rely on the early feature-disabling workaround.
• Get WordPress to 7.1.4, or the latest point release of your branch, and turn on automatic minor updates. If you use Wordfence's free tier, note its firewall rule for the exploited core bug does not arrive until late November, so patching is your only real protection right now.
• Patch even behind a firewall. One site we updated was not reachable from the open internet at all; we patched it anyway, because firewall rules change and patches do not expire.
• Take a backup before every update. It is the cheapest insurance in this whole post.

Finally, we put the vendor advisory feeds themselves on an automated 30-minute watch, which is why the nginx response started within hours of publication. Speed here is mostly about hearing the starting gun.