The CVSS 9.6 rating on CVE-2026-77087 technically scores the worst-case ceiling, but it collapses a narrow, precondition-dependent attack into a critical-severity label that misrepresents realistic exposure. That's the analytical problem worth fixing first.
Paperclip's local_trusted mode treats network locality as a identity anchor — it trusts any HTTP request originating from the same machine without validating the Host header or connection source. DNS rebinding exploits this by making a malicious domain resolve to 127.0.0.1 at request time after the victim has already visited the attacker's page. This isn't a remote network attack; it's an intra-process information flow that requires the developer to be simultaneously running Paperclip and browsing the web in the same browser session. The attacker's control is bounded by browser security policies that DNS rebinding only partially circumvents.
The preconditions significantly narrow the surface: local_trusted must be the default configuration, the developer must be actively browsing while the server runs, and the process adapter must be reachable. Each layer attenuates the realistic threat. The consequence — authenticated command execution through the process adapter — is real and severe, but the trigger conditions are narrower than the 9.6 implies.
What's more important than the score: this vulnerability has appeared with near-identical genetics for two decades. DNS rebinding against loopback-trusting services was documented in 2007 against Apache, then Redis, then Rails. Paperclip is the latest branch on a family tree we've been pruning incorrectly — issuing new CVEs for the same root cause without addressing the underlying design assumption that network address equals identity. The pattern persists because "localhost-as-trusted" is baked into developer tooling culture.
For defenders: verify whether local_trusted is your default mode, and whether your development workflow involves browsing untrusted sites while the server runs. The immediate fix is Host header validation or explicit loopback allowlisting. The deeper question is whether the trust model itself should survive the modern development environment, where browsers, IDEs, and local servers share the same host and the same cookie jar. The correct long-term fix may be eliminating the model entirely — not patching one instance of a vulnerability class we've known about for twenty years.