CVE-2026-4747, FreeBSD RPCSEC_GSS Remote Code Execution

CVE-2026-4747 is one of those vulnerabilities that became important for two separate reasons at once. First, the bug itself matters: it is a real remote code execution issue in FreeBSD’s RPCSEC_GSS packet validation path, disclosed by the FreeBSD Project on March 26, 2026, and affecting all supported FreeBSD versions at the time of disclosure. Second, the public conversation around it matters: official language, NVD language, AI lab write-ups, and independent exploit write-ups do not all describe the attack path in exactly the same way. For defenders, that combination is now common enough that it deserves its own response pattern.

The strongest starting point is the FreeBSD advisory, not social media screenshots, not secondhand summaries, and not breathless claims about what a model supposedly did in four hours. The advisory states that each RPCSEC_GSS data packet is validated by a routine that copies part of the packet into a stack buffer without ensuring the buffer is large enough, allowing a malicious client to trigger a stack overflow. It also states that all supported versions of FreeBSD were affected, that no workaround was available, and that kernels without kgssapi.ko loaded were not vulnerable. That already tells you something crucial: this is not a generic “all FreeBSD hosts are instantly dead” story. Exposure depends on service role and module state.

At the same time, it would be a mistake to overcorrect into complacency. NVD’s public page for CVE-2026-4747 exists, and as of April 13, 2026 it still showed the record as awaiting NVD analysis, while also displaying a CISA ADP CVSS 3.1 score of 8.8 High. NVD also points to public exploit material and the official FreeBSD advisory. In other words, even before full NVD enrichment, the record is already part of the operational vulnerability stream that defenders should treat seriously.

What makes this case especially worth studying is that it sits right at the intersection of three things security teams now have to handle at the same time: legacy protocol code, memory safety bugs in privileged paths, and a public environment where exploit construction can move very quickly once a vendor bulletin appears. CVE-2026-4747 is not just another line item in a patch queue. It is a useful case study in how to read modern disclosure material without letting either vendor caution or research hype do your thinking for you.

CVE-2026-4747 confirmed facts from FreeBSD and NVD

The FreeBSD advisory identifies the topic as “Remote code execution via RPCSEC_GSS packet validation,” credits “Nicholas Carlini using Claude, Anthropic,” and marks all supported FreeBSD versions as affected at disclosure time. The corrected release lines listed by FreeBSD were 13.5-RELEASE-p11, 14.3-RELEASE-p10, 14.4-RELEASE-p1, and 15.0-RELEASE-p5, with corresponding fixes in the stable and releng branches. Those are the versions defenders should use as their minimum patch baselines, not just “some update from late March.”

The advisory’s impact section is careful and specific. For the kernel path, it says remote code execution is possible by an authenticated user who can send packets to the kernel’s NFS server while kgssapi.ko is loaded. For user space, it says applications that have librpcgss_sec loaded and run an RPC server are vulnerable to remote code execution from any client able to send them packets, while also noting that FreeBSD was not aware of such applications in the base system. That distinction matters, because many write-ups flatten the whole issue into one dramatic sentence and lose the difference between kernel exposure and user-space exposure.

NVD’s public record mirrors the vendor description in the places that matter most. It repeats the stack-based buffer overflow root cause, notes that the packet validation routine can be triggered without authenticating first, and preserves the vendor’s more conservative wording for kernel-space remote code execution. It also shows the record as sourced from FreeBSD, published on March 26, 2026, with later updates adding exploit and write-up references. That combination is exactly what defenders should expect now: an official record with restrained language, and a fast-growing public ecosystem of downstream analysis.

A concise way to organize the confirmed facts is this:

