Unpatchable Primitive

Exhibits

CVE-2025-24054: The Two Verbs That Don't Trigger Are 'Open' and 'Execute'. CVE-2025-24054 is the .library-ms half of a primitive whose .URL half is CVE-2025-33053. Both Windows shell metadata formats exist to embed a URL the shell resolves at metadata-render time; the URL element is what the format does. The March 2025 Patch Tuesday closed two render paths for .library-ms (CVE-2025-24054 for selection-and-inspection, CVE-2025-24071 for folder-navigation) and left the URL-resolution capability intact, because removing the URL fetch would close the file format. The cadence (three CVEs in this family in five months, each followed within weeks by in-the-wild use) is the unpatchable-primitive shape: each patch closes one rendering trigger, the underlying capability is the reason the metadata format ships at all. The fourth CVE in this family will arrive when a researcher finds a render path Microsoft has not yet patched.

CVE-2025-33053 Was the WorkingDirectory Half. The Other Half Got a Documentation Edit.. The .URL file format's reason for existing is the URL= directive: a shell-resolvable redirect that follows whatever URI the user authored. UNC paths are URIs, WebDAV servers are addressable as UNC paths, and binaries on those servers run when the shell follows the URL. CVE-2025-33053 closed the WorkingDirectory directive's effect on executable launches, a helper field with rare legitimate use. Closing the URL= directive's ability to name a UNC path or WebDAV URL would close the file format itself; a .URL whose URL= cannot resolve to a remote handler-resolvable URI is not a .URL. MSRC's reply that "when the Shell invokes an app from a remote share, it's expected" names the primitive without naming it: it is what .URL files do, and the patch does not reach it. The next variant of this primitive will not be a CVE either.

CVE-2026-24118: vm2's Patch Names Its Sibling. resetPromiseSpecies Was 2023.. CVE-2026-24118 is the V8-internal-bypass class of vm2's unpatchable primitive made explicit in source code. vm2's isolation rests entirely on a Proxy bridge whose get/set/apply/construct traps mediate every host-realm access. ES2024 §10.4.2.3 specifies that ArraySpeciesCreate reads this.constructor[Symbol.species] from the raw object, and V8 implements that step in C++ inside the engine; the C++ read does not call the Proxy's trap. The patch does not fix the bridge's blind spot; the patch hides the host array's constructor slot for the duration of every host call, then restores it. The defense is per-built-in: resetPromiseSpecies covered Promise.prototype.then in 2023, the new neutralizeArraySpeciesBatch covers Array#map/filter/slice/concat/splice/flat/flatMap and TypedArray equivalents in 2026. The vocabulary will grow whenever V8 ships another species-using built-in whose C++ implementation reads through to a raw object. The primitive (Proxy traps cannot intercept C++ reads) is unpatchable, and vm2's defense library is now formally organized as an inventory of the places where the Proxy gave up.

CVE-2012-1823: The 2024 Patch Removed The Feature The 2012 Patch Filtered. CVE-2012-1823 is the canonical user-mode example of the pattern. PHP-CGI's job is to invoke the PHP runtime with CGI's argv conventions, and RFC 3875 §4.4 codifies that the query string can become argv when no = is present. PHP took the convention literally. The 2012 fix added an in-process filter (URL-decode the query, check for leading -, skip getopt if so). The 2024 bypass (Orange Tsai / DEVCORE) proved the filter ran in the wrong process: Windows' WideCharToMultiByte Best-Fit mapping in CJK code pages turns U+00AD into ASCII - between PHP's check and kernel32!CreateProcessA's argv assembly, so PHP saw 0xAD (filter passes) and php_getopt saw -d (RCE). PHP's response was not a smarter filter. PHP's response was skip_getopt = cgi || fastcgi on Windows: PHP-CGI no longer reads argv from the URL on Windows in CGI/FastCGI mode at all, regardless of leading byte, encoding, or locale. The 2012 fix tightened the design. The 2024 fix removed PHP's participation in the design on the platform where the design could not be made safe.

CVE-2024-21182: WebLogic Denied `ForeignOpaqueReference`. `AggregatableOpaqueReference` Reaches The Same JNDI Lookup.. WebLogic's OpaqueReference family is the canonical shape this pattern names. The sink — MessageDestinationReference.lookupMessageDestination calling new InitialContext().lookup(attackerUrl) — is the primitive: server-side JNDI resolution against an attacker-controlled URL on bind() + lookup(). Oracle's CVE-2023-21839 patch denied the one carrier class then known (ForeignOpaqueReference). CVE-2024-21182 reaches the same sink through a sibling carrier in a different package (AggregatableOpaqueReference). The deny-list is keyed on class names; the sink reads any subclass of the same interface. One carrier per CPU cycle is the steady-state.

