Between October 28 and November 6, four unrelated vendors shipped fixes for four unrelated products. Debian and Ubuntu patched apt. Canonical patched LXD. The WordPress project patched core. SonicWall patched SonicOS. Different languages, different protocols, different threat models.

Read the advisories side by side and you find one sentence that fits all of them: the system verified something, and then acted on something else.

  • APT verified a .deb, then installed bytes that were not the ones it verified.
  • LXD verified that a certificate in the TLS chain was trusted, then granted the identity of that certificate to whoever held the private key for a different one.
  • WordPress staged a release into a directory the web server would serve, and trusted the directory to stay private for the length of the upgrade.
  • SonicOS enforced SAML-delivered MFA on the SAML login path, then accepted the same user on a path that never touched SAML.

I have written before about verification theater, where a check confirms a label instead of the object. This is the sibling bug, and in my view the more dangerous one, because the check is real and correct. The cryptography works. The hash matches. The signature validates. The failure is that nothing binds the result of the check to the thing that later gets used.

This post is about how to recognise that gap, why it keeps surviving code review, and what to do about it on the infrastructure you run.

Four cases, one shape

APT: verify, then install (CVE-2026-109518)

APT’s model is sound on paper. Repository metadata is signed. Package hashes live in that metadata. A downloaded .deb is hashed, compared, and only then handed to dpkg. That is why Debian and Ubuntu mirrors can serve over plain HTTP and nobody panics.

CVE-2026-109518, reported by Max Justicz and fixed on November 4, breaks the ordering. Per Ubuntu’s notice (USN-8996-1), APT mishandled hard links when it hit redirects and retried package downloads. The CVE record maps it to both CWE-62 (UNIX hard link) and CWE-367 (time-of-check/time-of-use). The practical reading, from vendor analyses such as StepSecurity’s write-up: after the hash check passes, a resumed transfer can write through to the already-verified file. An on-path attacker, whether a hostile proxy, a compromised mirror or someone on the wire of an HTTP source, replaces the contents. dpkg installs them as root, and maintainer scripts run with that privilege.

The signature chain was never forged. The check passed honestly. It just described a file that was no longer there by the time it was used. The vulnerable retry path is on by default (Acquire::Retries defaults to 3 since apt 2.3.2), so stock Debian 12 and Ubuntu 22.04 and later are exposed. Treat the independent technical detail as thinner than the headline: Debian and Canonical describe the bug briefly, and the deeper mechanism comes mostly from vendor-adjacent blogs. No in-the-wild exploitation has been reported.

LXD: trust the chain, authenticate the leaf (CVE-2026-112816)

LXD’s HTTPS API uses mutual TLS. A client presents a certificate chain, and LXD compares what it sees against its trust store. According to Canonical’s advisory, the code compared every certificate in the presented chain against the store. But a TLS handshake proves possession of exactly one private key: the leaf’s.

So an attacker builds a chain whose leaf is a certificate they generated, and appends a trusted client’s public certificate further up. The handshake succeeds, because the attacker holds the leaf key. The trust lookup also succeeds, because a trusted certificate is in the chain. LXD concludes the caller is the trusted client. CVSS 4.0 scores it 10.0.

The input that matters, a trusted public certificate, is not secret. You can see it on the wire during a MicroCloud join. An admin identity here means privileged containers, host path mounts and command execution on the host, which is root on the hypervisor. Fixed in LXD 6.10.1, 5.21.9, 5.0.11 and 4.0.15, and MicroCloud 2.1.5 and 3.4.1. Reports on exploit status conflict (one cites a public proof of concept on November 1, others none), so assume the technique is public.

WordPress: a private directory that isn’t (CVE-2026-119977)

WordPress extracts a full-package upgrade into wp-content/upgrade/ before promoting it. Per published analyses, before 7.1.4 the staging names were predictable and the directory was reachable over HTTP on default configurations. The “check” here is implicit: the updater assumes that for the duration of the upgrade, nobody can read or influence the staged tree. That assumption was never enforced by anything.