Item	What is confirmed publicly
Vulnerability ID	CVE-2026-4747
Vendor source	FreeBSD
Public disclosure date	March 26, 2026
Core issue	Stack-based buffer overflow in RPCSEC_GSS packet validation
Kernel exposure path	NFS server with kgssapi.ko loaded
User-space exposure path	RPC servers linked with librpcgss_sec
Vendor workaround	No workaround available
Practical exception	Kernels without kgssapi.ko loaded are not vulnerable
Fixed release baselines	13.5-p11, 14.3-p10, 14.4-p1, 15.0-p5
NVD status on April 13, 2026	Awaiting NVD analysis, CISA ADP 8.8 High shown

This table is not glamorous, but it is the part most incident and vulnerability teams actually need to act on.

CVE-2026-4747 background, RPCSEC_GSS, NFS, and why this path is sensitive

To understand why this bug is serious, you need only a modest amount of protocol context. RPCSEC_GSS is the mechanism that brings GSS-based security services into Sun RPC. In practical NFS deployments, that usually means Kerberos-backed authentication, integrity, or privacy. The FreeBSD advisory describes RPCSEC_GSS as the module that enables the use of GSS with Sun RPC servers, implemented in the kernel by kgssapi.ko and used by the NFS server for Kerberos-based authentication and encryption between server and clients.

That description is consistent with broader kernel RPC documentation outside FreeBSD as well. The Linux kernel documentation for kernel RPC servers explains RPCGSS as the GSSAPI authentication method used for NFS, and notes that the kernel path handles per-packet integrity and privacy work while initial context establishment is handled through userspace support. That does not prove anything about FreeBSD internals by itself, but it reinforces the architectural point: this is not an obscure admin tool. It is part of the security boundary for a high-value network file service.

The reason NFS matters here is not just popularity. It is privilege and reach. The public Calif write-up says kgssapi.ko implements RPCSEC_GSS authentication for the kernel’s RPC subsystem and that NFS is the primary in-kernel RPC service using it. It also points out that nfsd listens on port 2049/TCP and processes RPC packets in kernel context. Even if you never read a single line of exploit code, that is enough to understand the risk class: attacker-controlled network input reaching a kernel-side service path with memory corruption potential.

This is also why shallow summaries fail readers. If someone tells you “the bug is in Kerberos NFS,” that sounds narrower than it really is. If someone tells you “all NFS on FreeBSD is unauthenticated root from the internet,” that is broader than what the official vendor language guarantees. The useful middle position is more precise: the vulnerable logic sits inside the RPCSEC_GSS validation path, the kernel exposure story centers on NFS with kgssapi.ko present, and the operational priority depends on whether your environment actually exposes that path.

CVE-2026-4747 root cause in svc_rpc_gss_validate

The most technically useful public description of the bug comes from the public write-up referenced by NVD. It explains that in sys/rpc/rpcsec_gss/svc_rpcsec_gss.c, the function svc_rpc_gss_validate() reconstructs an RPC header into a 128-byte stack buffer for GSS-API signature verification. According to that write-up, the function writes a fixed amount of RPC header data first, then copies the entire RPCSEC_GSS credential body into the remaining space without checking whether the credential length actually fits. Anthropic’s Mythos write-up describes the same pattern more compactly: a method copies attacker-controlled packet data into a 128-byte stack buffer starting 32 bytes in, leaving only 96 bytes of room, while the only source length check enforces a maximum of 400 bytes.

That is the heart of the vulnerability. Not “NFS is old.” Not “Kerberos is risky.” Not “AI found a weird corner case.” The heart of the bug is a familiar memory safety failure: trusted code assumes a packet-derived length will remain compatible with a small local buffer, but the actual allowed protocol input range is far larger. Once that happens in a kernel-facing service path, the bug stops being an implementation embarrassment and becomes an operational problem.

A simplified representation of the bug looks like this:

int32_t rpchdr[128 / sizeof(int32_t)];   // 128 bytes total
write_fixed_rpc_fields(rpchdr);          // 32 bytes used

// credential length comes from the incoming packet
memcpy(rpchdr + 8, credential_body, oa_length);  // no check that oa_length fits