CVE-2026-10520: Ivanti Patched The Argument To handleMessage, Not The Call. CVE-2026-10520 is the MICS-admin-plane variant of the primitive. The pattern's mechanism named the three clues: each patch's advisory closes a specific path, but the root cause is architectural; the patch cadence does not trend downward; the credited researchers across years are different people. Sentry's two CVEs in the public record match all three. CVE-2023-38035 (Horizon3.ai, August 2023, KEV) and CVE-2026-10520+10523 (watchTowr, June 2026) both ride unauthenticated reach into wire-protocol dispatchers backed by CommonUtilities.executeNativeCommand, both got fixed at the bundled Apache HTTPD layer, and both left the dispatcher in the JAR unchanged. This exhibit adds the most legible confession in the catalog: the patched controller still calls the dispatcher with a wire-protocol "execute" message; only the message's value was replaced with a hardcoded Ivanti-chosen string that runs /bin/cat /sys/devices/virtual/dmi/id/product_name. The shell exec was kept because some internal caller needed the answer. The primitive is what stayed.

CVE-2017-9822: The Patch Encrypted the Cookie. The Deserializer Is Still Public.. DotNetNuke's XmlUtils.DeSerializeHashtable constructs an XmlSerializer from Type.GetType(<caller string>) and feeds caller-supplied XML into it. That contract IS the function. The 2017 patch encrypted the one cookie that reached this function; the function itself was not changed and still ships in the current DotNetNuke release as a public static method, with a deprecated public wrapper in Globals (DeserializeHashTableXml) that re-exposes the same primitive to any third-party module written against DotNetNuke.dll. Nine years of CVE-2017-9822 exploitation, CISA KEV listing, EPSS at the 99.94 percentile, and the underlying primitive is still callable. The patch is a key gate on one consumer; the substrate cannot be made safe without changing what the function does.

CLFS: Ransomware's Favorite Kernel Driver. The Common Log File System kernel driver has produced Windows LPE CVEs for more than a decade. Each patch closes a specific parser path. The primitive, a kernel component parsing user-supplied binary log files with broad trust, is the driver's entire job. Ransomware crews maintain CLFS primitive lists because they know the next instance is a matter of months. Microsoft patches. The next one arrives.

CVE-2026-109618 and CVE-2026-109619 Are Two Directions Through the Same Pre-RINIT Window. 8.5.12 does not reorder php_hash_environment() and zend_activate_modules(). It inserts php_basic_early_rinit() to do a surgical pre-RINIT for exactly the globals the window reads, and gates the serializers on PS(in_rfc1867_update) so objects decode as __PHP_Incomplete_Class. The window stays. Three post-patch paths are already in public PoC code: var_destroy re-entry UAF (5/5 on 8.5.12 CLI, root), handler mismatch via the application's own session_start() (verified at uid=33(www-data) on 8.5.12), and session injection where the filename is stored raw. The primitive is not a function. It is the ordering, and the ordering is load-bearing for the feature.

CVE-2026-40466: HTTP Discovery Was Row Two Of A Fourteen-Row Deny List. The primitive is "a JMX-reachable string method whose argument chooses a transport factory with config-fetching authority." Removing the primitive means changing addNetworkConnector(String) to take a constrained type, or removing the method from the public BrokerViewMBean interface. Neither happened in 5.19.6. The patch closes the http row of the deny list and leaves the registry-driven dispatch open. The HTTP discovery agent is a parser of remote content reachable through that dispatch; once the JMX validator approves a scheme whose factory fetches network bytes, the attacker controls the next round of input and the validator never sees it. The next CVE in this family is whichever transport factory's creation chain touches the network, the filesystem, or another URI parser before the validator gets a second look.

CVE-2026-34197: ActiveMQ's 5.19.4 Patch Denied One Scheme. Six Weeks Later, the Same Line Denies Fourteen.. The primitive is BrokerViewMBean.addNetworkConnector(String): a JMX-exposed method whose argument is a Discovery URI string parsed into transport factories with authority to fetch remote configuration. Removing the primitive means changing the method's parameter type or removing the method, both of which break the public ActiveMQ JMX contract. The 5.19.4 patch chooses the substitute: a name-based blocklist at the boundary, with the underlying authority of the transport factories untouched. The deny list grows by commit on the same branch in the same file because every scheme the registry knows about is a path the boundary did not previously refuse. The maintainer's own commit titles ("part 2") concede the shape.

