This Week Was (Is*) a Vulnpocalypse: 3 Ways GRC Can Help

Key Takeaways

• A Surge in Vulnerabilities: A wave of critical vulnerabilities and security incidents has exposed weaknesses in software dependencies, vendor access, and trusted distribution channels.
• Rethinking Remediation Priorities: With only a small fraction of disclosed vulnerabilities observed being exploited, GRC teams should prioritize demonstrated exploitation and business exposure rather than rely solely on severity scores and uniform remediation deadlines.
• Testing Compliance Controls: Recent incidents provide an opportunity to assess whether existing controls can identify vulnerable components, detect failures, and support timely remediation.
• Reassessing Third-Party Exposure: GRC teams should examine vendor dependencies, data access, and internal system privileges to identify which third-party relationships warrant immediate attention.
• Turning Risk Assessments Into Action: Risk registers should document vulnerabilities that cannot be patched immediately, establish interim mitigations, and identify the stakeholders needed to move remediation forward.

Deep Dive

In his original article, This Week Was (Is) a Vulnpocalypse. 3 Ways GRC Can Help, Ayoub Fandi, co-author of the GRC Engineering Manifesto, examines a wave of cybersecurity vulnerabilities and incidents and what they reveal about the systems organizations rely on. His argument is that GRC teams have a practical role to play in helping security teams respond, particularly through compliance oversight, third-party risk management, and the risk register.

Where GRC Can Make a Difference When Security Teams Are Under Pressure

Your security feeds spent the week reading like an incident channel. GitLab patched a CVSS 10 flaw reaching back to 2014, PHP shipped emergency fixes while the NSA advised taking unpatched systems offline, and a record Patch Tuesday was still being absorbed.

Is, because it's still going as you read this.

That's fifteen headlines in ten days. Most came through a door someone had approved, and most of the breaches started with a stolen or long-lived credential.

The security team is the one living through this. GRC works on different things, like passing audits and holding the programme to its remediation timelines, and that's where it can help this week: compliance, third-party risk and the risk register.

Two Numbers Worth Keeping

Microsoft's October 13 Patch Tuesday fixed more than 1,400 CVEs, a record. One of them, a Windows Shell Mark-of-the-Web bypass, was actively exploited, and CISA gave US federal agencies three days to fix it.

The second number comes from Google Threat Intelligence Group, reported by Help Net Security. Monthly vulnerability disclosures rose from 5,045 in January to 10,740 in August 2026.

Of all the vulnerabilities disclosed in 2026, only 0.23% were observed exploited in the wild. That is about one in 431.

Put the two numbers side by side, then look at your remediation SLA. Monthly disclosures more than doubled between January and August, and only a small share of them has been seen in use against anyone.

At this volume, a flat SLA for every critical will be missed, and every miss is risk you're carrying without a decision behind it.

GRC owns that SLA. If your policy says 14 days for every critical, it was probably set before monthly disclosures doubled.

This month, that SLA's evidence will mostly be a list of misses, and it won't tell anyone which miss was the exploited Patch Tuesday flaw. Rank by exploitation first, starting with CISA's Known Exploited Vulnerabilities list, and the SLA tracks the flaws that actually matter.

Your Week, in One Scroll

The core developer platform was one door. GitLab had a CVSS 10 remote-code-execution flaw affecting versions dating back to 2014. At the network edge, zero-days affecting Ivanti, PAN-OS, Cisco and BeyondTrust were exploited. The trust behind package publishing was another point of exposure: an npm publishing flaw exposed more than 1,500 packages.

Language runtimes were also in the headlines. PHP faced a critical remote-code-execution flaw, with the NSA advising users to patch or take unpatched systems offline. Node.js had 10 CVEs, including remote code execution.

