When a process calls execve(2) to execute a setuid or setgid image, hwpmc(4) is supposed to detach PMCs owned by unprivileged processes. An inverted check meant that this scenario was not handled properly.

An unprivileged local user who has attached PMCs to a process can continue monitoring it after the process executes a setuid or setgid binary, contrary to the intended policy.

The SOCKSTREAM receive path in the unix socket implementation failed to fully detach control messages from the socket buffer before processing them. Some error paths would free those messages, leaving freed data mbufs in the receive socket buffer.

An unprivileged local user can exploit this use-after-free to escalate privileges.

The implementation of this ioctl attempts to acquire locks on all channels in a sync group. If locking a channel would block, it releases the sync group list lock and sleeps. Upon reawakening, it is possible that the sync group structure is freed, but the implementation did not handle this possibility.

On a system with a multiple audio devices, an unprivileged local user can exploit this use-after-free to escalate privileges.

In FreeBSD 15.0, the kernel structure used to represent user credentials changed: previously the primary group ID was stored in the first element of the array containing the list of supplementary group IDs, whereas now the primary group ID is stored in a dedicated field. This change was largely internal to the kernel and not user-visible.

One function, groupisprimary(), was not properly updated as a part of this transition. This function is used by macdo to determine the primary group ID of the credential after applying a transition rule, used when the rule target does not explicitly specify a group.

As a result, with certain macdo rules, it is possible for a credential switch to incorrectly set the primary group ID to the ID stored in the first element of the original credential's supplementary group array.

If the list of supplementary groups is empty, this value will be 0, corresponding to the "wheel" group. For example, a rule such as "uid=1001>uid=1002" can be abused to set the primary group ID to 0 even if the process did not originally belong to group 0.

Certain macdo rules can be abused to set a process' group ID to 0. Note however, that the rule must apply to the caller in order for the bug to be triggered, e.g., given the ruleset "uid=1001>uid=1002", the user must have user ID 1001 in order to trigger the bug.

Further, logged-in users will in general have a non-empty supplementary group list, in which case the bug can at worst be used to set the credential's first supplementary group ID as its primary group ID. Processes must explicitly remove themselves from all supplementary groups, using the privileged setgroups(2) system call, in order to exploit the bug to set 0 as the primary group ID.

Since membership in group 0 is often used to enable controlled privilege escalation, the bug might be further exploitable to obtain root privileges, depending on the system configuration. For instance, a ruleset such as the following could be exploited by a process running as user 1001 and with an empty supplementary group list: "uid=1001>uid=1002;gid=0>uid=0".

The TIOCSCTTY ioctl handler drops the tty lock in order to acquire the process tree lock. After reacquiring the tty lock, the handler did not revalidate the state of the terminal, and could proceed to link a terminal that was concurrently being destroyed to the calling process' session.

An unprivileged local user can exploit this race condition to escalate privileges.

The FIOSSHMLPGCNF ioctl(2) operation configures the page size for a largepage shared memory object. This is intended to be used immediately after creating the object, before any memory is allocated for the object. The handler checked whether a page size had already been configured without holding the rangelock. Two concurrent callers could both observe an unconfigured object and set conflicting page sizes, leaving the object in an inconsistent state.

An unprivileged local user can exploit this race to escalate privileges.

The setlocale function in FreeBSD 5.0 and earlier, and possibly other OSes, allows local users to read arbitrary files via the LANG environmental variable.

opiepasswd in One-Time Passwords in Everything (OPIE) in FreeBSD 4.10-RELEASE-p22 through 6.1-STABLE before 20060322 uses the getlogin function to determine the invoking user account, which might allow local users to configure OPIE access to the root account and possibly gain root privileges if a root shell is permitted by the configuration of the wheel group or sshd.

Format string vulnerability in pwerror function in BSD libutil library allows local users to gain root privileges via a malformed password in commands such as chpass or passwd.

Format string vulnerability in top program allows local attackers to gain root privileges via the "kill" or "renice" function.

fingerd in FreeBSD 4.1.1 allows remote attackers to read arbitrary files by specifying the target file name instead of a regular user name.

