18 Critical CVEs, One Patch Plan

This week brought 18 critical CVEs, and almost every one carries a CVSS score of 9.0 or higher. Four of them score a perfect 10. If your organization runs a hospital network, a clinic group or a health-tech platform, that list doesn't fit neatly into a single maintenance window, and it shouldn't be handled as if it does. Effective vulnerability prioritization in healthcare starts from a simple premise: a CVSS score tells you how bad a flaw could be in the abstract. It doesn't tell you how bad it is in your environment, next to your protected health information.

Below, we walk through how our analysts triage a week like this one, using three of this week's CVEs as worked examples: CVE-2026-120345, CVE-2026-120322 and CVE-2026-62048. Then we cover the harder problem: what to do about systems you can't patch on schedule, like clinical devices and vendor-managed EHR components.

Why CVSS Alone Fails in Clinical Environments

CVSS measures intrinsic severity. It's a useful starting signal, but when 18 findings all sit between 9.1 and 10.0, the scores stop differentiating anything. A 9.9 and a 10 are functionally identical on paper, yet one might be on an internet-facing gateway in front of your patient portal while the other sits on a lab router that's been unplugged since 2024.

Healthcare adds two complications most industries don't face:

• Patching has clinical consequences. Rebooting an infusion pump management server or a PACS node mid-shift isn't a routine IT decision. It's a patient-safety decision.
• Much of the stack isn't yours to patch. EHR hosting, imaging modalities and connected medical devices are often vendor-managed, with update cycles governed by contracts and, in the device world, FDA-cleared configurations.

The HIPAA Security Rule doesn't ask you to patch everything instantly. It asks you to perform an accurate risk analysis (45 CFR 164.308(a)(1)(ii)(A)) and to implement security measures that reduce risk to a reasonable and appropriate level (164.308(a)(1)(ii)(B)). That's a prioritization mandate, and OCR investigators look for evidence that your decisions followed a defensible method rather than a sorted spreadsheet column.

How We Rank: Exposure, Exploitability and PHI Proximity

Our SOC scores each critical CVE on three factors, each rated 1 to 3, and multiplies them. CVSS stays on the worksheet as a tiebreaker, not the driver.

Factor	3 (High)	2 (Medium)	1 (Low)
Exposure	Internet-facing or reachable from guest/patient Wi-Fi	Reachable from the general corporate network	Segmented, management-VLAN only, or not deployed
Exploitability	Public exploit available or active exploitation reported	Technical details published, no working exploit seen	Theoretical, requires unusual preconditions
PHI Proximity	Stores, processes or directly brokers ePHI	One hop from ePHI systems (shared credentials, flat network)	No meaningful path to ePHI

A score of 18 to 27 means emergency change within 72 hours. A score of 8 to 12 means the next scheduled window. Anything below that gets tracked and folded into routine cycles. The thresholds matter less than the fact that they're written down and applied the same way every week. That consistency is what turns a patching decision into audit evidence.

The first question is always inventory

Before scoring anything, we confirm whether the affected product actually exists in the environment. It sounds obvious, but in our experience a surprising number of critical findings fall away at this step. A WAVLINK range extender isn't standard hospital equipment, but it does turn up in satellite clinics, home-health setups and physician offices where someone bought hardware off the shelf. Continuous attack-surface scanning answers this question in minutes instead of days, which is why we run vulnerability assessments as an ongoing process rather than a quarterly snapshot.

Three CVEs, Three Different Outcomes

CVE-2026-120345: WAVLINK WN551X3-A command injection (CVSS 10)

CVE-2026-120345 is an OS command injection in WAVLINK WN551X3-A firmware M51X3_V251020-WO-182e965. The flaw sits in the DNS Resolution Handler (function sub_41a430 in /bin/ioos), where manipulating the data argument lets an attacker run commands remotely. A public exploit exists. Its sibling, CVE-2026-120344, hits the same device through the WireGuard CLI Group Handler's group_name argument, and CVE-2026-120279 affects the WN536AX6-A (V260507) via the openvpn_cli handler in /protocol.csp. All three score 10 and all have published exploits.

The advisories note the vendor was contacted early, but they don't list a fixed firmware release. So remediation here is containment, not patching:

1. Locate every instance through network discovery and DHCP logs, especially at remote sites.
2. Disable remote management and block WAN-side administrative access.
3. Move any surviving devices onto an isolated segment with no route to clinical or EHR networks.
4. Plan replacement with enterprise-managed hardware. Consumer gear with unpatched public exploits doesn't belong anywhere near ePHI.

Our scoring: If one of these is bridging a clinic's front-desk network, that's Exposure 3, Exploitability 3, PHI Proximity 2 or 3. That's an 18 to 27 and an emergency change. If inventory finds none, it drops off the list entirely.

CVE-2026-120322: Termix path traversal (CVSS 9.9)

CVE-2026-120322 affects Termix-SSH Termix up to version 2.9.2. Manipulating the destPath argument at /plugin-api/file-manager/transferToHost allows path traversal, and it's remotely exploitable with a public exploit available. Termix is a web-based SSH and server management tool, which is exactly why it worries us. Admin tooling tends to hold the keys to everything else.

In a health-tech company, a self-hosted Termix instance used by DevOps engineers could sit one hop from production databases holding patient records. Write a file to the wrong place on a managed host and you have a foothold that leads straight to ePHI.

Remediation: Upgrade off Termix 2.9.2 and earlier. Per the advisory, the vulnerable shortcut was removed in the standalone File Manager plugin v1.0.0, so move to that plugin. Until then, put the Termix interface behind VPN or SSO-gated access, and review the file-transfer logs on managed hosts for unexpected writes.

