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

In sshd in OpenSSH before 10.5, the restrict keyword (in authorizedkeys) was supposed to be applicable to tunnel forwarding but was not.

In ssh in OpenSSH before 10.5, a use-after-free for realloc data can occur if a certain pair of remote-forwarding operations are concurrent.

In ssh-agent in OpenSSH before 10.5, some operations can occur remotely but were intended to occur only locally, including operations that add tokens or use keys. This is caused by misinteraction between agent locking and the session-bind@openssh.com extension.

An integer underflow was found in the popt library when formatting help text for option tables that exceed the terminal width. A local user who can cause an application to print help under those conditions may cause that application to crash or fail to display help, resulting in a denial of service of the affected application.

Last updated 13 July 2026

Last updated 13 July 2026

Last updated 13 July 2026

In sshd in OpenSSH before 10.4, DisableForwarding=yes was supposed to take precedence over PermitTunnel=yes, but did not.

Last updated 13 July 2026

internal-sftp in sshd in OpenSSH before 10.4 recognizes only the first 9 command-line arguments, which can be important if a later command-line argument would have helped to ensure the intended security properties of an SFTP connection.

Last updated 13 July 2026

Last updated 13 July 2026

sys/kern/sysvsem.c in OpenBSD through 7.9 has a use-after-free allowing local privilege escalation to root. This is a context switch use-after-free after tsleep in syssemget().

A crafted MPLS packet can trigger an out-of-bounds read in mpls\do\error, leaking 4 bytes of adjacent kernel stack memory back in an ICMP/MPLS error response.

It requires MPLS enabled, but the leak is remote and repeatable. Fixed in OpenBSD-current on 2026-06-18.

------------------------------------------------------------------------ ------------------------------------------------------------------------

Affected:  OpenBSD -current prior to 2026-06-18 (fixed in -current) Vendor:    OpenBSD Severity:  Medium Reporter:  Argus Systems Date:      2026-06-12 CVE:       CVE-2026-56099

1. SUMMARY ==========

The mplsdoerror() function in sys/netmpls/mplsinput.c parses an incoming MPLS label stack into a fixed-size local array, struct shimhdr stack[MPLSINKERNELLOOPMAX] (16 entries). When the parse loop completes without encountering the Bottom-of-Stack (BoS) label, nstk reaches MPLSINKERNELLOOPMAX (16). Several subsequent code paths then compute a copy length of (nstk + 1) sizeof(shim) -- 17 entries -- and use it with icmpdoexthdr(), MPREPEND(), and mcopyback() against the 16-entry stack object. This reads one struct shimhdr (4 bytes) past the end of the array, and that data is reflected back to the sender inside the generated ICMP/MPLS error response.

2. AFFECTED VERSIONS ====================

The (nstk + 1) length computations against the 16-entry stack[] array were introduced with the ICMP/MPLS error path on 2010-09-13 (commit 201d6983add, "First shot at ICMP error handling inside an MPLS path. Currently only TTL exceeded errors for IPv4 are handled."). The parse loop was bounded by MPLSINKERNELLOOPMAX (16), but nothing rejected a stack that ran to completion without a BoS bit, so nstk could reach 16 and the subsequent (nstk + 1) reads accessed stack[16].

Affected: OpenBSD -current prior to 2026-06-18 (mplsinput.c pre v1.82).

3. DETAILS ==========

Vulnerable code (sys/netmpls/mplsinput.c, mplsdoerror):

struct shimhdr stack[MPLSINKERNELLOOPMAX];   / 16 entries /   ...   for (nstk = 0; nstk < MPLSINKERNELLOOPMAX; nstk++) {       ...       stack[nstk] = mtod(m, struct shimhdr );       madj(m, sizeof(shim));       if (MPLSBOSISSET(stack[nstk].shimlabel))           break;   }   / no guard: with no BoS bit set, nstk == 16 here /

shim = &stack[0];   ...   case IPVERSION:       ...       if (icmpdoexthdr(m, ICMPEXTMPLS, 1, stack,           (nstk + 1) sizeof(shim)))           return (NULL);       ...

MPLSINKERNELLOOPMAX is defined as 16 and sizeof(struct shimhdr) is 4. With nstk == 16, each of these copies 17 4 = 68 bytes from a 64-byte stack[] object, reading stack[16] -- one struct shimhdr (4 bytes) of adjacent kernel stack -- and including it in the response.

The same (nstk + 1) length is later used to prepend and mcopyback() the stack back onto the reflected packet:

MPREPEND(m, (nstk + 1) sizeof(shim), MNOWAIT);   ...   mcopyback(m, 0, (nstk + 1) sizeof(shim), stack, MNOWAIT);

so the leaked entry also travels on the wire as the 17th MPLS shim header of the returned frame.

4. REACHABILITY ===============