FreeBSD 4.1.1 and earlier, and possibly other BSD-based OSes, uses an insufficient random number generator to generate initial TCP sequence numbers (ISN), which allows remote attackers to spoof TCP connections.

Buffer overflow in ncurses library allows local users to execute arbitrary commands via long environmental information such as TERM or TERMINFODIRS.

mpEnddisc() used incorrect length calculations when formatting endpoint discriminator addresses for display, allowing a received endpoint option to overflow a global result buffer.

A malicious PPP peer can crash ppp(8) or potentially execute arbitrary code as root.

LcpDecodeConfig() did not validate the length of received endpoint discriminator options against the minimum required by RFC 1717. Undersized options would trigger an out-of-bounds write.

A malicious PPP peer can exploit CVE-2026-58095 and CVE-2026-58096 to crash ppp(8) or potentially execute arbitrary code as root.

mpSetEnddisc() copied a user-supplied PSN endpoint value without length validation, allowing a buffer overflow via the ppp(8) command interface.

A local user with access to the ppp(8) command interface can crash ppp(8) or potentially execute arbitrary code as root.

End of life: 6/30/2027

Summary

Terrapin is a prefix truncation attack targeting the SSH protocol. More precisely, Terrapin breaks the integrity of SSH's secure channel. By carefully adjusting the sequence numbers during the handshake, an attacker can remove an arbitrary amount of messages sent by the client or server at the beginning of the secure channel without the client or server noticing it.

Mitigations

To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes.

Warning: To take effect, both the client and server must support this countermeasure.

As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available.

Details

The SSH specifications of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com MACs) are vulnerable against an arbitrary prefix truncation attack (a.k.a. Terrapin attack). This allows for an extension negotiation downgrade by stripping the SSHMSGEXTINFO sent after the first message after SSHMSGNEWKEYS, downgrading security, and disabling attack countermeasures in some versions of OpenSSH. When targeting Encrypt-then-MAC, this attack requires the use of a CBC cipher to be practically exploitable due to the internal workings of the cipher mode. Additionally, this novel attack technique can be used to exploit previously unexploitable implementation flaws in a Man-in-the-Middle scenario.

The attack works by an attacker injecting an arbitrary number of SSHMSGIGNORE messages during the initial key exchange and consequently removing the same number of messages just after the initial key exchange has concluded. This is possible due to missing authentication of the excess SSHMSGIGNORE messages and the fact that the implicit sequence numbers used within the SSH protocol are only checked after the initial key exchange.

In the case of ChaCha20-Poly1305, the attack is guaranteed to work on every connection as this cipher does not maintain an internal state other than the message's sequence number. In the case of Encrypt-Then-MAC, practical exploitation requires the use of a CBC cipher; while theoretical integrity is broken for all ciphers when using this mode, message processing will fail at the application layer for CTR and stream ciphers.

For more details see https://terrapin-attack.com.

Impact

This attack targets the specification of ChaCha20-Poly1305 (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com), which are widely adopted by well-known SSH implementations and can be considered de-facto standard. These algorithms can be practically exploited; however, in the case of Encrypt-Then-MAC, we additionally require the use of a CBC cipher. As a consequence, this attack works against all well-behaving SSH implementations supporting either of those algorithms and can be used to downgrade (but not fully strip) connection security in case SSH extension negotiation (RFC8308) is supported. The attack may also enable attackers to exploit certain implementation flaws in a man-in-the-middle (MitM) scenario.

The AI industry is running a contradiction it hasn’t resolved.

Frontier labs are warning about an imminent software security collapse. Anthropic reported that Claude Mythos found zero-days in codebases hardened by decades of review: a 27-year-old denial-of-service bug in OpenBSD’s TCP SACK implementation, and a 17-year-old remote code execution flaw in FreeBSD’s NFS server that hands an unauthenticated user root (CVE-2026-4747). Mozilla, testing Mythos Preview against Firefox 150, surfaced 271 vulnerabilities, more than ten times what it found in Firefox 148 using Claude Opus 4.6. OpenAI is sounding the exact same alarm, touting GPT-6 Astra saturating ExploitBench while warning that autonomous attack capabilities are scaling faster than human defenders can patch.