That is not the exact vendor patch, and it is not intended as exploit material. It is a teaching model. The point is to help readers see why the issue is a stack overflow rather than a vague “validation bug.” The bug class is simple enough that many engineers can understand it instantly once it is shown this way.

The Calif write-up adds an important detail for risk interpretation: the XDR layer permits MAX_AUTH_BYTES = 400, which means the copy source may be vastly larger than the safe space left in the 128-byte buffer after fixed fields are written. That is why the issue supports more than a crash narrative. A memory corruption bug with this geometry in a privileged service path will naturally draw exploit development attention.

CVE-2026-4747 and the authenticated versus unauthenticated confusion

This is where the public discussion gets messy, and where careful writing matters more than dramatic writing. The FreeBSD advisory says a malicious client can trigger the stack overflow and adds, notably, that this does not require the client to authenticate itself first. But in the same advisory, when FreeBSD describes kernel-space impact, it says remote code execution in the kernel is possible by an authenticated user able to send packets to the kernel’s NFS server while kgssapi.ko is loaded. For user-space RPC servers linked against the vulnerable library, the advisory is again broader: remote code execution from any client able to send packets.

Anthropic’s public Mythos write-up is more aggressive. It says Mythos Preview identified and exploited the vulnerability and describes the result as complete control of a FreeBSD server starting from an unauthenticated user anywhere on the internet. The same write-up describes the attack as a straightforward ROP opportunity once the attacker reaches the vulnerable memcpy, then explains that incoming requests need a 16-byte handle matching a live GSS client entry and suggests that an attacker can create that entry via an unauthenticated INIT request, albeit with additional information requirements involving hostid and boot time.

Then you get the Calif write-up and exploit repository, also referenced publicly, which go in a different direction operationally. That material says the vulnerable function is only reached after several conditions are satisfied: the packet uses RPCSEC_GSS, the procedure is DATA, the server finds a valid client entry matching the context handle, and the replay sequence check passes. It further says that without a valid GSS context the server rejects the packet before the vulnerable copy is reached, and that creating that valid context requires a successful Kerberos handshake. Its public exploit code explicitly states that it requires a Kerberos ticket and targets a FreeBSD 14.4-RELEASE amd64 lab setup with NFS and kgssapi.ko.

Those sources are not perfectly aligned, but they do not necessarily contradict each other in a simple yes-or-no way. The most defensible reading is that the public sources are describing different levels of the attack chain with different confidence thresholds. Triggering the vulnerable logic is one question. Building a reliable, end-to-end kernel RCE chain with no prior credentials is a second question. Generalizing that path across environments is a third. Vendors tend to speak conservatively about stable impact. Researchers and AI lab write-ups often emphasize the strongest demonstrated chain. Defenders need both views, but they should not collapse them into one sentence.

This is exactly why CVE-2026-4747 is more interesting than a routine patch notice. It is a public example of how wording matters in the AI era. The official record, the lab narrative, and the public exploit path may all be “true” within their own scope, while still creating confusion for teams that want a simple headline. The right operational response is not to choose your favorite phrasing. It is to patch on the higher-risk interpretation while documenting your environment against the stricter preconditions.

CVE-2026-4747 affected releases and corrected versions

For patch management, the most important lines are straightforward. FreeBSD says all supported versions were affected, and the corrected release baselines were 13.5-RELEASE-p11, 14.3-RELEASE-p10, 14.4-RELEASE-p1, and 15.0-RELEASE-p5. The advisory also lists the corresponding stable and releng branch commits. If you run one of those release families below the corrected patch level, you should treat the host as vulnerable until updated and rebooted.

A patch planning view looks like this:

Release line	Vulnerable before	Corrected at
FreeBSD 13.5	p11	13.5-RELEASE-p11
FreeBSD 14.3	p10	14.3-RELEASE-p10
FreeBSD 14.4	p1	14.4-RELEASE-p1
FreeBSD 15.0	p5	15.0-RELEASE-p5