CISA added it to KEV on November 3. The severity disagreement is instructive. Wordfence’s CVE record says CVSS 3.1 8.1. The WordPress project rates it Low. Patchstack argued the race window is too short to matter. CISA’s listing is the answer to that argument: a window that is short for one attacker is a polling loop for another. Anyone who can request a path every 50 ms for a few days will eventually land in it, especially against hosts that run auto-updates on a schedule or extract slowly under load. Treat the exact attempt counts floating around in blog posts with suspicion; they vary by an order of magnitude and none are well sourced.

SonicOS: MFA on the door you inspected (CVE-2026-19868)

SonicWall’s advisory SNWLID-2026-0014 describes an SSL-VPN configured for SAML that still lets an attacker with valid credentials authenticate through a non-SAML method, bypassing the identity provider and its MFA. CISA added it to KEV on November 6, with a November 20 deadline. SonicWall says there is no workaround; fixes are 7.3.4-7013 (Gen7) and 8.2.3-8015 (Gen8).

Nothing was wrong with SAML. The enforcement lived on the login route the admin configured and tested, and the policy “this user requires MFA” was not attached to the user. It was attached to one of several ways in. Same class of failure, different layer.

The shared structure

Strip the product names and each case has three steps:

  1. Check property P of object A (hash, trust, privacy, MFA status).
  2. Time or path passes: a retry, a chain walk, an upgrade window, an alternate login method.
  3. Use object B, assuming P still holds.

The bug exists whenever A and B can differ and an attacker influences the difference. Our industry has names for the narrow versions (TOCTOU, confused deputy, improper certificate validation, auth bypass), and that is the problem. Because the names live in different CWE categories, different teams own them, different scanners flag them, and nobody asks the general question in design review: what ties the check to the use?

Why this survives review

The check is tested, the gap is not. Unit tests prove that a bad hash is rejected. They do not prove that a good hash remains good. LXD’s test suite presumably verified untrusted certificates fail; the failing case needed a trusted certificate attached to an untrusted one.

Retry, resume, redirect and fallback code is the gap factory. APT’s bug lives in the code that handles failure. These paths are written later, tested less, and reached by attackers who can induce failure. If you can drop a connection or return a 3xx, you have a lever on the state machine.

Alternate paths accumulate. Every legacy login method, every compatibility flag, every “also accept” is another route that the security control must be re-attached to. SonicWall is the latest in a long line of VPN edge appliances where enforcement was per-route. See our earlier coverage of edge devices in Q1 and two parsers, one URL for how often this repeats.

Severity scoring punishes it. “Requires on-path position,” “requires valid credentials,” “race window is short,” “requires the attacker to hold a public cert.” Each qualifier lowers the CVSS number, and each describes something attackers get cheaply. A hostile Wi-Fi network, a stuffed password and a polling loop are commodity. This is the same severity drift problem: the score measures how hard the bug is to explain, not how hard it is to use.

What to do about it

1. Audit the verify-then-use seams you own

Most of your risk is not in the vendor code. It is in your pipelines, which implement the same pattern in shell. Look for:

1
2
3
4

# Check and use are separate steps on a path an attacker may influence
curl -o /tmp/tool.tgz "$URL"
sha256sum -c tool.sha256        # checks the file...
tar -xzf /tmp/tool.tgz -C /opt  # ...then uses it later, by name

Predictable paths in world-writable directories, hash checks on files that are re-read afterwards, and “download, verify, move” sequences across a shared volume all qualify. Fix by verifying and consuming the same handle: download to a private directory (mktemp -d, mode 0700, owned by the job), verify, and extract from that exact file, or pipe through a verifier that fails closed.

2. Make package installs unfalsifiable in transit

For the APT case specifically:

1
2
3