Our scoring: Exposure depends on whether it's internet-facing (we've seen plenty that are). Exploitability is 3. PHI Proximity is often 3 for engineering teams with production access. This is frequently the top item of the week.

CVE-2026-62048: when details are still thin

Not every CVE on a weekly list arrives with complete, verified vendor guidance at triage time. For entries like CVE-2026-62048, where we haven't yet confirmed the affected-product and fixed-version details against the vendor's own advisory, we don't guess. The process is the same: confirm presence in inventory, score exposure and PHI proximity on what you know, mark exploitability as provisional, and set a re-review date. A documented "pending vendor guidance" entry with a deadline is far more defensible to an auditor than a CVE that silently sat in a queue.

The rest of the list, briefly

Several other critical CVEs this week deserve a quick look if they're in your stack:

• Control Web Panel: CVE-2026-77876 (CVSS 9.8) is OS command injection via the file parameter in the protected_directory module, fixed in webpanel_version 1.16. CVE-2026-73696 (CVSS 9.1) is an unauthenticated auth bypass from a missing exit() after a redirect, fixed in 1.12. Upgrade to 1.16 or later to close both.
• ape-volo-admin: CVE-2026-120442 (CVSS 9.8) uses a hardcoded JWT signing key in appsettings.json, letting attackers forge admin tokens offline. Upgrade to 3.6.1 and rotate the signing key, since any previously deployed key should be considered compromised.
• @fastify/http-proxy: CVE-2026-120213 (CVSS 9.1) affects versions 9.0.0 through 11.6.5 when parameterized prefix and rewritePrefix are used, since decoded parameters aren't re-encoded. Upgrade past 11.6.5. Health-tech API gateways built on Fastify should check this one first.
• SUSE Rancher Fleet: CVE-2026-94290 (CVSS 9.1) lets a Fleet Cluster object in a user-controlled namespace reference administrative kubeconfig secrets. Apply SUSE's patched Fleet release and audit which namespaces ordinary users control.
• madong-admin-saas: CVE-2026-120446 (CVSS 9.4) exposes unauthenticated tenant-management APIs through 5.1.4. With no fixed version listed, block external access to /platformapi/ routes at the proxy.
• Linksys E8450: CVE-2026-120283 (CVSS 10) is a stack-based buffer overflow in portal.cgi on firmware 1.2.00.360516. The vendor didn't respond to disclosure, so isolate or replace.

None of these were flagged in the advisories we reviewed as being on CISA's Known Exploited Vulnerabilities catalog at the time of writing. Check KEV during your own triage anyway, because that status changes fast, and a KEV listing should automatically raise exploitability to 3.

When You Can't Patch on Schedule

This is where healthcare vulnerability management gets genuinely hard. Your imaging modality runs an embedded OS the manufacturer must validate before you touch it. Your EHR vendor hosts the application tier and patches on its own calendar. A bedside device can't go offline until the unit is quiet. You still own the risk, even when you don't own the patch.

Compensating controls that actually reduce risk

A compensating control should break at least one of the three scoring factors. If it doesn't lower exposure, exploitability or PHI proximity, it's just paperwork.

Control	Factor it reduces	HIPAA / framework mapping
Micro-segmentation of clinical device VLANs	Exposure	164.312(e)(1) transmission security; NIST CSF PR.IR
Block vulnerable ports/paths at firewall or WAF	Exploitability	164.308(a)(1)(ii)(B) risk management; CIS Control 4
Remove shared credentials and enforce MFA on admin consoles	PHI Proximity	164.312(a)(1) access control; 164.312(d) authentication
Enhanced SOC monitoring with device-specific detections	Exploitability (time to detect)	164.308(a)(1)(ii)(D) information system activity review
Disable unused services and remote management	Exposure	CIS Control 4; HITRUST 01.l

For vendor-managed EHR components, the move is contractual as much as technical. Ask the vendor in writing for its remediation timeline, the compensating controls it has applied on its side, and confirmation of whether ePHI on the affected component was exposed. Your business associate agreement should support those requests. If it doesn't, that's a gap to raise at renewal.

Documented risk acceptance

When a system stays unpatched past your SLA, record a formal risk acceptance. At minimum it should include:

• The CVE, the affected asset and its location relative to ePHI
• The current three-factor score and the score after compensating controls
• Why patching is deferred (vendor validation, clinical uptime, contract)
• The named owner who accepted the residual risk, at an appropriate level of authority
• An expiration date and the trigger that forces re-review, such as a KEV listing or exploitation reports

This record is what you'll hand OCR if a breach investigation ever asks why a known critical flaw was still present. It's also what HITRUST assessors want when they test your vulnerability management control. Our governance and GRC work maps each acceptance to the specific Security Rule safeguard it touches, so the evidence exists before anyone asks for it.

Turning One Bad Week Into a Repeatable Process

The teams that handle a week like this calmly aren't the ones with the biggest patch crews. They're the ones who already know what they own, where ePHI lives and who signs off on deferred risk. A practical cadence looks like this:

1. Day 0: Ingest new criticals, confirm inventory presence, drop what doesn't apply.
2. Day 1: Score exposure, exploitability and PHI proximity. Open emergency changes for anything 18 or above.
3. Days 2 to 3: Patch or apply compensating controls on the top tier. Engage vendors for anything they manage.
4. Day 7: Validate fixes. A targeted penetration test against your highest-scored assets confirms the exposure is actually closed, not just marked closed.
5. Ongoing: Review every open risk acceptance before it expires.

Eighteen criticals is a lot of noise. But only a handful will sit close to your patient data and within an attacker's reach, and those are the ones that deserve your Thursday night. Rank by what matters in your environment, write down why, and the rest of the list becomes manageable.