If you build from source or track stable branches rather than RELEASE patch levels, use the advisory’s listed commit hashes and branch revisions as your source of truth. That is especially important in environments where release strings, kernel strings, and deployed binaries are not always interpreted consistently by operators.

CVE-2026-4747 exposure triage, how to tell whether you should panic now or patch urgently and calmly

Not every vulnerable version is an equally exposed asset. A useful triage sequence starts with five questions.

First, is the system running an affected FreeBSD release family below the corrected patch level. Second, is it actually acting as an NFS server or otherwise running an RPC server in scope. Third, is kgssapi.ko loaded in the kernel. Fourth, is port 2049 reachable from untrusted or semi-trusted networks. Fifth, do you use Kerberos-backed NFS or any user-space RPC service linked with librpcgss_sec. The farther you move down that list toward “yes,” the more the issue stops being a version-management task and becomes a service-exposure incident.

This is the point where a lot of vulnerability programs lose credibility with engineers. If the message to ops is “every FreeBSD machine is a critical emergency,” the engineers who know their fleet will tune you out. But if the message is “it is only a theoretical NFS edge case,” you are also wrong. The operational truth is narrower and more urgent than either caricature: hosts that meet the service and module conditions deserve fast handling, and hosts that do not meet those conditions still deserve version hygiene because service roles change over time.

This is also where environment-aware validation becomes more important than static CVSS sorting. A host with an affected release string but no NFS role and no kgssapi.ko load state is not your highest-priority ticket. A host on the same release running internet-reachable or broadly reachable NFS with Kerberos-backed access is a very different problem. Good vulnerability handling is not only about identifying a CVE match. It is about turning that match into evidence about real exposure.

In practice, that means your triage notes should record at least four concrete facts per asset: the exact FreeBSD version and patch level, whether kgssapi.ko is loaded, whether nfsd is enabled and listening, and what networks can reach 2049/TCP. Without those four facts, most prioritization arguments around CVE-2026-4747 are hand-waving.

CVE-2026-4747 host-side verification commands that actually help

On a FreeBSD host, start by checking installed and running version strings. You want to know what kernel and userland patch levels are present, and whether the currently running kernel reflects the post-fix state after reboot. FreeBSD operators often use freebsd-version -kru for exactly this reason, because it shows installed kernel, running kernel, and userland together. A March 2026 FreeBSD forum thread about this very advisory shows how patch-level interpretation can still confuse people after an update if they only look at one dimension of versioning.

freebsd-version -kru
uname -a

Next, verify whether the vulnerable kernel module is actually loaded and whether the system is acting as an NFS server.

kldstat | grep -w kgssapi
service nfsd status
sysrc -a | egrep '^(nfs_server_enable|rpcbind_enable|mountd_enable)'
sockstat -46l | egrep '(:2049|rpcbind)'

These commands help answer the two most important exposure questions from the advisory: is kgssapi.ko present, and is the kernel NFS path active and reachable. The advisory is explicit that kernels without kgssapi.ko loaded are not vulnerable, so that check is not optional busywork.

If you maintain custom RPC services, add an application inventory step. The official advisory says user-space applications with librpcgss_sec loaded and running an RPC server are also vulnerable, even though FreeBSD was not aware of such applications in the base system. That means your base OS posture may be fine while a custom daemon or packaged service still needs attention. Inventory, not assumption, is the right response.

If your NFS servers are meant to be restricted to specific internal segments, confirm that your network enforcement still matches policy. Do not assume that “internal only” means “low risk.” Many NFS environments exist specifically so authenticated users across broad enterprise networks can reach them, and the public write-up for CVE-2026-4747 explicitly treats a valid Kerberos-backed user in such an environment as a realistic attacker model.

CVE-2026-4747 safe remediation, patching, containment, and retesting

FreeBSD’s guidance is direct: upgrade to a supported FreeBSD stable or release/security branch dated after the correction date. For systems installed from binary distribution sets, the advisory recommends freebsd-update fetch followed by freebsd-update install, and then a reboot. For source-based environments, it points to a specific security patch and standard rebuild workflow. For some 15.0-RELEASE base-package installations, it also documents the package-base update route.

