By the Numbers: A Historic Security Dump

Microsoft just shipped its biggest Patch Tuesday ever — and it’s not even close. The company closed 622 vulnerabilities in its own products, according to its Security Update Guide. That’s more than triple the previous record of around 200 flaws addressed in June 2024.

Put simply: This is a monster release. And among those hundreds of fixes, two stand out because attackers are already using them in real-world campaigns.

The Two Zero-Days You Need to Patch First

Both actively exploited bugs were reported by incident response teams. Microsoft credits those responders for each discovery — a sign that the company is leaning on frontline defenders to catch what automated scanners miss.

While the full technical details are still emerging, the pattern is familiar: one flaw likely enables remote code execution, the other a privilege escalation. Together, they give attackers a potent one-two punch. If you’re responsible for patching Windows systems, these two should be at the very top of your list.

What Makes a Zero-Day ‘Actively Exploited’?

Microsoft distinguishes between publicly known vulnerabilities and those under active attack. A zero-day under active exploitation means attackers have working code and are using it right now — not just proof-of-concept exploits floating around in research labs. That elevates the urgency significantly.

Why This Patch Tuesday Is Unprecedented

The sheer volume is staggering. Microsoft’s previous high was around 200 CVEs in a single month. Now we’re looking at 622 — a 200% increase. That’s not a gradual climb; it’s a spike. Analysts point to several drivers:

• More code, more bugs: Microsoft’s product surface area keeps expanding, especially with cloud services, AI features, and the ongoing integration of Windows and Office.
• Better detection: Internal and external researchers are finding flaws faster, partly thanks to improved tooling and bug bounty programs.
• Disclosure catch-up: Some of these CVEs may have been held back from previous releases and are now being shipped together.

Whatever the reasons, IT teams now face a massive patching workload. Prioritization isn’t optional — it’s survival.

How to Prioritize These Patches

With 622 fixes, you can’t install them all at once. Here’s a practical approach:

1. Patch the two actively exploited zero-days immediately. These are the ones attackers are using right now. No delay.
2. Fix critical-rated remote code execution bugs next. These don’t require user interaction and can spread like worms.
3. Address privilege escalation flaws that could let an attacker gain admin rights after an initial foothold.
4. Schedule the rest in your normal patch cycle, prioritizing internet-facing systems and servers.

Microsoft’s Security Response Center (MSRC) usually publishes a risk-based guide alongside Patch Tuesday. Check that before you start.

What This Means for Security Teams

Record patch volumes are becoming the new normal. In 2023, Microsoft shipped over 1,200 CVEs total. If this pace holds, 2024 could blow past 2,000. That’s a lot of updates for any organization to manage.

The key takeaway: Don’t treat every patch equally. Focus on the actively exploited bugs first, then the critical remote code execution flaws, then everything else. Automate what you can, but keep a human eye on the threat landscape.

Also worth noting: This record doesn’t mean Microsoft’s software is getting less secure. It means the detection and disclosure ecosystem is working. More bugs found and fixed before they become major incidents is a good thing — even if it hurts on patch day.

For now, get those two zero-days patched. The rest can wait a few days.

ModHeader Extension Yanked After Dormant Data Collector Found

Google and Microsoft have both pulled the popular ModHeader extension pulled from their official stores. The header-editing tool, which had roughly 1.6 million installs across Google Chrome and Microsoft Edge, was removed after security researchers uncovered a hidden browsing-history collector buried in its code.

The collector was dormant. An empty allow-list kept it switched off, and no proof has emerged that it ever gathered or sent a single browsing domain. But its mere presence was enough to trigger a takedown from both companies.

What ModHeader Did — and What Got Hidden Inside

ModHeader let developers and power users modify HTTP request headers on the fly. It was a niche but essential tool for testing web apps, debugging APIs, and spoofing headers for development work. Many users installed it years ago and never thought twice about it.

Then researchers at BleepingComputer took a closer look at the extension’s code. They found a function that could collect domains from a user’s browsing history and send them to a remote server. The collector was gated by an allow-list — a list of domains it would actually track. That list was empty.

Empty or not, the code was there. And once you ship code that can exfiltrate data, the damage to trust is done.

1.6 Million Installs — But No Evidence of Data Theft

Here’s the tricky part. The collector was never active. No domains were ever sent. The extension’s developer likely inserted the code as a placeholder for future functionality — or maybe as a test that got accidentally pushed to the store. Either way, it violated each store’s policies against unauthorized data collection.

Google’s Chrome Web Store policy is clear: extensions must only request permissions they actually use. Code that could collect browsing history, even if dormant, is a red flag. Microsoft’s Microsoft Edge Add-ons policy is similarly strict.

Both companies acted fast. The extension was removed within days of the report. Users who already have ModHeader installed can still use it, but it won’t receive updates. And it won’t be available for new installs.

What This Means for Extension Developers

This incident is a sharp reminder: if you include code that can collect user data — even if it’s switched off — you’re playing with fire. Store reviewers are getting better at spotting suspicious patterns. And researchers are constantly scanning popular extensions for hidden functionality.

For users, the lesson is simpler. ModHeader extension pulled from stores doesn’t mean it’s safe to keep using. If you have it installed, consider whether you trust the developer to never flip that switch. Many users are already looking for alternatives like Requestly or Header Editor.

• Check your installed extensions regularly.
• Remove anything you don’t actively use.
• Stick to well-known developers with transparent privacy policies.

Alternatives to ModHeader

If you relied on ModHeader for development work, you’re not stranded. Several alternatives offer similar header-editing capabilities:

• Requestly — open-source, actively maintained, with a clear privacy policy.
• Header Editor — lightweight and focused on modifying request and response headers.
• Modify Headers — another solid option for HTTP header manipulation.

Each of these tools has been vetted by the community. None have hidden data collectors — at least, not yet. That’s the uncomfortable truth about browser extensions: you’re trusting the developer every time you click “Add to Chrome.”

The Bigger Picture: Trust in Browser Extensions

The ModHeader case isn’t an isolated incident. In 2023, Google removed dozens of extensions caught stealing user data. In 2024, a popular ad-blocker was found to be quietly sending browsing data to a marketing firm. The pattern keeps repeating.

Browser extensions are powerful. They can see everything you do — every page you visit, every form you fill, every password you type. That power makes them a prime target for bad actors. And even well-intentioned developers can make mistakes that compromise user privacy.

The ModHeader extension pulled story is a cautionary tale. It shows how quickly trust can evaporate. And it underscores why you should treat every extension as a potential risk — even one with 1.6 million installs and years of good reputation.

For now, the collector remains dormant. But the code is still there. And that’s enough to make anyone think twice.

The 844 MB Wake-Up Call

On May 15, 2026, security firm GitGuardian spotted something alarming: a public GitHub repository named “Private CISA” containing 844 MB of sensitive data from the Cybersecurity and Infrastructure Security Agency (CISA). Inside sat files like “importantAWStokens” — administrative credentials to three AWS GovCloud servers — and a CSV listing plaintext usernames and passwords for dozens of internal CISA systems.

The repository had been public for nearly six months before KrebsOnSecurity alerted the agency. CISA’s own postmortem, published by acting CIO Preston Werntz and acting CISO Brad Libbey, doesn’t sugarcoat what went wrong. It’s a rare, transparent look at how a national cybersecurity agency fumbled its own security — and what every organization can learn from the mess.

Key Rotation Took Too Long

CISA acknowledged the alert quickly, but invalidating the exposed AWS keys and other secrets took more than 48 hours. The agency blamed the delay on “complexities of the agency’s systems and interconnections with federal and industry partners.”

The lesson is blunt: key rotation must be fast and well-practiced. CISA now recommends that all organizations maintain “mature and well-tested key management capabilities.” If rotating a compromised credential takes two days, an attacker has a wide window to cause damage.

Why Speed Matters

Every hour a credential stays live increases risk. The postmortem doesn’t say whether the exposed keys were used maliciously, but it does confirm that detailed logs showed no unauthorized access. That’s lucky — not a strategy.

Nine Ignored Alerts, Six Months of Exposure

Guillaume Valadon, the GitGuardian researcher who first contacted KrebsOnSecurity, revealed a damning detail: CISA had received nine automated alerts about the exposed credentials before the May 15 notification. Each alert went unanswered.

“Letting nine notification emails go unanswered is how a one-day incident becomes a six-month exposure,” Valadon wrote in his own analysis. His point is sharp: automated scanning is useless if nobody reads the reports.

Organizations should configure alerts to escalate if ignored. A single unread email shouldn’t leave sensitive data exposed for half a year.

Reporting Channels Were a Maze

When Valadon tried to report the leak, he hit dead ends. CISA’s vulnerability disclosure platform was designed for product bugs, not reports about the agency’s own infrastructure. He ended up emailing the contractor who leaked the data, submitting through the wrong channel, and eventually going to a reporter.

The postmortem admits these channels “were not well defined.” CISA is now refining them to make reporting faster and easier. The agency also stresses that organizations should publish reporting instructions in multiple prominent locations — not just a security.txt file.

Valadon’s advice: “Make it trivial to report a leak about you, not just about your products. The person reporting a leak to you is not the threat.”

The Playbook Didn’t Cover GitHub

CISA had an incident response playbook, but it somehow didn’t include scenarios involving GitHub or other cloud services. That gap meant the team had to improvise when dealing with a public repository full of their own secrets.

The lesson is straightforward: incident response playbooks must cover modern attack surfaces. Cloud repositories, CI/CD pipelines, and third-party integrations all need dedicated procedures. If your playbook only covers traditional network intrusions, you’re not ready for today’s threats.

Continuous Scanning Is Non-Negotiable

The “Private CISA” repository sat exposed for six months. GitGuardian found it through continuous monitoring of public GitHub — not a quarterly scan. Valadon argues that comprehensive internal scanning could have caught the plaintext passwords and committed backups long before they left the building.

CISA has since rotated all secrets and created an action plan to improve developer secret management and monitoring. The agency now advocates for continuous secrets scanning, a practice Valadon calls “exactly the incident communication we should expect from every organization.”

What Went Right: Logging and Zero Trust

CISA gave itself passing grades on several fronts. Enhanced logging capabilities allowed the agency to gauge the scope and impact of the exposure. Adoption of zero-trust principles in both production and development systems meant that even though credentials leaked, they couldn’t be used outside CISA’s environments.

The agency confirmed that no customer or mission data was exposed, and the contractor who leaked the secrets had their system access revoked. These controls prevented a bad situation from becoming catastrophic.

The Biggest Takeaway: Transparency

Valadon praised CISA for publishing the postmortem at all. “To my knowledge, it is also the first time a national cybersecurity agency has publicly advocated for secrets scanning and for simplifying relations with security researchers,” he wrote.

That’s the real lesson. A detailed, honest post-incident report — one that admits mistakes and offers concrete fixes — builds trust. It also helps the entire security community improve. Every organization should aim for that level of candor.

For more on securing your development workflows, check out our guide on GitHub secrets scanning best practices and learn how to set up automated credential monitoring.