Several incidents involved software or workflows users had reason to trust. LiteLLM had a backdoored release linked to stolen OAuth tokens. OVHcloud CLI binaries were swapped for a secret stealer. Official Rank Math PRO packages were backdoored and exploited. GhostAction used fake workflows to steal GitHub Actions secrets. In ConnectWise, a vendor application credential was abused in Microsoft 365 tenants.

Platforms holding secrets were another point of exposure. Railway environment variables may have been accessed, some of them decrypted. Zeabur had plaintext administrator credentials exposed and is now shutting down. OpenCode exposed saved AI provider API keys. TiDB Cloud had stolen service-account credentials and exposed billing data. At certificate authority eMudhra, eight CA keys were recoverable and one root was removed.

Official releases, package registries, a vendor's own app identity and a certificate authority are the channels your controls are built to trust. This month attackers came through several of them, and two more, a certificate authority and npm's publishing trust, turned out to be breakable.

The Vulnpocalypse Phrasebook

Every incident week produces the same sentences in the meetings GRC sits in. Keep this open for the ones you'll hear next week.

“Are we affected?” Nobody knows what runs PHP. “It's a CVSS 9.8.” A number, still waiting for a decision. “We have a compensating control.” The WAF, probably.

“Raise an exception.” Expiry date: never. “Patch all criticals in 14 days.” A policy written for a quieter year. “We did a vendor review.” A snapshot, taken before this week.

“Let's take this offline.” For once, the NSA said it first. “Who owns this?” The oldest open item in the risk register. “We're monitoring the situation.” Someone has the news tab open.

GRC can help in those meetings without running the patching, through three lanes it already owns. From incident week to something the security team can use, one lane at a time.

Compliance: Would Your Controls Have Seen It?

Start with the controls whose assets and scope match the components in this week's incidents. If PHP or Node.js runs inside your certification scope, some control already claims to cover it. In the infrastructure-as-code guide, I showed how a resource can vanish from drift detection while it keeps running, so check what runs as well as what the repo declares.

Then ask: would that control, as designed, have found this?

If your continuous control monitoring works, it should be showing you a failing control right now. The other possibility is that another team saw it first and fed it back to you.

If GRC learned last, ask two follow-up questions: should you have been aware, and is this something you need to track?

If you found out from Slack, the control didn't do its job.

In the issue on certification scope, I walked through a team shipping 100 times a day, where the auditor samples 25 of roughly 36,000 pull requests, about 0.07%, while the certification covers all of them. Weeks like this one are when you find out how the rest are doing.

Then do GRC's part, which sits one level up from the flaw: the commitments your programme has made.

Give back remediation timelines in the terms those framework commitments use. That means the vulnerability management control in your SOC 2 or ISO 27001 programme, and FedRAMP 20x if you run one. For each in-scope component, write one line: the finding, the SLA your policy commits to, the due date, and the exception if you will miss it.

TPRM: Map Your Vendor Exposure

When vendors have a week like this, think about every vendor you have, beyond the names in the incident roundup.

Check your own company first. Do you use any of these libraries, frameworks, languages or services directly? If the answer is yes, that component goes to your security team and back into the scope check from the compliance lane.

For vendors, check the subprocessor lists on their trust centres. Then read their DNS records to see which services they rely on, and work out from both whether you have exposure.

A verification record in TXT or a mail provider in MX shows some of the SaaS and hosting a vendor relies on before you send a single email. DNS won't show which runtime or package they run, which is what the outreach is for. It is the same habit as reading a config with a GRC question in hand.

For a generic DNS check using example.com, the commands are dig +short TXT example.com and dig +short MX example.com. To inspect a vendor subdomain such as a status or help page, use dig +short CNAME status.example.com. TXT verification records and MX/CNAME targets often reveal which SaaS services a domain relies on.

Then reach out. Weigh how strong the risk is by how much of your data each vendor holds and what access they have to your internal systems.

Decide the best way forward for each one. Ideally, build an automated way to run the outreach and triage the answers as they come back. Next time, you start from this list.