# /etc/apt/apt.conf.d/99hardening
Acquire::Retries "0";        # temporary stopgap on unpatched apt only
Acquire::AllowRedirect "false";   # where your mirrors do not redirect

and move every sources.list / .sources entry to HTTPS to a mirror you pin. Update apt first: patched builds are 2.6.2 (Debian 12), 3.0.4 (Debian 13), and per-release Ubuntu updates, so confirm against the tracker for your release. Then rebuild container images and CI runner images that ran apt-get install over networks you did not control, and audit them:

1
2

debsums -c 2>/dev/null     # changed files vs. package md5sums
dpkg -V                    # verify installed files

Remember that debsums compares against the package’s own metadata. If a swapped package carries its own consistent file list, you need to compare against the archive’s Packages hashes, not just local metadata.

3. Re-ask the identity question on every mTLS service

For anything that authenticates with client certificates, the property you need is: the identity is derived from the certificate whose private key was proven in the handshake, and nothing else in the chain. Test it. Build a chain with an attacker-owned leaf and a trusted cert as an intermediate, and confirm you are rejected. Do this for LXD and Incus, but also for internal service meshes, API gateways and anything homegrown.

Then shrink exposure, since this class tends to produce 10.0s:

1
2

lxc config get core.https_address     # is the listener on at all?
lxc config trust list                 # stale entries are raw material

Management listeners belong on a management network, not on a tenant VLAN.

4. Enumerate authentication paths, not just policies

For every VPN, SSO-fronted app and bastion, list every way a session can be established, then verify the MFA requirement on each one. For SonicWall specifically, after patching to 7.3.4-7013 or 8.2.3-8015:

  • Disable unused authentication methods on the SSL-VPN realm.
  • Hunt for sessions with no matching IdP assertion. Join VPN login events against SAML assertion logs by user and a ±60 second window:
1
2
3

vpn_login(user, t, method != "saml")
  AND NOT EXISTS idp_assertion(user, t' in [t-60s, t+60s])
  AND user IN (group: saml_only)

Any hit since late October deserves credential rotation and session revocation for that user.

5. Treat “race” and “needs a window” as exploitable

For WordPress, patch to 7.1.4 or the backport for your branch. Until then, deny the staging path at the edge:

1

location ^~ /wp-content/upgrade/ { return 403; }

Hunt for the bug’s footprint:

1
2

grep -E 'GET /wp-content/upgrade/' access.log \
  | awk '{print $1}' | sort | uniq -c | sort -rn | head

Unauthenticated requests to anything under that path since October 28, especially to staged copies of setup-config.php, bursts correlating with upgrade events, and new PHP files or admin users afterwards. More generally: any updater, installer or migration tool that stages privileged material on disk should run with a private work directory and not rely on a short window.

6. Put a design-review question on the checklist

One question catches this whole family: “After this check passes, what can change before the action, and who controls it?” Ask it for hashes, tokens, certificates, permissions, MFA state and path ownership. If the answer is “nothing, because we use the same handle,” you are fine. If the answer is “a short window” or “an attacker would need X,” you have just written a CVSS qualifier, not a mitigation.

Takeaways

  • The recurring failure is not weak verification. It is verification not bound to use. A correct check on the wrong object is worth nothing.
  • Retry, redirect, resume, fallback and alternate-login code are where the gap hides. Review them as attack surface, not error handling.
  • “Needs a race,” “needs on-path,” “needs valid credentials” and “needs a public certificate” are not mitigations. Each is a commodity capability. Prioritise accordingly.
  • Verify and consume the same handle: private directories, file descriptors, immutable copies, identity derived only from the proven key, MFA attached to the account rather than to a login route.
  • Patch this month: apt, LXD/MicroCloud, WordPress 7.1.4 (KEV, past its federal deadline), SonicOS 7.3.4-7013 / 8.2.3-8015 (KEV, due November 20). Then spend an afternoon grepping your own build scripts for the same pattern.

Sources