Anthropic-Associated CVEs Worth Watching for Storage and Backup

This is a follow-up to an earlier article on CVE-2026-4747 and what AI-assisted vulnerability discovery means for storage infrastructure, which you can read here.

The first wave of CVEs linked to Anthropic’s Claude Mythos Preview is now beginning to emerge. Several sit inside the components that storage and backup products are built on – TLS libraries, kernel subsystems, cryptographic providers, BSD-derived protocol stacks.

Vendor advisories specific to storage and backup have been limited so far.

What follows is our informed assessment of seven CVEs we believe warrant attention. The assessments below are based on previously reported advisories in storage and backup products and on public information about each CVE. They are not confirmed vendor guidance.

Based on this assessment, we also outline practical mitigation considerations and recommended next steps for storage and backup environments.

CVE-2026-31402 – Linux Kernel nfsd Heap Overflow

Critical, kernel.org: 9.8

A remote, unauthenticated attacker can corrupt kernel memory by sending two coordinated NFSv4.0 lock requests that overflow a buffer in the NFS server.

Linux underpins many storage and backup platforms (NAS controllers, backup appliances, HCI nodes). Exposure depends on whether the product uses in-kernel nfsd or a user-space implementation such as NFS-Ganesha. As a precaution, treat Linux-based systems serving NFS as potentially affected until vendors confirm otherwise.

CVE-2026-5194 – wolfSSL Certificate Validation Flaw.

Critical, NVD: 9.1

A signature verification flaw affecting both classical (ECDSA, Ed25519, Ed448) and post-quantum (ML-DSA) algorithms in wolfSSL could allow forged digital identities. Patched in 5.9.1; the bug had been present since 2017.

wolfSSL has appeared in past storage and backup security advisories. While this does not confirm exposure to CVE-2026-5194, it indicates that some vendors may embed the library and is a reason to investigate.

CVE-2026-5588 – Bouncy Castle BC-JAVA Signature Validation Flaw.

High, Redhat: 7.5

A signature verification flaw in Bouncy Castle’s post-quantum certificate code, patched in BC-JAVA 1.84. Most applications don’t use the affected path. More notable in the same release: CVE-2026-3505 (PGP DoS) and CVE-2026-5598.

Bouncy Castle has appeared in past storage and backup vendor advisories. Without a Software Bill of Materials (SBOM), exposure is hard to assess – and fixes arrive only when the vendor ships a refreshed build.

CVE-2026-28386 – OpenSSL AES-CFB-128 Out-of-Bounds Read. 

Critical, CISA-ADP: 9.1

An out-of-bounds read leading to denial of service, affecting systems running on modern x86-64 CPUs with AVX-512. Fixed in OpenSSL 3.6.2 and backports. AES-CFB-128 is uncommon in modern TLS but still appears in S/MIME and some IPsec deployments.

Given OpenSSL’s ubiquity, most vendors will need to assess this – even if urgency is limited by the DoS-only impact – and likely issue an advisory.

CVE-2026-5398 – FreeBSD TIOCNOTTY Use-After-Free.

High, CISA-ADP: 8.4

A local privilege escalation via a dangling pointer in FreeBSD’s terminal handling. Patched in FreeBSD-SA-26:10.tty. Realistic exploitation requires chaining with another vulnerability that provides initial access. FreeBSD-derived storage and backup appliances may be affected.

CVE-2026-6386 – FreeBSD amd64 Local Privilege Escalation

Medium, CISA-ADP: 6.2

Another local privilege escalation issue (FreeBSD-SA-26:11.amd64). Like CVE-2026-5398, it becomes meaningful when combined with an initial foothold, potentially enabling full system compromise.

CVE-2026-4747 – Remote Code Execution in FreeBSD NFS/RPCSEC_GSS

Critical, CISA-ADP: 8.8

