RC RANDOM CHAOS

The copy runs past the allocation, again

Recurring dystopian tech vulnerabilities persist because defenders patch the CVE instance and never hunt the underlying mechanism. The inaction is the vuln.

· 7 min read
The copy runs past the allocation, again

EternalBlue is nine years old. CVE-2017-0144, CVSS 8.1. Remote code execution in SMBv1 through a buffer overflow in the SRV driver’s handling of crafted transaction requests - the packet declares one length, the parser trusts it, the copy runs past the allocation. Microsoft patched it in MS17-010 in March 2017. It powered WannaCry and NotPetya inside two months. It is still logged against live hosts in 2026.

The patch closed one door. The mechanism - an unauthenticated, network-reachable service parsing an attacker-controlled length field - was never retired. That is the finding. Not the specific horror. The failure to hunt the condition that regenerates it.

A CVE is one instance. A bug class is the condition that produced it. Patching the instance and ignoring the class is why the same dystopia gets a new identifier every year and the same three sentences of analysis.

Take memory-unsafe length handling. EternalBlue was SMBv1. The identical primitive - trusted length, unchecked copy - shows up in CVE-2020-0796 (SMBv3 compression, “SMBGhost,” CVSS 10.0), in the recurring TCP/IP stack bugs, in every protocol parser written in C that treats a wire field as ground truth. The language permits the write. The design permits the reach. Rewriting one driver does not remove the class. The class lives wherever an unauthenticated remote service parses untrusted structure into a fixed buffer.

Take untrusted input reaching an evaluation context. Log4Shell, CVE-2021-44228, CVSS 10.0. A logging library performed recursive JNDI lookup on strings it logged as data but processed as instructions. Attacker text flowed from an HTTP header into a resolver that reached out over LDAP and loaded a remote Java class. T1190, exploitation of a public-facing application, chained straight into T1105, remote class retrieval and execution. The mechanism is a trust-boundary violation - content crossed into command. The same class is Spring4Shell, server-side template injection, and every insecure deserialization sink shipped since. Defenders wrote WAF rules for the literal string. Obfuscated variants using nested lookups bypassed the first rule wave inside 48 hours. Signatures catch literals. The mechanism generates infinite literals.

Take unauthenticated management surfaces. Exposed RDP. Exposed Redis. Exposed Kubernetes API servers. Cloud instance metadata at 169.254.169.254, reachable with no authentication, credentials served to anything that can force a server-side request. That is the Capital One vector from 2019 - SSRF into IMDSv1, T1552.005, unsecured credentials pulled from a metadata service. AWS shipped IMDSv2 with session tokens and a hop-limit that breaks the SSRF path. It is opt-in. In 2026 IMDSv1 still answers on running instances because migration was never enforced by default. The prediction was published. The inaction outlived it.

Take identity that trusts the wrong signal. Default credentials on network appliances, T1078. Hardcoded secrets committed to repositories, then reused across environments. Session tokens accepted without device binding, replayed after theft - the Okta support-case breach in 2023 ran on stolen session material, not cracked passwords. The class is authentication that verifies possession of a token and never verifies the context around it. Every phishing-resistant control that stays optional leaves the class intact.

Take trust-by-name in package resolution. Dependency confusion, disclosed by Alex Birsan in 2021, T1195.001. The resolver prefers the highest version number it can find across every configured registry, so a public package can shadow an internal name the moment someone claims it. The mechanism is provenance losing to version precedence. Five years on it still ships as the default behavior in common package managers, and it resurfaces as every typosquat, every namespace claim, every CI/CD pipeline that installs from an untrusted index with build-time credentials in scope.

The pattern across all six is the same. The instance gets a patch. The class gets a write-up. Nobody is tasked with hunting the class across the estate. Vulnerability management measures itself on time-to-patch against known CVEs. It does not measure coverage against the mechanism, because the mechanism has no CVE number and no vendor to file the ticket against.

