pattern·published·25 exhibits

The Detector Is The Target

The sandbox, scanner, or SOC tool is itself the attack surface.

A sandbox is a machine you paid money to put on your network because it was supposed to detonate bad things safely and tell you what they were. It ingests anything a file or email or URL can carry. It runs the code. It exposes an API for other tools to query what it found.

Each of those properties is also a feature an attacker wants. Unrestricted input channel. Privileged execution environment. Ready network adjacency to everything else in the security fabric. The detector was built assuming its inputs would be hostile. The detector itself was not modeled the same way.

Mechanism

Detection tooling has a structural handicap. To find threats, it must accept inputs no other part of the network will accept: executable files, unknown file formats, network traffic from the worst neighborhoods, scripts pulled from phishing emails. To analyze those inputs, it must parse them. Parse implementations have bugs. Parse implementations at the edge of file format weirdness have concentrated bug density. The detector parses the worst inputs with the most complex code and runs with enough privilege to do meaningful analysis. That is a vulnerability profile most products would never be allowed to have.

The pattern: an attacker does not try to evade the detector. The attacker submits a crafted input that exploits the detector itself. The detector ingests as designed. The exploit fires on the ingestion path. The attacker now has code execution inside the detection infrastructure, with the detection infrastructure's network position, with the detection infrastructure's implicit trust across every tool in the security fabric that queries it.

What makes this pattern specific is the INVERSION of role. A normal vulnerability in a normal product is a problem for the users of that product. A vulnerability in a detector is a problem for the people the detector is supposed to protect. The blast radius is inverse to the customer's intent: the more they trusted the tool to find threats, the more access they gave it, the more the vulnerability pays out.

Exhibits

CVE-2026-39973: Apktool's Path Check Was Replaced With a Name Check. The Path Has Two Names.. Apktool extends this pattern from the appliance to the developer laptop. The pattern's published exhibits, FortiSandbox, vm2, radare2, Zabbix's audit log, sit at the network-positioned end of the spectrum: boxes whose role obligates them to accept hostile input. CVE-2026-39973 is the same shape at a different rung. The user of apktool d is, by occupation, looking at bytes they do not trust. The decoder's job is to make sense of those bytes. The path concat that writes the result is the input path the malicious APK reaches the analyst's home directory through. The blast radius is a single workstation rather than a security fabric, but the prerequisite is also smaller: one malicious sample on disk, one apktool invocation, and the analyst's ~/.bashrc belongs to whoever crafted the resources.arsc. The pattern's mechanism_md notes "the detector parses the worst inputs with the most complex code"; Apktool's resources.arsc parser, two attacker-controlled string pools deep, is the most complex code in the ingestion path.

CVE-2024-22120: Zabbix's Audit Log Is the Read Primitive. The audit log is the SOC tool. It records what every user did, when, and from where. Its database connection necessarily holds SELECT on every table the system might audit, which is every table in the schema. CVE-2024-22120 routes a low-privilege user's SQL through the audit-writer's connection by way of the unsanitized clientip column in the audit-log INSERT. The detector's necessary privilege becomes the attacker's read across sessions and config. The pattern's specific shape: the SOC tool is the attack surface because the SOC tool's privilege is broader than the privilege of the user it is recording.

CVE-2026-39808: One curl to Root on the Box That's Supposed to Catch Malware. FortiSandbox is a malware analysis appliance. Its job is to receive suspicious files, detonate them, and report verdicts. A pre-auth RCE on the box means that anyone who can reach its submission interface can run code on the appliance itself. The attacker does not need to evade detection. The attacker needs to submit a sample that exploits the submission endpoint. The sandbox's role, the thing that makes it valuable to the defender, is exactly the attack surface.

CVE-2026-0300: seven PoCs, four defenders, two placeholders, one missing patch. The honest half of this PoC ecosystem is detection tooling pointed at the appliance it is meant to defend: TailwindRG's audit walks the live config from a Panorama API key (and concedes PAN-OS has no read-only XML-API role to do it safely), mr-r3b00t's honeypot impersonates a vulnerable PAN-OS captive portal down to the O=Palo Alto Networks cert and the JA3 capture, shizuku's survey probes the same /php/login.php path the exploit stubs POST to. Every defensive artifact here is built by standing where the attacker stands and looking at the same port — the detector and the target are the same box, reached the same way.

CVE-2026-40517: fN Was the One r2 Command That Skipped the base64 Envelope. radare2 is a reverse engineering framework whose users are, by occupation, the people who load binaries from sources they do not trust. The idp command is in the muscle memory of every Windows malware analyst working from a PE sample plus its symbols, and the symbol file is exactly the channel an attacker controls when they ship the binary. CVE-2026-40517 is the-detector-is-the-target with the detector being the analyst's r2 instance and the input being the PDB file paired with the sample; the pattern's mechanism_md says "the detector parses the worst inputs with the most complex code," and radare2's PDB parser, the binary backend's most variant-rich format, fits. The patch closes this CVE on the fN realname slot. It does not address the broader exposure that every RAD-mode cb_printf in libr/bin/ is the same kind of bridge from attacker-controlled file bytes to defender-side command execution.

