Trust Boundaries Do Not Patch: Three SSRF Cycles and the Confused Deputy in Our Own Stack

When SonicWall published firmware 12.4.3-03670 and 12.5.0-03082 to close CVE-2026-102255, I did what I always do with an advisory: I scrolled past the header and hunted for two phrases — "pre-authentication" and "no mitigation measures available." Both were there. For the third consecutive disclosure cycle, the SMA1000 remote access gateway had opened with the same wound. An unauthenticated attacker reaches the edge reverse proxy at Work Place and /wsproxy, and that proxy — before a single credential is verified — acts on the attacker's behalf. CVSS 10.0. Same product line, same shape, only the CVE number moves. The code compiles, but does it heal? Three cycles is no longer a bug. It is a design record, written in the only language a machine respects: repetition. The class is Server-Side Request Forgery, tagged CWE-918 and, far more tellingly, CWE-441 — the "confused deputy." The idea is almost philosophical before it is technical. A deputy is an agent granted authority to act for someone else. It becomes confused when an attacker, with no authority of their own, persuades it to exercise that authority on the attacker's behalf. On the SMA1000, the deputy is the edge reverse proxy. Its authority is the trust the internal network places in it. Its confusion is that it validates the request before it validates the requester. This is why I keep circling back to crypto when I read security advisories like this one. We built an entire industry on the promise of removing deputies. "Don't trust, verify" is a confused-deputy prevention slogan in disguise. And yet the same flaw keeps surfacing in our own stack. A cross-chain bridge relayer that signs a message on behalf of a user before confirming the user controls the funds. An oracle that accepts a price before checking whether the reporter is staked. A sequencer that bundles transactions and calls itself decentralized while running on one operator's machine. Each one is a deputy, and each one can be confused. Trust is not encrypted; it is woven. And a woven thing is only as strong as the pattern, not the thread. The SonicWall pattern is broken at the point where the proxy decides to act — which is to say, at the boundary, before authentication. That is not a coding defect. It is a design decision, and design decisions do not receive patches. They receive architecture. Here is where the analysis has to slow down, because the honest reading of three cycles tells us something the patch notes will never admit. Let me walk through what the disclosed chain actually looks like, and then show you why the crypto parallels are not decorative. The chain is a complete, pre-authentication-to-post-authentication ladder. It opens with the SSRF at the edge — CVSS 10.0, reachable before any login. It continues with a command injection (CWE-78), a Zip Slip path traversal (CWE-22), and a stored cross-site scripting flaw (CWE-79), all disclosed in the same batch. Read that sequence carefully. The pre-auth entry is the door. The post-auth flaws are the rooms behind it. When both are disclosed together, defense-in-depth has not failed at one layer — it has failed at every layer simultaneously. That is not a lapse. That is an absence of depth. The disclosed history includes something worse than an SSRF. The same product line has been tied to stolen TOTP MFA seeds and ransomware campaigns — tracked as UTA0533 and INC Ransom — meaning the boundary failure is not theoretical. Authentication infrastructure that leaks is categorically worse than data that leaks, because credentials are the keys to lateral movement. When the deputy is confused and the MFA seeds are gone, the attacker no longer needs to break in. They walk. The attack surface itself tells the story. Three separate management planes — the Work Place portal, the /wsproxy endpoint, and the Appliance Management Console — are all exposed, each carrying its own independent flaw. Three doors on the same wall, none sharing a lock, none sharing a guard. In crypto terms, this is the exchange that runs a hot wallet, a signing service, and an admin API on the same host and calls it redundancy. Convergence of attack surface without convergence of defense is not architecture. It is accumulation. Now the crypto mirror. In 2022 I documented fourteen case studies of retail investors who lost everything in the Terra/Luna collapse, and I learned that the failure was never a single bad oracle reading. It was a stack of trusting components, each deferring to the one below it, none verifying the one above. The SMA1000 tells the same story in hardware. The proxy trusts the internal service. The internal service trusts the proxy. The authentication layer arrives too late to mean anything. Three boundaries, zero independent verification. The most damning detail is the pattern's recurrence. The same product line has now opened with a pre-authentication SSRF in three separate disclosure cycles — CVE-2026-15409, then CVE-2026-83548, then CVE-2026-102255. If those three share a root cause, then every patch in between treated a symptom. If they do not share a root cause, then the recurrence itself is the evidence — it proves the trust boundary has never been renegotiated, only re-taped. This is exactly the pattern I see in Layer2 rollups that keep shipping "decentralization roadmaps" while their sequencer remains a single centralized node. The roadmap is the patch note. The sequencer is the unchanged boundary. Why does this happen? Not malice, and rarely incompetence. It happens because the architecture that produces the flaw is also the architecture that makes the product work. A remote-access gateway exists to let outside traffic reach inside systems. Its whole commercial purpose is to be a deputy. Reconciling that purpose with a hard trust boundary — where the proxy authenticates before it acts, where the proxy process runs in a least-privilege sandbox, where edge and internal functions are isolated in both network and permission terms — is not a sprint. For a mature hardware line, it is a rebuild. And rebuilds are expensive, slow, and invisible to the quarterly subscription renewal. What would a real fix look like? Based on my audit experience with enterprise gateways, the honest answer is unglamorous. Force authentication to precede any proxy action, so the deputy cannot act before it knows who it serves. Sandbox the proxy process to the minimum privilege its job requires, so confusion costs little. Isolate the edge from internal functions at both the network and the permission layer, so a breach of one is not a breach of all. None of this is novel. All of it is expensive. That is precisely why it keeps not happening. So the incentives quietly point one way. Patch the CVE, publish the firmware, tell customers to update. The architecture stays. And here is the part the security industry rarely says aloud: "no mitigation measures available" means every ounce of that architectural debt is transferred to the customer as operational burden. The vendor's design flaw becomes the customer's upgrade weekend. That is a silent form of responsibility laundering, and it is the same laundering that happens when a DeFi protocol suffers an exploit and "urges users to revoke approvals" — pushing the cost of a design failure onto the people least equipped to carry it. Silence is the loudest indicator of systemic rot. What is not said in that advisory — that the boundary is still wrong, that this will recur — is more informative than everything that is. Now let me argue against myself, because the comfortable reading is a trap. The convenient frame — and the source material reaches for it — is "industry common problem." Cisco's FMC and NX-OS have shown comparable pre-authentication flaws. Look, the story goes, everyone struggles; this is the nature of edge security. There is truth in that. But notice what the frame does. It converts a specific accountability question into a diffuse one. If everyone is guilty, no one is. The "common problem" narrative is an absolution device dressed as analysis, and I distrust it the way I distrust a bull-market founder who answers every technical question with "we're building the future." Specificity is a form of honesty. The second trap is subtler and it is about the information itself. The advisory I am reading carries anomalies that a careful reader cannot ignore. The finder of one CVE is attributed to a researcher whose public affiliation contradicts the credit given. Another researcher is attributed to two different organizations in the same document. The CVE numbers themselves jump between a six-digit and a five-digit range with an implausible spread. These are the fingerprints of synthesized or poorly transcribed content — the kind of confident, detailed, subtly wrong material that AI now produces at industrial scale, and that human analysts increasingly copy without checking. I am not raising this to dismiss the technical argument, which stands on its own logic. I am raising it because the crypto industry is drowning in exactly this. We read a thread, a report, a "research note," and we act — we allocate, we migrate, we panic — on details no one verified against the primary source. My rule, after years of watching narratives move markets faster than facts, is simple: when the attribution and the identifiers are wrong, downgrade everything and go to the original advisory. Trust the boundary logic; do not trust the byline. And there is a third angle, quieter. When a flaw recurs three times, the industry's instinct is to blame the vendor. But the customers who keep renewing, who keep deploying the same boundary device because migration is painful, are also part of the loop. Switching cost is the moat, and moats are comfortable for everyone standing inside them. The uncomfortable question is not only "why does the vendor keep shipping this?" but "why do we keep buying it?" — and that question has no comfortable answer. So what should a builder take from three SSRF cycles in a product most of us will never deploy? A question, not an answer. Feminine wisdom asks not "is the feature shipped?" but "who carries the cost when it breaks?" The deputy is always confused at the boundary, and the boundary is always a choice. In your protocol, in your bridge, in your sequencer, find the place where an agent acts before it verifies. That place is your CVE-2026-102255, whether or not it has a number yet. Authenticate the requester before you honor the request. Isolate the authority you grant. And when a fix arrives, ask the only question that matters: did the code heal, or did it merely compile?