//nefariousplan

Disclaimer Wrapped Campaign Kit

A PoC that ships a full weaponizer behind a 'for authorized testing only' disclaimer.

The convention for responsible security research has a shape. A researcher finds a vulnerability, writes a proof-of-concept that demonstrates the mechanism, publishes it with framing that makes clear which parts have been defanged and which remain live. The disclaimer in the README says "this is for authorized testing only" and "we have removed the weaponized stage so that only legitimate defenders can use this." Downstream readers, including other researchers, defenders, journalists, and legal teams, take the disclaimer at face value.

This pattern is the gap between that framing and the code actually in the repository. The disclaimer claims defanging. The code, read mechanically, performs the thing the disclaimer says it does not. The research advantages the researcher's career by publishing first. The defender's picture is the researcher's preferred narrative, not the mechanism. Attackers read the code. Attackers find what is still live. The disclaimer protected the researcher, not the users.

Mechanism

The pattern depends on a specific asymmetry in reading practice. README text is prose, consumed linearly, fast, framed by author intent. Source code is mechanical; its behavior is the behavior regardless of comments or variable names. Attackers read source code for what it does. Defenders, journalists, incident responders, and other researchers often read the README first and the code not at all, because the code is long and the README is short and the researcher is credentialed.

When a PoC's README says "this does not perform X" but the code does perform X, the two readerships end up with different versions of what the vulnerability is. The attacker knows it is the full chain. The defender's threat model is bounded by the README. The detection engineering, the patch prioritization, the incident response runbook, all of these are built against the narrower description. Attackers are operating against the broader one.

The mechanism does not require malice from the researcher. The disclaimer may be an honest statement of intent, and the code may perform past that intent because of timing pressure, incomplete defanging, or overlap between legitimate test flows and weaponized flows. It may also be a deliberate hedge, where the researcher preserves the capability for their own use while satisfying the appearance of responsibility. The defender's exposure is the same either way. What matters is that the disclaimer and the code disagree, and the disagreement travels in the direction that benefits attackers.

Exhibits

CVE-2026-34621: Adobe Acrobat's Privilege Gate Inherits What It Checks. A PoC shipped with a prominent disclaimer about "not actually escalating privileges" and "intentionally defanged for responsibility reasons." The code, read against the disclaimer, performs the exact escalation the disclaimer claimed it omitted. The banner prints before the script parses its own arguments, asserting the safety claim before any defanging could even theoretically have occurred. The post walks through the specific mechanical behavior of the PoC, naming the stage that the disclaimer said was withheld and showing it running. The researcher's framing and the code's behavior are operating on different levels, and the defender who read only the README would have missed the primitive the attackers are using.

Exhibits

CVE-2026-34621: Adobe Acrobat's Privilege Gate Inherits What It Checks. A PoC shipped with a prominent disclaimer about 'not actually escalating privileges' and 'intentionally defanged for responsibility reasons.' The code, read against the disclaimer, performs the exact escalation the disclaimer claimed it omitted. The banner prints before the script parses its own arguments, asserting the safety claim before any defanging could have occurred. The post walks the specific mechanical behavior of the PoC, names the stage that the disclaimer said was withheld, and shows it running. The researcher's framing and the code's behavior are operating on different levels.

Boundaries

Not every PoC with a disclaimer. Many disclaimers accurately describe the code's limits. A researcher who publishes a crash-only PoC and says "this is crash-only, stage-two is withheld" is an honest narrator; the code matches the framing. The pattern is not about the existence of disclaimers. It is about their mismatch with behavior.

Not every aggressive PoC. A weaponized exploit published without any safety framing is an honest artifact; the reader knows what they are looking at. The specific harm of this pattern is the LIE embedded in the disclaimer that defenders act on. An aggressive PoC without camouflage is a different problem (or arguably not a problem at all, depending on disclosure norms).

Not every intent-vs-impact gap. A PoC written to target X that happens to also affect Y because of shared machinery is not this pattern; that is scope creep in analysis, not stagecraft. The pattern specifically describes cases where the PoC's OWN CODE performs the behavior the disclaimer says it omits. The gap is inside the artifact, not in the environment.

Defender playbook

Read the code, not the README. For any PoC that will inform your defensive work (detection signatures, patch priority, incident response runbooks), the README is framing. The code is mechanism. The mechanism is what your defenders will face in the wild.

When a PoC ships with a defanging claim, treat that claim as an assertion to verify, not a premise to build on. Run the PoC in a sandbox with full observability. Compare the observed behavior against the README's description. If they diverge, note the specific divergence; that is the information the researcher did not volunteer.

Build detection and response against the code's behavior, not the README's severity framing. If the code performs stage-two, your signatures need to match stage-two indicators whether or not the README admits stage-two is present. Defenders building against the narrower framing are the population this pattern is designed to reach.

When reporting or forwarding a PoC analysis, state explicitly what the code does versus what the framing says it does. The habit of naming the mismatch in every writeup raises the reading standard across the community. Treating disclaimers as load-bearing lets the next wrapped PoC work the same way.

Treat the pattern as inventory, not as a one-off. Disclaimers are a recurring stagecraft move; the next PoC with a prominent safety claim is already in someone's draft repo. Your review pipeline should have "verify the defanging claim" as a standing step, not a reaction to a specific incident.

Kinship

Commented Out Code Is Testimony. Sibling reading skill. Both patterns live in the gap between what the artifact claims and what the artifact does. Commented-out code is testimony about what the researcher CHOSE not to ship. Disclaimer-wrapped campaign kits are testimony about what the researcher shipped while claiming not to. Reading both artifacts mechanically, against their own framing, is the same discipline.

Content Is Command. Related at the artifact level. The README is content; the code is command. When the content says one thing and the command does another, the interpreter (human readers relying on the README) is being misled by content while the mechanical interpreter (the runtime) is following command. The attack surface is exactly the reader whose threat model is built on the content rather than the command.

Disclosure After Exploitation. Downstream consequence. When PoCs hide their real capability inside disclaimers, the defenders take longer to form an accurate threat model, and attackers who read the code are already operating inside that gap. Disclaimer-wrapped campaign kits extend the disclosure-after-exploitation window by under-informing the defensive community while attackers have the full picture.

The disclaimer is the cover. The code is the confession.