TeamPCP Came for the Scanners. A campaign that specifically targeted the security tooling deployed across enterprises. The scanner agents, running with deep read across every repository, every endpoint, every artifact, were the payload delivery mechanism. Once the attacker reached the scanner infrastructure, they inherited the scanner's reach. The defender's investment in coverage became the attacker's coverage.

CVE-2026-24118: vm2's Patch Names Its Sibling. resetPromiseSpecies Was 2023.. vm2's product is "run untrusted JavaScript safely in-process." Its only input shape is attacker-influenced code, by definition. CVE-2026-24118 is the input shape doing exactly what the input shape is documented to do: a few lines of sandbox JavaScript that walk a prototype chain, install a self-returning species function, and trigger one r.map(f) to write raw host references into a sandbox-visible array, with the bridge's mediation routed around. Every property of the tool that makes it useful (executes caller code, exposes host built-ins, mediates through a Proxy) is the surface this CVE exploits. The README's "New bypasses will likely be discovered in the future" sentence is the maintainer's acknowledgment that the threat model and the input model are the same model, written down twice.

CVE-2026-24120: vm2's README Already Admits the Bug Class Is the Design. vm2's entire reason to exist is to detect and contain malicious sandboxed code. CVE-2026-24120 turns the detector into the target: a vm2 customer's normal input, vm.run(\"<user code>\"), returns shell execution on the host via err.constructor.constructor('return process')().mainModule.require('child_process').execSync(). The README acknowledges this directly under "Important Security Disclaimer" and recommends isolated-vm, Worker threads, or containers as "more robust alternatives." The library's own documentation tells callers not to use the library against the threat model the library was written for.

Boundaries

Not every vulnerability in a security product. A memory corruption bug in the admin UI of an EDR is a vulnerability in a security product, but the exploit path requires an authenticated admin. The-detector-is-the-target specifically describes the case where the DETECTION ROLE ITSELF is the attack surface: the input path the tool accepts because it is supposed to.

Not every EDR abuse. EDR bypasses are about the attacker avoiding the detector. The-detector-is-the-target is about the attacker using the detector. The distinction matters for investigation: when a security product misses a known-bad thing, that is coverage failure. When a security product executes the known-bad thing as its OWN process, that is this pattern.

Not general supply-chain compromise of the vendor. A signed-update attack that puts attacker code into the EDR binary is a different pattern. The-detector-is-the-target describes vulnerabilities in the detector's normal operation, not in its provenance. The tool is running the official build. The official build has the bug.

Defender playbook

Treat your detection fabric the way you would treat your crown-jewel systems. The sandbox is a machine with more input exposure than any production server and more network reach than most of them. Segment it accordingly. The default posture of putting the sandbox in a flat management network is a bet that the sandbox has no bugs. The house does not always win.

Audit what your detection tools accept and from whom. A sandbox that accepts submissions from the entire corporate email gateway has a submission channel connected to every user's inbox. Narrow the channel, rate-limit it, log it. The attacker's prerequisite is getting a sample in front of the detector. Making that non-trivial buys time.

Monitor the detectors' outbound traffic. A compromised sandbox that is calling home is easier to notice than a compromised sandbox that is sitting quiet. Detection agents rarely need broad egress. Policy that treats detection egress as suspicious by default catches a meaningful fraction of post-exploitation.

Do not let the detection team own its own unmonitored enclave. Security tooling is often deployed with "the security team needs admin, give them admin." That is how you end up without logs of the security team's traffic. The profile of a sophisticated attacker inside your network is structurally similar to the profile of a SOC engineer running a legitimate investigation. Both must be logged the same way.

Model the detector as a potential malware platform with authorized running privileges. Ask what it could do if the attacker reached its command interface. The answer is usually a list you do not want to read. Treat that list as your exposure, then work backward from there.

Kinship

Security Tool As Primitive. Parent pattern. Security-tool-as-primitive is the broader category: any defensive tool becoming attacker-controlled via its own privileges. The-detector-is-the-target is specifically this applied to detection tooling, where the input path is the dangerous primitive.

Content Is Command. Detectors are interpreters by occupation. A file submitted for analysis gets parsed by the detector's engines. If the parser reads attacker content as command, the detector is the first system to execute the attacker's code. Content-is-command against a detection tool is how this pattern most commonly lands.

Trust Inversion. The detector inverts trust when compromised: the tool your team trusts to surface threats is now surfacing the threat at them. The detector's outputs are believed by downstream tools and analysts, and a compromised detector can weaponize those outputs.

Your detector is the one component in your stack that is required to accept hostile input. Model it as if hostile input sometimes wins.