The path is reachable remotely via mplsinput() -> mplsdoerror() on systems that have MPLS enabled on an interface. The trigger is a crafted MPLS frame (EtherType 0x8847) carrying 16 labels with no BoS bit set and an outermost label TTL of 1, so the TTL-exceeded error path is taken:

mplsinput  (ttl <= 1)     -> mplsdoerror(m, ICMPTIMXCEED, ICMPTIMXCEEDINTRANS, 0)

The inner payload must be IPv4 so the IPVERSION branch is reached.

5. IMPACT =========

Each crafted packet leaks 4 bytes of kernel stack memory adjacent to the stack[] array. The leak is carried in the ICMP/MPLS extension object of the error response reflected back to the sender, so an attacker can harvest the leaked bytes.

6. PROOF OF CONCEPT ===================

A Python/Scapy PoC sends a 16-label MPLS frame with no BoS bit set and an outermost label TTL of 1, then captures the reply. On a vulnerable kernel the reply carries 17 MPLS shim headers on the wire; the 17th (stack[16]) is the leaked kernel stack data.

PoC: https://pop.argus-systems.ai/attachments/poc-008-mpls-stack-leak.py

7. FIX ======

Fixed in -current by mvs on 2026-06-18. The fix adds a guard that drops a label stack which runs to completion without a BoS bit, so nstk can no longer reach MPLSINKERNELLOOPMAX:

if (nstk >= MPLSINKERNELLOOPMAX) {       mfreem(m);       return (NULL);   }

Fix commit (mplsinput.c v1.82): https://github.com/openbsd/src/commit/6a23123ec05f1eb29cfcaae0f3a468b2e1983cfd

8. TIMELINE ===========

2026-06-12  Reported to security () openbsd org with PoC   2026-06-18  Fix committed to -current

9. CREDIT =========

