Everyone assumes a patched vulnerability is a solved problem. That’s the comfortable story security teams tell themselves after a CVE gets a fix: the danger passed, move on to the next fire. The China-aligned campaign hitting physics and engineering departments at U.S. and Canadian universities this week says otherwise. The attackers aren’t using some slick zero-day. They’re walking through Roundcube webmail flaws patched back in 2024, including a critical bug rated 9.3 on the CVSS scale. That’s not a cybersecurity failure of technology. It’s a failure of follow-through, and it’s happening at the exact institutions least equipped to catch it.

The Cybersecurity Assumption That’s Getting Universities Breached

Here’s the assumption doing the damage: once a vendor ships a fix, the clock resets. Analysts move on, dashboards go green, and the vulnerability quietly drops off everyone’s mental map. But attackers don’t work off mental maps. They work off scan results. A patch that exists in a changelog somewhere is worthless against a mail server that never got the update. CVE-2024-42009 has been public and fixable for roughly two years, and it’s still opening doors for credential theft against academic networks right now, in mid-2026.

That’s the real lesson buried in this campaign. The vulnerability isn’t the story. The gap between “patch available” and “patch applied,” sustained for years at scale, is the story. And that gap is exactly where threat actors with time, patience, and a state sponsor behind them like to live.

Two Years Isn’t Old. It’s Just Unpatched.

Security teams like to sort vulnerabilities by age, as if age itself provides some kind of protection. It doesn’t. A 2024 bug against an unpatched server is functionally identical to a 2026 bug against an unpatched server: full compromise, no resistance. Age only matters if it correlates with remediation, and in higher education, it frequently doesn’t.

Why Higher Ed Keeps Failing This Test

Universities run some of the most decentralized IT environments in existence. Individual departments stand up their own mail servers, research groups run legacy web apps nobody in central IT even knows exist, and budget cycles move slower than any attacker’s patience. Physics and engineering departments, the specific targets named in this campaign, often sit on valuable research data with none of the security hardening a finance or healthcare system would get by default. No dedicated SOC. No 24/7 threat detection. Sometimes not even a clear owner for the box running Roundcube.

China-aligned actors know this. Academic institutions are a reliable soft target for credential theft and long-term access, not because the data is easy to monetize on a criminal forum, but because it’s valuable for espionage and because nobody’s watching the door.

A Public Exploit Just Rewrote Attackers’ To-Do List

While universities were getting hit through a two-year-old webmail flaw, a second story landed that should worry anyone running Linux at scale. Researchers released a working proof-of-concept for the “Bad Epoll” root escalation flaw. Before this week, exploiting it required real skill and effort. Now it’s copy-paste territory for anyone with a foothold and a terminal.

This is the pattern defenders keep underestimating: a vulnerability’s danger isn’t fixed at disclosure. It changes shape over its lifecycle. A hard-to-exploit bug with no public code is a low-priority patch for a lot of overworked teams. The same bug with a working PoC in circulation is a five-alarm fire, because now every script kiddie and every ransomware affiliate has the tool, not just the handful of researchers who found it first. If your patch queue is prioritized by CVSS score alone, PoC releases like this one will blow right past you.

How To Triage Patches When CVSS Scores Lie To You

CVSS tells you theoretical severity. It doesn’t tell you who’s actually shooting at the bug this week. Here’s a more honest way to rank your patch queue:

1. Check exploit availability first, severity score second. A 7.5 with a public PoC and active exploitation beats a 9.8 sitting quietly in a vendor advisory with zero known abuse.
2. Inventory every internet-facing service you didn’t build recently. Webmail, legacy portals, and anything a department stood up without central IT’s knowledge are exactly where two-year-old CVEs survive.
3. Treat “patched” as a status you verify, not a status you assume. A changelog entry means nothing until you’ve confirmed the fix is actually deployed on every instance.
4. Layer brute-force protection and rate limiting on anything you can’t patch today. If the fix is a week out, a firewall rule that throttles repeated login attempts buys you real time.
5. Feed exploited-in-the-wild lists into your threat-protection tooling automatically. CISA’s KEV catalog and vendor advisories exist precisely so you don’t have to guess which old bugs are hot again.

Defense In Depth For The Bugs You Can’t Patch This Week

Nobody patches everything instantly, and pretending otherwise is how security programs burn out their staff chasing an impossible standard. The realistic goal is defense in depth: enough layers that one missed patch doesn’t equal one breached network. For webmail and other public-facing apps specifically, that means segmenting them away from core research and administrative systems, so a compromised Roundcube instance doesn’t hand attackers a straight line to everything else. It means logging authentication attempts somewhere attackers can’t reach and reviewing them, not just collecting them. And it means building incident response playbooks that assume credential theft from an old, “already fixed” bug is a live scenario, not a hypothetical one.

None of this requires a bigger budget than most IT teams already have. It requires treating patch verification as an ongoing discipline instead of a box you check once when the advisory drops. That shift in mindset is worth more than any single tool you could buy.

Frequently Asked Questions

If a CVE was patched years ago, why is it still dangerous?

A patch only helps systems where it’s actually installed. Many organizations, especially decentralized ones like universities, run internet-facing services that never got updated, so a two-year-old fix does nothing for them. Attackers scan for unpatched instances regardless of a bug’s age.

Does a public proof-of-concept really change how urgently I need to patch?

Yes. Before a PoC exists, exploiting a flaw takes specialized skill, which limits who can use it. Once working exploit code circulates, that barrier disappears, and the pool of attackers capable of using the bug expands overnight, often including opportunistic and less sophisticated actors.

What can under-resourced IT teams do if they can’t patch everything immediately?

Focus on containment while the fix is pending: segment vulnerable services from critical systems, add brute-force protections and rate limiting on exposed logins, and make sure authentication logs are captured somewhere attackers can’t tamper with them. Defense in depth buys time that a single missing patch would otherwise cost you.

Sources

• Suspected China-Aligned Hackers Exploit Roundcube Flaws Against Universities
• Proof-of-Concept Exploit Released for Linux ‘Bad Epoll’ Root Access Vulnerability