This week's intrusions hid in the handoff between two trusted systems

Two logs on the same GPUStack server described one request in two different ways, and both were accurate. The reverse proxy recorded a client somewhere on the internet. The application behind it recorded the same request arriving from 127.0.0.1, an address that GPUStack releases before 2.2.0 treated as the built-in administrator. Neither log held an error. The compromise lived in the space between them, and on November 9 CISA added that flaw, CVE-2026-102895, to its Known Exploited Vulnerabilities (KEV) catalog.

That space is this week's real story. Five of the incidents we covered, GPUStack, OpenSSH on Alpine Linux, SonicWall's SSL VPN, the cPGuard update hijack and the DreamHost File Manager breach, were not one component failing. Each was two components, each doing what its own documentation promises, joined by an assumption only one side knew about. That changes where a defender should look. In all five, the evidence was hard to see from either side alone and plain once the two records were put next to each other.

One request, two honest logs

Start with GPUStack, because it is the cleanest case. Putting Nginx or Caddy on the same host to terminate TLS is the ordinary way to publish a self-hosted web app. Do that in front of an older GPUStack and every visitor reaches the application from loopback. The project's advisory describes a second route through a forged forwarding header, and that is the route most teams rushed to filter. The first route needs no forgery at all: your own proxy supplies the trusted address.

Notice who owns each half. The proxy usually belongs to whoever runs the server. The application often belongs to a machine-learning team that stood it up once. Each half passes its own owner's review, and nobody is responsible for the join. As our GPUStack write-up noted, the advisory records attackers registering custom inference backends on a 2.1.1 deployment to open reverse shells.

The detection point sits at step four for a reason. Creating an inference backend is a rare administrative act. On the application side it looks like the administrator did it from the machine itself. On the proxy side it is one POST among thousands. Line the two up by time and path, and an outside address performing an admin action from "localhost" stands out at once.

The same seam, four more times

Inside one process. The OpenSSH bug on Alpine, CVE-2026-123158, is a seam between a C library and the daemon calling it. Without PAM, sshd checks passwords through musl's crypt(). Per Alpine's advisory, musl reports a too-long key by returning a lone asterisk, and a lone asterisk is also what Alpine writes into the shadow file for accounts with no usable password. Each convention is reasonable. Together, a long password matches a passwordless account. The OpenSSH maintainers say the root cause sits outside sshd, and the 10.6p2 fix lives inside it anyway, because the daemon is where the two contracts meet. We broke down the conditions in our OpenSSH post.

Between the identity team and the network team. On a SonicWall firewall that sends SSL VPN logins through SAML, the identity provider enforces MFA, but the firewall decides which logins go to the identity provider. SonicWall's advisory for CVE-2026-19868 says valid credentials for an alternate login method can skip SAML, and with it MFA. CISA listed it as exploited on November 6. The identity provider's log shows nothing, because the login never reached it. The firewall shows an ordinary success. As we wrote, the tell is a firewall login with no matching identity-provider sign-in.

Between a vendor and its customers. In the cPGuard incident, an attacker who reached the vendor's billing portal pushed a malicious update that executed with root privileges on roughly 2,950 customer machines, by the vendor's count. According to the vendor's notices, the stolen files were staged on its own licensing server. A customer egress rule that trusts the vendor saw normal traffic, and the vendor's side saw a trial signup. The most reliable exposure check in the vendor's notices is on the customer's side: the install log, matched against the bad builds the vendor later listed.

Between a host and its tenants. DreamHost's File Manager collected the FTP and SFTP logins of customers who used it from August until October 23, according to the company's notice. The provider can reset passwords. Only the tenant's own files show what was written while those logins were in someone else's hands, which is why our DreamHost guide ends in a file diff, not a reset.

Why seam bugs survive review

A test suite checks a component against its own contract. musl can rightly test that crypt() refuses an oversized key. Alpine can rightly test that a lone asterisk blocks a password login. Neither test contains the other's assumption, so both stay green while the product is open. The same holds for a proxy that faithfully forwards and an app that faithfully trusts loopback. Code review fails here for the same reason: a reviewer reads one side of the join.

Our own tracking shows the limit of a per-bug view. In the seven days to November 10 we triaged 6,390 vulnerabilities, logging a decision on each, and around 42 carried exploitation signals by our tracking. Authentication and account-takeover flaws made up 201 of those triaged entries, the third-largest class behind cross-site scripting at 325 and command injection at 210. The three seam CVEs this week are all authentication flaws, and each is recorded as a flaw in one product. The record never captures the second product that made it reachable, which is the half your environment decides. A CVE feed can tell you that GPUStack trusted loopback. Only your own inventory can tell you that a proxy sits in front of it.

Logging follows ownership, and that is the deeper problem. The proxy log goes to the web team, the application log to the ML team, the identity log to the identity team, the firewall log to the network team. Each is complete and correct. The join that would have exposed this week's intrusions usually does not exist anywhere, because nobody owns both halves.

Log both sides of every handoff, then join them

Patching each product closes its half of the seam. Finding out whether someone already walked through it takes the join. Concretely:

• Map the handoffs and the claim that crosses each one. A source address, a SAML assertion, a vendor-signed update, a password the provider holds, a value a library returns. Wherever a claim is trusted without being re-checked, you have a seam.

• Same-host proxies. No application should treat loopback as an identity. For GPUStack, upgrade to 2.2.2, which also closes the SAML callback flaw CVE-2026-102894, and set force_auth_localhost: true where you cannot. Ship the proxy and application logs to one place and review each backend creation against a named admin.

• SSO in front of a VPN. Enable SonicOS event 1080 for successful SSL VPN logins, correlate each one with an identity-provider sign-in, and retire every credential the firewall still accepts outside SAML.

• Root agents with auto-update. Keep a dated record of agent versions per host, because cPGuard exposure came down to the install log. Log outbound volume even to allowlisted vendor hosts. Remove vendor support keys from root's authorized_keys between tickets.

• Provider-run front ends. Keep a file baseline and a backup the provider cannot edit, so you can diff a site against the start of any disclosed window.

• Library conventions. On Alpine hosts running sshd, list accounts whose shadow field is a lone asterisk, then patch and restart the daemon.

awk -F: '$2=="*"{print $1}' /etc/shadow
grep 'POST /v2/inference-backends/from-yaml' /var/log/nginx/access.log
SonicOS: Device > Log > Settings > Users > Group Authentication Access > Event ID 1080

The vendor advisory is a handoff too. Barracuda's November 2 advisory said CVE-2026-116606 in its Email Security Gateway needed an administrator login. On November 5 it revised that to no authentication at all. A triage decision made on Monday was built on the earlier claim. Treat an advisory revision as a new event that reopens the ticket, and keep the logs on both sides of every boundary you depend on. The intrusion you miss will usually not be in either log alone.