This is a detection-engineering failure before it is a patching failure. Look at what actually fires. Sysmon Event ID 3 logs the network connection. Event ID 22 logs the DNS query to the callback host. Event ID 1 logs the process create. Windows Security 4688 logs the child process. A detection keyed to the callback domain fires once, for that campaign, against that infrastructure. The next actor rotates infrastructure. The reputation feed is empty. The hash is unseen. The atomic detection, bound to the last incident’s indicators, sees nothing. The mechanism executed cleanly under a rule written to catch its previous costume.

The behavioral signal was present the whole time. A java or w3wp process spawning cmd or /bin/sh is anomalous regardless of the callback host - that is the Log4Shell mechanism, visible in the process tree, independent of any IOC. An instance-role credential presenting from an IP outside its VPC is the IMDSv1 mechanism, visible in CloudTrail, independent of the SSRF entry point. A non-security process opening a handle to LSASS with PROCESS_VM_READ is credential theft, Sysmon Event ID 10, Windows Security 4656 and 4663 on the LSASS object - the mechanism of T1003.001, not the tool that performed it. These detections survive infrastructure rotation. They key on the invariant, not the indicator. Almost nobody writes them, because writing them requires modeling the mechanism, and the incident retro only asked for the domain to block.

Real-world use confirms the recurrence rather than the novelty. Sandworm ran NotPetya through EternalBlue and credential reuse in 2017; the credential-reuse half of that chain, T1550, still works in 2026 because flat networks and shared local-admin passwords were the real enabling condition, and neither was a CVE. Hafnium chained ProxyLogon - CVE-2021-26855 SSRF plus CVE-2021-27065 write primitive - into Exchange webshells; the SSRF-to-authenticated-action class it abused is the same class that produced ProxyShell months later on the same product. Citrix Bleed, CVE-2023-4966, CVSS 9.4, leaked session tokens out of an under-bounded buffer and drove session hijack against multiple named intrusions; the sensitive-memory-in-response class it belongs to is Heartbleed’s class, a decade on. Different products. Different actors. One mechanism per row, repeating.

None of this is advanced. That is the point. The primitives are public, in some cases for ten years. What persists is not attacker sophistication. It is defender inaction against the mechanism, dressed up as diligence against the instance.

The reframe changes the work. Treat the class as the unit of coverage, not the individual CVE. For every high-severity bug that lands, the question is not only whether the affected versions are patched. It is where else in the estate the same mechanism exists without a CVE to announce it - every other parser trusting a wire length, every other sink evaluating logged input, every other credential endpoint reachable without authentication, every other resolver that prefers version over provenance. That inventory is the hunt. It does not fall out of a scanner feed, because scanner feeds are indexed by CVE, and the mechanism is precisely the part that has no CVE yet.

Post-patch residual exposure is where this bites. MS17-010 is installed almost everywhere now. SMBv1 is still enabled on segments nobody audited, and the length-trust class still ships in newer parsers. Log4j is upgraded in the applications someone remembered; the untrusted-input-to-eval class is intact in every dependency that was never inventoried. IMDSv2 exists; IMDSv1 responds anyway. The patch boundary is real and it is narrow. It closes the named instance. It does not close the class, and the class is what resurfaces.

For operators under the SOCI Act and the Privacy Act, this is a governance exposure as much as a technical one. Mechanism-level recurrence means an incident traceable to a class flagged years earlier is not an unforeseen event - it is a documented, un-actioned risk, and it reads that way in a post-incident review. Where an active intrusion is suspected against a critical asset, that routes to the incident response function and the relevant national coordination body now, not into a backlog ticket.

The prediction was never the hard part. The dystopia posts from years ago were correct. They stay relevant because the mechanism under them was never hunted - only the instance was patched, and the instance was always the smaller half of the problem. The bug that keeps coming back is not the exploit. It is the decision to stop at the patch.

See also: NordVPN for tunneled traffic when operating outside controlled networks.


#ad Contains an affiliate link.

Share

Keep Reading

Stay in the loop

New writing delivered when it's ready. No schedule, no spam.