We covered this in depth in our previous post. A long-standing stack buffer overflow in RPCSEC_GSS. While patched prior to Mythos, it was highlighted by Anthropic as part of Mythos’s autonomous exploit generation capability. Huawei and NetApp have both published notices confirming their products are not affected.

What to Watch for Next

We expect storage and backup vendors to publish impact assessments as analysis progresses. Monitor vendor security advisory channels closely over the coming weeks.

Five Things To Do While Waiting for Vendor Guidance

These CVEs share a pattern: they affect embedded components in the data and management planes. That shapes the mitigation posture.

1. Start with inventory. Before applying controls, know what you actually have. Build a list of which storage and backup systems are exposed to NFS, expose management interfaces, run Java-based management planes, or are FreeBSD-derived.
2. Revisit protocol hardening. The protocol-level recommendations from our previous post – NFS access restriction, network segmentation, export policy hardening — remain applicable and are worth revisiting in light of this broader pattern.
3. Prefer NFSv4.1+ where possible. CVE-2026-31402 specifically affects NFSv4.0. NFSv4.1 and later use a different session model that doesn’t go through the vulnerable code path.
4. Harden TLS and certificates. Replace broad public CA trust with an internal CA and a small, explicit allowlist. Enable mutual TLS where supported.
5. Isolate the management plane. Restrict management access to the minimum necessary. Block management interfaces on non-management network interfaces. Isolate the management plane at the network level.

Ask Your Vendors for an SBOM

All of these CVEs originate in foundational components and embedded dependencies – not in vendor product code itself.

Without a Software Bill of Materials, determining exposure is difficult before vendors issue advisories.

Ask your vendors for an SBOM, and if they can’t provide one, ask them specifically whether their products include the affected components. A targeted question is more likely to get a useful answer today than a broad SBOM request.

Keeping Pace with Faster Disclosure

This batch is an early indicator of how AI-assisted vulnerability research will reshape disclosure – more CVEs, surfacing faster, in deeper layers of the stack. Before advisories arrive, the only defense is continuous hardening and configuration discipline. Once they land, what matters is the speed of identifying affected systems and prioritizing remediation. Periodic checks won’t keep pace. This is where Core6 focuses with StorageGuard – continuous, real-time posture awareness for storage and backup systems.

For official guidance, refer directly to your storage & backup vendors’ security advisory pages.

References:

• Tracking CVEs Attributed to Anthropic Researchers and Project Glasswing | Blog | VulnCheck
• GitHub – patrickmgarrity/Anthropic-Credited-CVEs: Tracking Vulnerabilities That Appear to be Credited to the Anthropic Research Team · GitHub
• freebsd.org/security/advisories/FreeBSD-SA-26:08.rpcsec_gss.asc
• NetApp Product Security – NTAP-20260410-0014
• NetApp Statement Regarding Anthropic Disclosure and Mythos Research Model
• CVE-2026-5588 – Red Hat Customer Portal

---

Frequently Asked Questions (FAQs)

What should you ask your storage or backup vendor right now?

Instead of asking broadly, ask targeted questions:

• “Do your products include wolfSSL / Bouncy Castle / OpenSSL versions affected by these CVEs?”
• “Are you using in-kernel NFS or a user-space implementation?”
• “Are any products based on FreeBSD and affected by SA-26 advisories?”

Also request: SBOM (Software Bill of Materials). This is the fastest way to validate risk across your environment.

How will AI-driven vulnerability discovery change storage security?

Expect:

• More CVEs
• Faster disclosure cycles
• Vulnerabilities in deeper infrastructure layers

Traditional approaches (quarterly reviews, manual audits) will struggle to keep up.

New requirement:

• Continuous visibility into storage security posture
• Real-time detection of configuration risks and exposure

What is the biggest takeaway for storage and backup teams?

These CVEs highlight a shift:

• Risk is increasingly in dependencies, not product code
• Exposure exists before vendor advisories are published

Actionable takeaway:

• Focus on hardening, segmentation, and visibility
• Reduce reliance on reactive patch cycles
• Speed up identification of affected systems