freebsd-update fetch
freebsd-update install
shutdown -r now

If you are patching from source, follow the official patch and signature verification path from the advisory rather than pulling unverified diffs from mirror sites or copied gists. The advisory explicitly provides the patch location and detached PGP signature flow. For a bug that already has public exploit discussion around it, chain-of-custody discipline on the fix path is not paranoia. It is standard operational hygiene.

Before your maintenance window, shrink exposure where possible. The advisory says no workaround is available, but it also gives a practical exception: kernels that do not have kgssapi.ko loaded are not vulnerable. That does not mean every operator can safely unload the module on a live production system, but it does mean temporary service disablement, access restriction, or module unloading may be reasonable risk-reduction steps where the environment allows it. The right short-term move depends on whether the host’s NFS role is essential.

After patching, do not close the ticket on version text alone. Retest the same exposure facts you used during triage: corrected release level, running kernel after reboot, module state, service state, and listening exposure. The most common operational failure after a high-profile advisory is not “we forgot the CVE existed.” It is “we marked it done when one command looked good.” For cases like CVE-2026-4747, closure should mean evidence, not optimism.

In real operations, the hard part is usually not understanding the advisory. The hard part is turning that advisory into a repeatable verification workflow across many systems, then rerunning the same checks after changes. That is where scope-controlled validation platforms are more useful than generic chat summaries. Penligent’s public materials emphasize operator-controlled agentic workflows, locked scope, and repeatable actions, and its own writing on the Mythos discussion emphasizes that public descriptions move faster than environment-specific validation. That is the right operational lesson here: what closes risk is evidence that your specific service path is patched or no longer exposed.

CVE-2026-4747 and the user-space angle many teams will miss

A surprising amount of public coverage centers so heavily on the kernel NFS story that readers never absorb the user-space clause in the official advisory. FreeBSD explicitly says that applications with librpcgss_sec loaded and running an RPC server are vulnerable to remote code execution from any client able to send them packets, even though it is not aware of such applications in the FreeBSD base system. That does not sound dramatic in headlines, but from an enterprise asset perspective it is exactly the kind of sentence that creates blind spots if ignored.

Why does that matter? Because many organizations run more RPC-adjacent software than they think they do, especially in older infrastructure, storage, scientific computing, and mixed Unix estates. A vulnerability program that only checks whether nfsd is enabled may miss an application owner who linked in the relevant library years ago and now considers the service “internal tooling.” The advisory does not tell you such software definitely exists in your estate. It tells you that, if it does, the risk model extends beyond kernel NFS. That is enough to justify an application inventory pass.

A good internal note for app owners is simple: if you run or ship an RPC server on FreeBSD and are not certain whether librpcgss_sec is in the process image or dependency tree, verify it now. This is one of those rare advisory details that looks niche until it turns into the exact exception that mattered on your network.

CVE-2026-4747 compared with CVE-2026-31402, the pattern in old protocol code

CVE-2026-4747 is not useful only as an isolated bug. It is useful as a reminder of a broader engineering pattern. A closely related example is CVE-2026-31402 in the Linux kernel, published by NVD on April 3, 2026. That issue affected the NFSv4.0 LOCK replay cache. According to the NVD description, the code used a fixed 112-byte inline buffer for encoded replay responses, but failed to account for LOCK denied responses that could include a variable-length conflicting owner field up to 1024 bytes. The result was a slab out-of-bounds write of up to 944 bytes beyond the buffer.

The two issues are not the same bug and do not deserve to be conflated, but they rhyme in the ways that matter for defenders. Both sit in old, complex protocol-handling paths. Both involve fixed-size storage assumptions meeting variable-length encoded inputs. Both are the sort of code many teams mentally classify as “mature infrastructure,” which often means “nobody has looked at it closely in a long time.” And both reinforce the same operational lesson: version age and deployment maturity do not protect protocol code from memory-safety failures.