CVE-2026-26332: vm2 Wraps Every Error the Sandbox Throws. SuppressedError Carries the Two V8 Threw.. SuppressedError joins the inventory of host-realm carriers vm2's bridge cannot intercept proactively. The construction site is V8's disposal-protocol implementation in C++; the sandbox does not call new SuppressedError in its own realm, so the sandbox-controlled constructor wrap cannot interpose on the carrier itself. The only available defense is to re-wrap the rethrown SuppressedError on the way back across the bridge, the same shape of after-the-fact patching that resetPromiseSpecies and neutralizeArraySpeciesBatch use for their respective C++ paths. ES2024 added two error-bearing carriers in one release (DisposableStack aggregating disposer throws into SuppressedError, plus e.stack's side-effect realm-leaking Symbol-coercion failures). The fix-vocabulary is now formally an inventory of places vm2 has conceded the Proxy cannot reach, growing by one entry per ECMAScript edition that ships another carrier.

CVE-2026-26956: vm2's Transformer Rewrites Every catch It Parses. WebAssembly's try_table Is Bytecode.. WebAssembly.JSTag is the second documented vm2 primitive that cannot be wrapped. The wasm runtime reads the tag's identity through a C++ slot, not through the JS property descriptor, so a Proxy around WebAssembly.JSTag is invisible to the matching logic in try_table. The maintainer's comment in lib/setup-sandbox.js says so directly: "wrapping WebAssembly.JSTag in a Proxy does not help because the wasm runtime reads the tag's identity through the C++ slot." The bridge is given up on. The defense is removal. Same shape as the resetPromiseSpecies fix; different V8 feature.

CVE-2026-24120: vm2's README Already Admits the Bug Class Is the Design. vm2 has shipped five fixes for the same Promise/host-realm-error primitive across thirty-two months: 26168e6 (2023-09), e43c635 (2023-10), 13651c2 (2024-08), 76ca2e9 (2026-01), a6cd917 (2026-02). The location of the next patch is predictable (handleException and globalPromise.prototype.then), even though the next entry point is not. vm2's own README says "New bypasses will likely be discovered in the future." That sentence is the maintainer's acknowledgment that this primitive is unpatchable in-process.

CVE-2026-33017: Langflow's flow_id Authorized. The data Parameter Ran.. Langflow's product is a server that exec()s user-authored Python components. The exec() call inside prepare_global_scope is not a bug; it is the runtime. CVE-2026-33017's data parameter is one arrival channel for code that reaches that runtime. The 1.9.0 patch declines to remove the parameter and instead pushes a source_flow_id argument through the build pipeline so create_graph ignores caller-supplied flow data. The vulnerable behavior is what the component does. Removing it would mean removing the reason build_public_tmp exists, which is to let unauthenticated visitors run shared flows. The patch closes the call path; the primitive (an HTTP-reachable server that compiles and runs caller-named Python in component construction) is unchanged.

CVE-2025-8061: LnvMSRIO Does What Its Name Says. Lenovo's 3.2 driver fixes the access control. The 3.0 and 3.1 binaries that shipped without the gate remain WHQL-attested, code-signed, and loadable on any Windows system that has not enabled the vulnerable-driver blocklist. The vendor's remediation reaches only the fleet the vendor's update pipeline reaches; the signature reaches every Windows host that will ever exist. The primitive (a signed kernel binary that exposes physical-memory write to user mode) cannot be unsigned. The patch closes the CVE for new installs; the same binary serves as a Bring Your Own Vulnerable Driver primitive against systems that never ran a Lenovo product, and outlives the patch.

CVE-2026-34159: The Deserializer Three CVEs Have Not Patched. The RPC server's job is to deserialize attacker-controlled tensor structures from the network and execute compute graphs over them. The structures carry 64-bit data pointers; the graphs invoke memcpy as a kernel operation. The exploit primitive (the server performs a memcpy with two attacker-named addresses) is the feature seen from the wrong angle. Closing it cleanly would mean rejecting every tensor whose data field is not provably inside a known server-side buffer, regardless of which call site reached deserialize_tensor. The 2024 fix did not. The 2026 fix did not. Two CVE cycles have ended without that refactor; the third one's exploit chain works on the substrate the first two left intact.