Three checks read a value that no longer meant what it said

Three components failed the same way over three weeks, and none is a memory safety bug in the ordinary sense. Each made a security decision by comparing a value that had stopped describing the object it stood for. A socket buffer carried a flag saying its pages were shared, and the flag disappeared when the buffer absorbed another one. A libc function returned an error string that already meant “no password” in the shadow entry it was compared against. A Barracuda appliance offered its configuration import to a request that never held a session.

That shape explains why none of the three produces a crash that a defender would notice. Two are failures to propagate state and one is a route that should not have been reachable. Each decision looks correct at the moment it is made. The kernel, runtime and edge fixes below are ordered by reach rather than score. The kernel flaw has already carried a firewall from a web request to root. The sshd flaw is being exercised at internet scale by automated traffic. The appliance flaw needs a reachable management interface and nothing else.

The socket buffer drops the marker that says its pages are shared

What happened: skb_try_coalesce() merges the paged fragments of one socket buffer into another, so that a run of small TCP segments becomes a single buffer. When the source buffer carries SKBFL_SHARED_FRAG, the pages it points at belong to someone else. In the sequence the kernel CNA describes, that owner is the page cache. The merge moves the fragment descriptors and leaves the marker behind, so the destination buffer holds shared pages while claiming private ones.

The missing marker is read at one call site. ESP input tests skb_has_shared_frag() to decide whether an uncloned nonlinear buffer may skip skb_cow_data(). That copy is what separates the kernel’s view of the pages from the cache. After TCP receive coalescing has moved shared fragments into an unmarked buffer, the test returns false. The ESP path then decrypts in place over page-cache-backed fragments. The write lands in the cached copy of a file the attacker chose, which is the primitive the Dirty COW family used to reach the kernel.

The fix propagates the marker whenever skb_try_coalesce() transfers paged fragments. The tailroom copy path needs no marker because it copies bytes into linear data and moves no descriptors. Eight trees received the change: 5.10.257, 5.15.208, 6.1.174, 6.6.141, 6.12.91, 6.18.33 and 7.0.10, with 7.1 carrying the original commit. The CVE record lists every kernel from 3.9 onward as affected. Thirteen years of releases fall inside that range.

What it reaches: The path is IPsec over TCP, so exposure is limited to hosts that terminate ESP inside a TCP stream. Hosts using ESP over UDP for NAT traversal do not reach the coalescing code. Firewalls and remote access concentrators are where the TCP form is configured. They are also where a page-cache write becomes a write into the code that sets filtering policy. The public proof of concept is local, against kernels built before 2026-05-13. Dream Research documented the flaw as the second stage of an attack that began with a PHP2Shell request. The team counted 25 rooted servers, described as PAN-OS firewalls and management servers, across the United States, Japan, Taiwan and South Korea. Three sat in a US government-affiliated environment, alongside roughly 40 post-exploitation scripts and follow-on attacks against Active Directory. Unit 42 verified the tooling, and Palo Alto Networks shipped fixed PAN-OS builds.

What to check:

• The kernel version against the fixed release for its own branch, since the CVE record lists eight separate fix commits.
• Whether the host terminates IPsec over TCP, which is the configuration that reaches the coalescing path.
• Package and binary integrity with rpm -Va, debsums or apk audit, because the primitive writes into a file that a package database already has a hash for.
• Whether anything above the kernel runs unauthenticated code, since the observed chain began with a web request.

What would change the assessment: A demonstration that ESP over TCP needs an explicit non-default setting on the affected branches would cut exposure to deliberate deployments. Every public writeup assumes the option is reachable, and the campaign evidence comes from appliances rather than general purpose hosts.

musl’s error string equals the marker for an account with no password

What happened: When sshd is built without PAM it verifies a password by hashing the attempt with crypt() and comparing the result to the string in the shadow entry. An account with no password stores * there, which is the normal state for root on Alpine and for key-only accounts created with adduser. The salt comes from another account’s $5$ or $6$ entry, because the target has none of its own. For a key longer than 256 bytes, musl’s crypt() fails and returns the string * rather than a null pointer. The comparison then finds * equal to *, and sshd logs the session in. The CVE record states that any password between 256 and 1,024 characters succeeds, while Alpine’s advisory gives the working range as 257 to 1,024 bytes.

The ambiguity sits in a return value rather than in the authentication logic. glibc returns a null pointer for the same oversized input, and sshd already rejected that. Özgün Kültekin of Wakefield reported it, and the release notes credit him. OpenSSH classes the root cause as outside sshd while accepting that the bug is exploitable through it. The 10.6p2 fix rejects any stored hash shorter than four characters.