A comparison helps make the pattern concrete:

CVE	Platform	Component	Memory issue	Notable trigger condition	Fix direction
CVE-2026-4747	FreeBSD	RPCSEC_GSS validation in NFS-related kernel path and related user-space library path	Stack-based buffer overflow	RPCSEC_GSS packet validation path, kernel path tied to kgssapi.ko and NFS exposure	Update to corrected FreeBSD branches and releases
CVE-2026-31402	Linux kernel	NFSv4.0 LOCK replay cache	Heap out-of-bounds write	Large lock-owner encoding in replay cache response	Bounds-check encoded response length before copying

This is not trivia. It is the kind of comparison that changes where good engineers look next.

CVE-2026-4747 and AI-assisted exploit development

Even if you set the AI narrative aside, CVE-2026-4747 would already matter as a FreeBSD kernel-adjacent remote code execution issue. But the AI narrative is not noise here. It is part of why the bug received outsized attention. Anthropic’s Mythos write-up presents the FreeBSD issue as one of its flagship public examples, saying the model fully autonomously identified and exploited the vulnerability. Calif’s public write-up, in turn, presents a timeline where a public advisory is followed very quickly by AI-assisted exploit construction. Those claims should not be repeated uncritically, but they should not be dismissed either. They change how defenders should think about patch latency.

The important change is not philosophical. It is operational. If public advisory language plus a codebase pointer plus a few hours of focused reasoning can produce exploit-quality work faster than many organizations can even triage the impact on their own fleet, then the old assumption that “we have a few days before offensive quality catches up” becomes less safe. CVE-2026-4747 is useful because the public evidence around it already looks like the kind of advisory-to-exploit compression defenders worry about, regardless of whether every claim in every write-up is equally strong.

This is also why wording discipline matters so much. If your SOC ticket says “unauthenticated internet root on all FreeBSD NFS” and that turns out to overstate the conditions in your environment, you lose trust. If your ticket says “vendor says authenticated kernel path only, so low urgency,” you may be taking the narrowest possible reading while public exploit work is already moving. The right message is: a serious memory corruption issue exists in an exposed protocol path, official and public exploit descriptions differ at the edges, and that is a reason to move faster, not slower.

For security leaders, the practical implication is simple. Treat public-source disagreement as a prompt for environment validation, not as permission to defer action. In 2026, “the sources disagree” is often the beginning of the operational task, not the end of it. CVE-2026-4747 is a clean example of why mature teams need both disciplined triage and rapid retesting.

CVE-2026-4747 lessons for blue teams, infrastructure teams, and vulnerability management

For infrastructure teams, the first lesson is that service role matters more than abstract platform fear. You do not need to treat every FreeBSD asset the same, but you do need to know which ones actually run NFS, which ones load kgssapi.ko, and which ones expose 2049/TCP beyond a narrow trusted zone. If that information is not already in inventory, the inventory gap is part of the risk.

For blue teams, the lesson is to separate exploitability from observability. The public sources do not hand you a polished, universal detection rule. They do tell you where to look: NFS service changes, RPCSEC_GSS use, access to 2049/TCP, anomalous traffic against systems that should not be receiving broad NFS traffic, and unusual behavior around services that depend on Kerberos-backed NFS. Good detection engineering starts from service context, not from a wish that every kernel bug comes with a ready-made signature.

For vulnerability management teams, CVE-2026-4747 is a reminder that “affected software” is not a complete risk statement. The advisory itself gives you the ingredients for a better prioritization model: module load state, service role, network reachability, and whether the user-space library path is relevant. A mature program should record those factors and use them to drive sequencing. Otherwise, you end up treating a dormant lab VM and a production Kerberos-backed NFS server as equivalent because both match the same version fingerprint.