To be fair, Anthropic acted on part of this. Project Glasswing puts $100M in credits behind partnerships with Microsoft, Apple, CrowdStrike, and the Linux Foundation.

Glasswing makes sense for foundational open-source packages and mega-cap infrastructure. It does nothing for the other 99% of software developers. The startups, the internal tool builders, and the mid-market engineering teams writing the proprietary software that runs the rest of the world don’t have an organizational sponsor. Yet they are expected to hold off machine-speed exploits without access to the intelligence that found them.

What they get instead are models like Claude Fable or public endpoints of Astra, sitting behind hair-trigger safety classifiers and preemptive capability caps.

Labs are terrified of prompt injection and “I’m an authorized pen tester” jailbreaks, so the filters cast an absurdly wide net. Paste in complex code and ask the model to trace an execution path, analyze memory corruption, or check whether untrusted input can reach a sensitive sink, and the classifier fires immediately.

Security researchers have already documented Claude Code blocking vulnerability work outright, throwing errors about “violative cyber content” that contaminate the entire session and spread to benign follow-up questions. Worse, when the classifier flags an inquiry as security-related, it quietly routes the work to Opus. Opus handles the analysis, and you get degraded work compared to what Fable would have delivered.

Anthropic built Mythos as a model tier above Opus and published what that difference looks like in practice: ten times the findings on comparable Firefox releases.

So when Opus finishes auditing your code and reports nothing exploitable, what have you actually learned? Only that there are no bugs an Opus-class model can find. Anthropic’s own numbers prove that is a fraction of what is actually there. You haven’t verified your code is secure; you’ve verified it survived a search one tier below the frontier, and you were never told the search happened at that tier.

That ceiling won’t hold. Every audit that passes at the Opus level is a bet that nothing Mythos or Astra-class will ever be pointed at your attack surface. But frontier engines already exist, and ablated open-weight models in agentic loops are rapidly converging on the exact same workflows, without a classifier deciding which tier is appropriate for them. On a long enough timeline, that bet is guaranteed to lose.

The gatekeeping rests on a misunderstanding of how software security actually works.

Defense is downstream of offense. You cannot verify a fix you cannot attack. A scanner that lists 300 theoretical warnings without the ability to chain an exploit path is useless. It just breeds alert fatigue. Real remediation means proving the vector is reachable, building the proof of concept, shipping the patch, and running the exploit again to confirm the vector is dead.

Neuter the model’s offensive reasoning, and you neuter the audit.

Meanwhile, nobody attacking your systems is applying to Project Glasswing or arguing with commercial API guardrails.

They run local open-weight models: ablated, fine-tuned on exploit repositories, with the guardrails stripped out. Open weights still trail closed frontier models on raw benchmarks, but benchmark scores don’t decide an engagement. An attacker doesn’t need one omniscient model. They just need uncensored weights in an agentic loop with a fuzzing harness behind it, and no safety classifier killing the context window on attempt four hundred.

That leaves three distinct tiers:

Incumbents, who get vetted private access to the frontier tier through closed programs like Glasswing. The 99% of developers, who get models like Fable or Astra that trip alarms, refuse prompts, or quietly hand security work down to lower tiers without telling anyone. Attackers, who get unconstrained offensive intelligence pointed straight at the attack surface, running at machine speed.

Telling developers a cyber tsunami is coming while confiscating their lifeboats is not responsible stewardship. It is security theater. If the labs believe machine-speed cyber warfare is already here, throttling the people trying to inspect their own code is a strange way to act on that belief. Give everyday builders the same offensive firepower and let them tear their own systems apart before someone else does.

Originally posted at: https://eddiemissri.substack.com/p/the-asymmetric-disarmament-of-ai

When msync(MSINVALIDATE) is called on a mapping of an unmanaged device object, the physical pages in the mapping range are marked invalid but remain in the pager's page list. A subsequent page fault will cause the fault handler to re-insert the page into the object's list. This corrupts the list, and on object destruction the page is freed twice.

