A special edition. Instead of five stories, the week already triaged: what is exploited, what is exposed, what it touches, and what that means for when you act.
In this edition
Get the next GRC Brief in your inbox.
Subscribe to The GRC BriefPAN-OS: hours, if that management interface faces the internet.
On 14 October Palo Alto Networks disclosed CVE-2026-0322, a code injection flaw in the PAN-OS management interface that lets an authenticated attacker with high privileges execute code as root on the firewall. CVSS 8.6. The company had already observed what it calls very limited exploitation, and CISA added it to the known exploited catalogue the same day with a federal deadline of 17 October. It affects PA-Series and VM-Series firewalls and Panorama. No special configuration is needed to be vulnerable. Palo Alto's guidance is to restrict management access to trusted internal addresses, or to a single jump box.
Source: Palo Alto Networks · Advisory, 14 Oct 2026
My take
Exploited: yes, as a zero-day, before you heard about it. Exposed: only where the management interface is reachable from outside. Touches: the device that enforces your perimeter, at root. Verdict: hours if that interface answers from the internet, days behind a jump box. And note what the score did here. 8.6 is High, which in most policies buys 30 days, while CISA gave federal agencies three. If your SLA table had been the only input, you would have scheduled an actively exploited firewall takeover for November. The compensating control costs nothing and Palo Alto has recommended it for years: take the management interface off the internet tonight, patch on your own schedule after that.
PHP2Shell: hours, and you were already late.
On 21 October the PHP project shipped an emergency release for two critical flaws in the PHP core, CVE-2026-109618 and CVE-2026-109619, both rated 9.2, both allowing an unauthenticated attacker to run code as the web worker. They are reached while PHP parses the request, before any application code runs. Details leaked on 20 October, a day ahead of the planned disclosure, which forced the release forward. Amazon's honeypots logged an exploitation attempt on 17 October, four days before anyone announced anything. Cloudflare went from tens of thousands of attempts within 45 minutes of disclosure to millions by the next morning. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and earlier get nothing.
Source: PHP · Emergency release, 21 Oct 2026
My take
Exploited: yes, four days before disclosure. Exposed: anything serving web requests through PHP, which for most organisations means the marketing site nobody owns. Touches: code execution as the web account, on the host. Verdict: hours, and the honest version is that your window closed before the advisory existed. Two things to take from it beyond patching. Apache mod_php was validated for full code execution on default settings, so start there. And if any of your estate still runs PHP 8.1 or older, there is no fix coming, which makes it a risk acceptance decision with a name on it rather than a patching task.
Node.js: days, and check your container base images.
The same day, Node.js released fixes for ten CVEs across its 22, 24 and 26 lines. The serious one is CVE-2026-111497, an out-of-bounds write in the bundled Brotli decoder. A malformed stream makes the decoder keep appending input to an eight-byte internal buffer, which can corrupt process memory and permit remote code execution in any application that decompresses attacker-supplied Brotli data. Three more high-severity issues cover TLS certificate hostname validation and DNS name handling. Fixed in 22.23.4, 24.22.1 and 26.12.1. Node.js 20 reached end of life in April and receives nothing.
Source: Node.js · October 2026 security releases
My take
Exploited: no reports. Exposed: any service that decompresses Brotli it did not create, which is more of them than you think. Touches: the runtime under your applications. Verdict: days, on your normal emergency track. The part that bites is distribution. Every container built on a node base image from before 21 October carries this, so the fix is a rebuild and a redeploy across your estate, not a package update on one host. And this release also quietly shipped the certificate distrust from the next item, which is the clearest proof that your trust store lives inside your dependencies.
eMudhra: no patch exists. This one is an inventory problem.
On 17 October a researcher reported to Apple, Google, Microsoft, Mozilla and eMudhra that the private keys of eight of the Indian certificate authority's intermediate certificates could be recovered from the public certificates. They had been generated as tiny integers. Scott Helme, who recovered all eight on a laptop in under a second, notes that one of them is the number 4. Whoever holds an intermediate's key can sign a valid certificate for any domain. The certificates were issued in April 2025, so the exposure window ran about seventeen months. Chrome and Firefox blocked them the same day, Apple on the 19th, Microsoft on the 20th. eMudhra revoked them on the 18th and announced on the 22nd that it is leaving the TLS certificate business.
Source: Scott Helme · 20 Oct 2026, with Mozilla bug 2083449
My take
Exploited: no confirmed abuse, though nobody can account for seventeen months. Exposed: not your browsers, which were fixed within hours. Touches: trust itself, everywhere you validate a certificate outside a browser. Verdict: this one has no deadline because it has no patch, and that is exactly why it is the hard one. Your containers, your appliances, your Java keystores and every Python environment carrying its own copy of certifi each hold a trust store somebody has to update. Curl, certifi, Node.js, Go and the Rust ecosystem all shipped distrust separately. The question your organisation has to answer is where you trust certificate authorities and who can change that everywhere at once, and most cannot answer the first half. One detail worth sitting with: Helme says an AI agent recovered the keys for him from a single prompt.
The three sentences your executive committee needs this week.
A CVE count tells a board nothing it can act on. After a week like this one, three sentences do. Are we exposed to any of this, yes or no. What we did, and when. What we have chosen to leave for now, and who signed that off. The third is the one that matters, and it is the one that almost never gets said out loud. Under Article 20 of NIS2, the management body approves the cybersecurity risk-management measures, oversees their implementation, and can be held liable for failures. A deferral they never hear about is a decision you have quietly taken on their behalf.
Source: My full analysis · christophemazzola.fr
My take
You did not patch your way through this week. You chose, or somebody chose for you. So write the choice down. A named owner, the reason, the compensating control if there is one, and a date to look at it again. A deferred vulnerability with a signature is a risk decision. Without one it is an omission you will be explaining later, and after eight days like these there will be plenty to explain. I have written up the full argument, including why the scores decided nothing and why most patch policies would have ranked the ransomware vector as second-division work. Link above. The short version is that your scanners were the same as everybody else's this week. What separated organisations was knowing who was allowed to decide.