What it reaches: The condition set is narrow and the population that meets it is large. sshd must run on musl without PAM, password authentication must be enabled, one account must carry * in shadow, and one other account must hold a $5$ or $6$ hash. Alpine’s advisory covers every release it checked from 3.16 through edge. It names root, key-only users, the alpine user in the tiny-cloud images, and accounts arriving through musl-nscd. OpenWrt, Buildroot and Yocto images built the same way inherit the behavior, as does any container running sshd. WatchTowr and Previdian reported exploitation over the weekend of 7 November, with botnets and crypto miners in the first wave. The catalog entry followed on 9 November, with a deadline of 12 November.

What to check:

• Whether the running sshd links musl without PAM, or is openssh-server-pam with UsePAM no, since the glibc path is not affected.
• Whether PasswordAuthentication is yes, which is the compiled default.
• Whether any login-capable account has exactly * in /etc/shadow, noting that ! accounts are locked and therefore safe.
• Whether at least one account holds a $5$ or $6$ hash, because that salt is what sshd borrows.
• Whether sshd was restarted after the package upgrade, since Alpine states that upgrading alone does not replace the running daemon.
• Whether logs contain Accepted password lines for an account that has no password.

What would change the assessment: A survey showing that public cloud images and managed platforms ship PasswordAuthentication no by default would narrow this to self-built images and appliances. Cloud-init writes that setting on most mainstream images, which concentrates the exposure in container fleets and network gear rather than the general server population.

An appliance restores a backup for a request that never authenticated

What happened: CVE-2026-116606 is an authorization bypass that uses an alternate path or channel, scored 9.3 under CVSS 4.0 by Mandiant as the CNA. The bypass reaches a configuration import function without a session. The import then restores a crafted but format-compatible backup archive, which rewrites the appliance’s global configuration. Barracuda first listed administrative access as a requirement and changed that field on 5 November. The current text reads “No (Administrative UI Access Required)”, with a note that the administrative interface must still be reachable.

The paired flaw, CVE-2026-111560, is a command injection in the timezone field of code shared across six product lines. It runs with root privileges when the crafted value is processed, and it needs an authenticated administrator, which the first flaw supplies. Both were published on 2 November, from Barracuda disclosures dated 15 and 22 October and Mandiant advisories MNDT-2026-0041 and 0042. An unauthenticated request rewrites configuration, and the rewritten configuration carries a timezone string the appliance executes as root. Barracuda updated its advisory on 9 November to report exploitation against a small number of organizations, and the catalog followed on 10 November with a deadline of 13 November.

EPSS puts the pair at 0.016 and 0.011, in the 76th and 65th percentiles, which scores the likelihood of an attempt rather than what follows from one.

What it reaches: Email security gateways sit in front of every inbound message and often hold directory credentials. Root on the appliance converts into a position on the mail path and a foothold beside identity. The precondition is exposure of the administrative interface, and Barracuda makes that the dividing line. Organizations whose management interfaces are reachable only from trusted internal networks are less exposed. Appliances managed from the internet, or reachable across a flat internal network from any compromised workstation, meet the condition without anyone intending it. The product spread of the second flaw matters more than the first. The same timezone handling appears in the load balancer ADC, the web application firewall, the web security gateway, the message archiver and the WAF control centre.

What to check:

• The firmware and patch level of each Barracuda product in the estate, since the second CVE covers six product lines with six separate patch identifiers.
• Whether the administrative interface answers on any address reachable from outside the management network, tested from the internet rather than an inventory.
• The configured timezone value, which should be a plain zone name and nothing else.
• Configuration import history, since a restore that nobody scheduled is the observable half of the unauthenticated step.
• Whether the appliance holds bind credentials or an LDAP account, which determines what an operator has to treat as exposed after a compromise.

What would change the assessment: A firmware build in which the import route enforces a session would remove the unauthenticated half and leave an authenticated root escalation. That would change the population and the priority together. The vendor’s 5 November correction runs the other way, and it is the stronger evidence because it comes from the party with access to the code.

The work in all three cases lands in a component with its own change control. A kernel fix needs a reboot window and an appliance fix needs a firmware slot that the vendor schedules. An sshd fix needs a daemon restart inside images that are rebuilt rather than patched. That is a scheduling difference rather than a technical one. Three fixes with published deadlines will still be outstanding where operators consider themselves current.