An illustrative triage record could cover four vendors. Vendor A holds customer records, has an SSO app with directory-read access and reports Node.js exposure as mitigated, with follow-up due October 29, 2026. Vendor B holds marketing contacts, has no internal access and reports PHP as patched, with no follow-up date. Vendor C holds source code, has CI integration access and has not responded about LiteLLM exposure, with follow-up due October 23, 2026. Vendor D holds support tickets, has a Microsoft 365 app identity and reports no exposed component and no impact, with follow-up due October 29, 2026. That last response still needs verification because it shares the access path involved in this week's app-identity incident.

Then read the replies as a set. Count who answered and who didn't, who said they mitigated, who said they patched and who said they had acted before the news broke.

Chase the vendors with internal access who haven't answered first. A patched response from a vendor holding marketing data can wait.

Risk: The Dependency You Cannot Hot-Patch

Look for one scenario in your register. A core dependency used by software in production carries a critical vulnerability, and you cannot hot-patch it fast.

Sometimes the patch exists and still needs proper regression testing before it ships. A language runtime like PHP or Node.js is the example from this week's incidents.

You need to understand that scenario and have it in the register, with an owner, the interim mitigation and the date the decision gets revisited.

At one in 431, much of the queue can wait. The few flaws that cannot wait and also cannot be patched quickly are the risk register's job. Every interim mitigation on them needs an expiry, either a date or an exposure trigger.

In the risk register issue, I wrote that every row in a register is a photograph of its inputs on one date. This week changed that photograph for any row that depends on PHP or Node.js.

Writing the scenario down is the easy part. Getting it fixed is where GRC's stakeholder management helps the security team most.

Security has to collaborate with many stakeholders to get a remediation moving. GRC can open those doors for them.

You know the right point of contact in each team and who is most likely to get a change through. You also know who has been the security team's biggest ally in the past.

In the vendor dinners issue, I argued that the biggest security decisions still run on gut feel, vendor dinners and whatever leadership read last week. Knowing who actually says yes is how you work with that.

You've built those relationships over the years. This is the week to use them to turn a register entry into a fix in production.

Your security team knows what needs fixing. You can tell them who will get it through.

For the runtime scenario, the remediation owner might be the head of platform engineering, with the risk owner named in the register as approver. Bring in platform, engineering leads and product, and legal or vendor management if a vendor is involved. The ally is the engineering lead who has unblocked security before. Agree the interim mitigation with the remediation owner and write it into the register entry. Set a revisit date, or revisit the decision the day the flaw appears on an exploited list.

Hand those responsibilities to your security team before they need them, and make the introduction to the ally yourself.

Your Starter Toolkit

To prove a control operates, start with 5 metrics that prove a control works, including remediation velocity at median and p90 per severity, plus exception age.

To check a platform's testing logic, start with The Zillow effect in GRC, on platforms moving from storing evidence to judging whether controls work, and what to check in their testing logic.

To keep exceptions tied to exposure, start with Threatify your GRC workflows, where an acceptance ends when its exposure changes.

To debug a control that failed, start with The GRC debugger, for finding the frame that broke without booking a meeting.

Before the Next One

You don't need the whole playbook this week. Pick the lane where your programme is weakest and do that one before next Thursday.

For compliance, pick the control whose scope covers one component in the incident roundup and check whether it would have flagged it. For TPRM, list your vendors with the most internal access and check their subprocessor lists for this week's names.

For risk, write the scenario for one production dependency you could not patch within your SLA without regression testing. Then name the people who can get one remediation moving fastest, and introduce your security team to them.

The GRC Report is your premier destination for the latest in governance, risk, and compliance news. As your reliable source for comprehensive coverage, we ensure you stay informed and ready to navigate the dynamic landscape of GRC. Beyond being a news source, the GRC Report represents a thriving community of professionals who, like you, are dedicated to GRC excellence. Explore our insightful articles and breaking news, and actively participate in the conversation to enhance your GRC journey