And for organizations trying to operationalize repeated retesting, this is exactly the kind of case that benefits from automation without giving up human judgment. The right automation does not invent exploit stories. It reruns the host checks, confirms the fixed release level, records whether the risky service path still exists, and preserves the evidence. Penligent’s public product and content pages both point in that direction: controlled agentic workflows, scoped actions, and verification over vague reassurance. That is a useful posture for CVE-2026-4747 and for the broader class of protocol-path vulnerabilities that look quiet until they do not.

CVE-2026-4747, what to say internally if you need one precise summary

If you need a short internal summary for an engineering channel, use something like this:

CVE-2026-4747 is a FreeBSD RPCSEC_GSS stack overflow in packet validation, disclosed by FreeBSD on March 26, 2026. The official advisory says all supported FreeBSD versions were affected at disclosure time, that kernel-space RCE is possible in the NFS path when kgssapi.ko is loaded, and that user-space RPC servers linked with librpcgss_sec are also in scope. Public write-ups describe stronger exploitation claims than the vendor advisory, so treat exposed NFS and related RPCSEC_GSS paths as urgent to patch and verify, not as a wording debate.

If you need a short leadership summary, use this:

The risk is not “all FreeBSD hosts are compromised.” The risk is that a real memory corruption bug exists in a privileged protocol path, public exploit discussion already exists, and the organizations most at risk are those exposing the relevant NFS and RPCSEC_GSS service path while still below the corrected patch levels. The right response is rapid exposure validation, patching, reboot verification, and service-scope review, especially where NFS is reachable across broad internal or external networks.

That is the useful level of precision. It avoids theatrical claims, but it also avoids the dangerous instinct to hide behind the most conservative phrase in the advisory while public exploit engineering accelerates around you.

CVE-2026-4747 final assessment

CVE-2026-4747 deserves attention because the core facts are already strong enough without exaggeration. It is a real FreeBSD RPCSEC_GSS memory corruption issue with remote code execution implications. It affects all supported FreeBSD versions at disclosure time. The official advisory says there is no workaround, gives explicit fixed releases, and narrows one practical exception by stating that kernels without kgssapi.ko loaded are not vulnerable. That is already enough to justify urgent handling for exposed systems.

It deserves even more attention because it shows how security teams now have to read public source material. Vendor wording, vulnerability database wording, AI lab wording, and public exploit write-ups may all land within days of each other, and they may not describe the exact same point on the attack chain. CVE-2026-4747 is not just a bug to patch. It is a reminder that modern defense depends on being able to hold several truths at once: patch fast, validate locally, read carefully, and do not confuse the loudest public claim with the only fact that matters.

Further reading and references

FreeBSD Security Advisory, FreeBSD-SA-26:08.rpcsec_gss — the primary vendor advisory for CVE-2026-4747, including affected branches, fixed releases, and official remediation guidance.

NVD Entry, CVE-2026-4747 — the public vulnerability record, useful for tracking the canonical description, references, and scoring updates.

Anthropic Red Team, Assessing Claude Mythos Preview’s Cybersecurity Capabilities — Anthropic’s public write-up that discusses Mythos Preview and includes its account of the FreeBSD RPCSEC_GSS case.

Calif, MAD Bugs — Claude Wrote a Full FreeBSD Remote Kernel Exploit for CVE-2026-4747 — a public research post discussing exploit development around the vulnerability.

Calif GitHub Write-up, CVE-2026-4747 — the detailed public technical write-up covering the vulnerable path, assumptions, and lab exploit conditions.

Penligent, Claude Mythos Preview and the New Zero-Day Era — a related Penligent article that discusses the broader security implications of the Mythos disclosure wave.

Penligent, Anthropic Mythos, Strong Claims and Thin Binary Proof — a more skeptical Penligent take on the public evidence and how to interpret the stronger claims around Mythos.

Penligent Hacking Labs — Penligent’s security research hub page, which currently indexes the Mythos-related pieces and adjacent analysis.

Penligent Homepage — the main product site if you want one general product reference at the end of the article.