An unprivileged local user with access to a device that provides memory-mapped I/O can trigger a use-after-free in the kernel, though this is limited to a pool of objects ("fictitious pages") that are never recycled for a different purpose. It may be possible to exploit this to escalate privileges.

When the JAILATDESC flag is specified, kernjailset() and kernjailget() released the reference to the caller's current prison before looking up the jail descriptor. If the descriptor lookup failed, error-handling paths released the same reference a second time.

An unprivileged local user can trigger a prison reference count underflow, which may cause the prison structure to be freed while still in use. When this is done on the jail host, the bug will generally result in an immediate panic. However, if the user is running in a jail, then it may be possible to exploit the bug to elevate privileges.

The RTSP handler in libalias rewrote outgoing packets into a fixed-length stack buffer without checking whether the rewritten data fit in the buffer, or whether the result fit back in the original packet.

A host sending crafted RTSP traffic from inside a NAT gateway using libalias can overflow a stack buffer, potentially achieving remote code execution in the kernel (when using ipfw(4) NAT) or in the natd(8) process (which generally runs as the root user).

The kernel function that implements unlinkat(2) and funlinkat(2) validated the ATRESOLVEBENEATH flag but failed to pass it through to the underlying path lookup. The flag was silently dropped, so path resolution was not actually restricted.

A process that uses ATRESOLVEBENEATH with unlinkat(2) or funlinkat(2) to confine path resolution can in fact resolve paths above the starting directory. A caller relying on this flag for path containment may delete files outside the intended directory tree.

The RACK setsockopt(2) handler drops the connection lock in order to copy option data from userspace, then reacquires the lock. After reacquiring, it verifies that the TCP stack had not been switched away, but did not reload its pointer to the stack's per-connection control block. If userspace switches stacks twice during this window, the check will succeed but the saved pointer will refer to freed memory.

The bug may be exploitable by an unprivileged local user to escalate privileges.

When auditing a system call executed via ptrace(PTSCREMOTE), the kernel passed the return value of an internal setup function to AUDITSYSCALLEXIT() rather than the actual result of the executed system call. As a result, committed audit records for system calls which returned an error do not reflect the true outcome of the operation. That is, they indicate that the operation succeeded when it in fact failed.

Audit records for system calls executed via ptrace(PTSCREMOTE) may show an incorrect error status. An attacker with the ability to debug a process could use this to produce misleading audit trails, potentially undermining audit-based Intrusion Detection Systems (IDS).

Pages belonging to largepage shared memory objects were not explicitly wired. When sendfile(2) transmitted such an object with the SFNOCACHE flag, it freed the underlying pages after transmission even though existing mappings still referred to them.

An unprivileged local user can abuse the bug to access freed kernel memory. This can be exploited to escalate privileges.

Certain system calls, such open(2) with the OTRUNC flag set, and fspacectl(2), could incorrectly free memory in largepage objects. These operations are not permitted on largepage objects, but the implementation did not verify this.

An unprivileged local user can abuse the bug to access freed kernel memory. This can be exploited to escalate privileges.

The ZFSIOCUSERSPACEMANY ioctl, used by zfs-userspace(8), truncated a 64-bit output buffer size to a 32-bit integer for the kernel allocation, but used the original 64-bit size as the buffer limit when writing records.

A local user with the "userused" delegated ZFS permission can trigger a kernel heap overflow via the ZFSIOCUSERSPACEMANY ioctl, potentially escalating privileges.

The ZFSIOCRECVNEW ioctl, in the heal receive path, similarly truncated a 64-bit payload size to a 32-bit integer for allocation, then used the original 64-bit size as the length for a byteswap operation.

A local user with the "receive" delegated ZFS permission can trigger kernel memory corruption via ZFSIOCRECVNEW by sending a crafted receive stream in heal mode.

The ZFSIOCSETPROP ioctl, used by zfs-set(8), incorrectly validated the calling user such that an unprivileged user is able to set metadata on a dataset indicating that the dataset has received properties from a zfs-recv(8) stream.

Any local user can set the internal ZFS metadata flag "$hasrecvd" on datasets via ZFSIOCSETPROP.