Discovered and reported by Argus Systems (https://byteray.co.uk/).

10. REFERENCES ==============

Advisory:   https://pop.argus-systems.ai/advisory/adv-040.html

Proof of concept: https://pop.argus-systems.ai/attachments/poc-008-mpls-stack-leak.py

Fix commit: https://github.com/openbsd/src/commit/6a23123ec05f1eb29cfcaae0f3a468b2e1983cfd

OpenBSD before commit 6a23123 (2026-06-18) contains an out-of-bounds read vulnerability in the mplsdoerror function within sys/netmpls/mplsinput.c that allows remote attackers to disclose kernel stack memory by sending crafted MPLS frames with 16 labels and no Bottom-of-Stack bit set.

sppppapinput in sys/net/ifspppsubr.c in OpenBSD before 076e2b1 allows authentication bypass via certain zero values for lengths.

------------------------------------------------------------------------ OpenBSD sppppapinput: PAP Authentication Bypass via Zero-Length bcmp ------------------------------------------------------------------------

Affected:  OpenBSD all versions through 7.6 (fixed in -current) Vendor:    OpenBSD Severity:  High Reporter:  Argus Date:      2026-06-16

1. SUMMARY ==========

The sppppapinput() function in sys/net/ifspppsubr.c uses the attacker-controlled namelen and passwdlen fields from the incoming PAP frame directly as the comparison length for bcmp() against configured credentials.

When both fields are set to zero, bcmp() returns 0 unconditionally (bcmp with length 0 always succeeds). The existing upper-bound guard (> AUTHMAXLEN) allows zero through. As a result, a PAP Auth-Request with namelen=0 and passwdlen=0 passes credential validation and triggers a PAPACK, authenticating the peer without any knowledge of the configured username or password.

A secondary kernel heap over-read exists via the same root cause: supplying a namelen larger than the allocation of the stored credential causes bcmp to read past the heap object.

2. AFFECTED VERSIONS ====================

The bcmp comparison pattern was introduced with the original sppp code import on 1999-07-01 (commit bda3414e, "lmc driver; ported by chris () dqc org"). The zero-length bypass has been exploitable since that date.

In February 2009 (commit 9c2f3d605fc), auth credential fields were changed from fixed-size struct arrays to dynamically allocated malloc(strlen()+1), and the bounds check was changed to AUTHMAXLEN (256). This decoupled the allocation size from the comparison bound, enabling the heap over-read.

Confirmed against OpenBSD 7.6 (amd64) in QEMU/KVM.

3. DETAILS ==========

Vulnerable code (sys/net/ifspppsubr.c, sppppapinput):

if (namelen > AUTHMAXLEN ||       passwdlen > AUTHMAXLEN ||       bcmp(name, sp->hisauth.name, namelen) != 0 ||       bcmp(passwd, sp->hisauth.secret, passwdlen) != 0) {           / authentication failed /

namelen and passwdlen are parsed directly from the PAP frame payload. bcmp(a, b, 0) always returns 0. The > AUTHMAXLEN guard rejects values above 255 but permits zero.

The CHAP handler in the same file already had the correct pattern with an exact-length pre-check:

if (namelen != strlen(sp->hisauth.name)       || bcmp(name, sp->hisauth.name, namelen) != 0) {

The PAP handler never received the same treatment.

4. REACHABILITY ===============

Both bugs are reachable via the PPPoE data path:

pppoedatainput -> pppoeintr -> spppinput -> sppppapinput

Precondition: the target system must be configured as a PAP authenticator (e.g. ifconfig pppoe0 peerproto pap peername <x> peerkey <y>). The attacker does not need to know any credentials.

5. IMPACT =========

An attacker on the same network segment can authenticate to a PPPoE interface without credentials, establishing a full network-layer link (LCP -> PAP -> IPCP -> IP).

When OpenBSD acts as a PPPoE client with mutual authentication, a rogue server in the same broadcast domain can exploit the bypass to impersonate a legitimate server, causing OpenBSD to route traffic through the attacker's endpoint.

6. PROOF OF CONCEPT ===================

A Python PoC acts as a PPPoE server, completes discovery and LCP negotiation, then sends a PAP Auth-Request with namelen=0 and passwdlen=0.

Result:

PAPACK received with empty credentials   VM accepted namelen=0, passwdlen=0 as valid auth.

IPCP Config-Ack received - link is UP   ICMP echo reply from 10.0.0.1

FULL LINK ESTABLISHED

PoC and full technical report:   https://blog.argus-systems.ai/blog/openbsd-pap-27-year-auth-bypass.html

7. FIX ======

Fixed in -current by mvs on 2026-06-14. The fix mirrors the CHAP handler's exact-length pre-check:

if (namelen != strlen(sp->hisauth.name) ||       passwdlen != strlen(sp->hisauth.secret) ||       bcmp(name, sp->hisauth.name, namelen) != 0 ||       bcmp(passwd, sp->hisauth.secret, passwdlen) != 0) {

Fix commit: https://github.com/openbsd/src/commit/076e2b1c1fc4ac0883a72d3544131ad5cee7adf8

8. TIMELINE ===========

2026-06-12  Reported to security () openbsd org with PoC   2026-06-14  Fix committed to -current

9. CREDIT =========

Discovered and reported by Argus (https://byteray.co.uk/).

10. REFERENCES ==============

Advisory:   https://pop.argus-systems.ai/advisory/adv-038.html

Blog post: https://blog.argus-systems.ai/blog/openbsd-pap-27-year-auth-bypass.html

Proof of concept:   https://pop.argus-systems.ai/attachments/poc-001-pap-bypass.py

Incorrect packet validation allowed unbounded recursion parsing SCTP chunk parameters. This can eventually result in a stack overflow and panic.

Remote attackers can craft packets which cause affected systems to panic. This affects any system where pf is configured to process traffic, independent of the configured ruleset.

A flaw was found in OpenSSH. This vulnerability, a heap out-of-bounds read, occurs during the cleanup of GSSAPI (Generic Security Service Application Programming Interface) indicators when a trailing NULL termination is missing in the auth-indicators array. A remote attacker, under specific configurations involving GSSAPI authentication and a Kerberos environment, could exploit this to cause the SSH authentication path to crash or abort. This leads to a denial of service (DoS), impacting the availability of the SSH service.

A flaw was found in OpenSSH. A malicious SSH server can exploit a double free vulnerability in the Diffie-Hellman Group Exchange (DH-GEX) client path. This occurs during FIPS (Federal Information Processing Standards) mode known-group validation when the client processes attacker-controlled DH-GEX group parameters. Successful exploitation leads to client-side process termination, resulting in a Denial of Service (DoS).

A flaw was found in OpenSSH. A local unprivileged attacker on a Linux client host can hijack client-side X11 forwarding connections. This is possible by pre-binding the preferred abstract X socket name when X11 forwarding is enabled and a local UNIX-domain X socket is used. A successful attack can compromise the confidentiality of forwarded X11 traffic, including sensitive window contents and input, and may allow some manipulation of the forwarded session.

In OpenBSD through 7.8, the slaacd and rad daemons have an infinite loop when they receive a crafted ICMPv6 Neighbor Discovery (ND) option (over a local network) with length zero, because of an "ndoptlen 8 - 2" expression with no preceding check for whether ndoptlen is zero.

Last updated 10 July 2026

OpenSSH before 10.3 omits connection multiplexing confirmation for proxy-mode multiplexing sessions.

OpenSSH before 10.3 can use unintended ECDSA algorithms. Listing of any ECDSA algorithm in PubkeyAcceptedAlgorithms or HostbasedAcceptedAlgorithms is misinterpreted to mean all ECDSA algorithms.

In OpenSSH before 10.3, command execution can occur via shell metacharacters in a username within a command line. This requires a scenario where the username on the command line is untrusted, and also requires a non-default configurations of % in sshconfig.

In OpenSSH before 10.3, a file downloaded by scp may be installed setuid or setgid, an outcome contrary to some users' expectations, if the download is performed as root with -O (legacy scp protocol) and without -p (preserve mode).