pattern·published·1 exhibit

Commented Out Code Is Testimony

The capability the researcher didn't ship tells you what the capability is. Read what's commented out.

Security research artifacts contain more than they execute. A PoC that demonstrates privilege escalation also contains, scattered through the source, comments about what else was possible. Lines that start with a pound sign or a double slash and read like "uncomment for full exploit" or "stage two omitted for responsibility" or "original version had keylogger here." The runtime ignores those lines. The researcher did not.

The commented-out sections are a contemporaneous record of what the researcher believed was achievable, considered shipping, and chose to withhold. They are the best available evidence of the real capability of the technique, because they were written by someone who had just finished proving it. Readers who look only at what the code does miss half the artifact. Readers who read the comments are reading the researcher's own threat model in their own words.

Mechanism

The pattern depends on a specific production dynamic in security research. A researcher working through an exploit chain writes code that does the full thing first, because writing the defanged version from scratch is harder than writing the full version and then removing parts. The full version is tested, works, confirms the hypothesis. Then the researcher prepares the artifact for publication. The responsible move is to remove the weaponizing parts. The fast move is to comment them out.

Commented-out code is a version of removal that is operationally the same as removal (the runtime never sees it) and editorially different (the capability is still present in the text). The researcher typically tells themselves "this is fine, nobody reads comments, and it makes the history clear to maintainers." Attackers read the comments. Other researchers read the comments. The comments persist across forks, across archive mirrors, across eventual rewrites. The capability stays in the artifact as information even when removed from execution.

The pattern is not specifically about malice. Researchers commenting out stage-two code are often trying to do the right thing while preserving the technical completeness of their work. The defender's exposure is independent of intent. The commented code tells the defender what the technique can do at full capability. That is the threat model defenders need, and it is the threat model attackers already have, and it is hiding in plain sight.

Exhibits

BlueHammer: What the Researcher Commented Out. The PoC repository included extensive commented-out sections that, read against the live code, mapped the full weaponizer. The live code demonstrated the hardware effect at a research-grade level. The commented code filled in the missing steps: the targeting logic, the timing refinement, the cleanup stage, the conditional that distinguishes "this is a test" from "this is a real run." Read as a single document, the live code plus the commented code is the complete attack. Read as a publication artifact (live only), it is a responsible demonstration. The post walks through specific commented sections and names what they were for. The capability was always there.

Exhibits

BlueHammer: What the Researcher Commented Out. The PoC repository included extensive commented-out sections that, read against the live code, mapped the full weaponizer. Live code demonstrated the hardware effect at a research-grade level. The commented code filled in the missing steps: targeting logic, timing refinement, cleanup stage, the conditional that distinguishes 'this is a test' from 'this is a real run.' Read as a single document, the live code plus the commented code is the complete attack. Read as a publication artifact (live only), it is a responsible demonstration. The post walks through specific commented sections and names what they were for.

Boundaries

Not every commented-out code is this pattern. Most commented code in any codebase is debug prints, TODO notes, alternate implementations kept for reference, or rollback safety during refactoring. The pattern specifically requires that the commented code represents a CAPABILITY the researcher chose to withhold from publication while keeping it in the artifact's text.

Not every incomplete PoC. A PoC that a researcher explicitly describes as partial, with notes about what is not yet working, is an honest artifact; the reader knows what they have. The pattern describes the case where the published framing (README, blog post, conference talk) implies a narrower capability than the artifact, read comments-included, actually documents.

Not every code comment. This is a reading skill focused on deliberate withholding. A comment like "// TODO: add rate limiting" is development hygiene, not testimony. A commented-out block titled "// uncomment for full exploit" or a stage that matches the researcher's stated "withheld for responsibility" stage is the testimony the pattern is about.

Defender playbook

Read the full source, including comments, for any PoC you intend to inform defensive work. Your detection signatures, your incident runbooks, your severity estimates should all be built against the complete capability the artifact documents. Reading only the runtime behavior under-estimates the full reach of the technique.

Look for specific language. "Uncomment for full exploit." "Stage two omitted." "Intentionally removed before publication." "Original version had X here." "Not shipping this." These phrases are where researchers tell you what they chose to withhold, which is to say, what they believe is possible.

Diff PoC repositories against each other and against their forks. A commented-out capability in version N may be active in version N+1 (an attacker's fork), or moved to a private branch, or recoded differently. The diff is where the full capability crystallizes.

When writing your own public artifacts, delete, do not comment. If you are removing something for responsibility reasons, the removal should be visible by diff only, not by reading the shipped file. Commented-out responsibility-removed code is the exact pattern this essay is about, and writing it yourself is the single most traceable way to produce the next instance.

Treat the pattern as a general reading discipline, not a one-off advisory. Every PoC you read in 2026 and 2027 should be inspected with this lens. The pattern is not rare; it is the default production mode of security research under time pressure, and it keeps producing the same defender-blinding effect.

Kinship

Disclaimer Wrapped Campaign Kit. Immediate sibling. Both patterns live in the gap between what an artifact claims and what the artifact, read mechanically, documents. Disclaimer-wrapped kits have the lie in the README text. Commented-out-code-is-testimony has the evidence in the source file itself. Reading both artifacts against their own framing is the same discipline, applied at different layers of the publication.

Todo That Shipped. Adjacent but different angle. Todo-that-shipped is about code comments that document unfinished work in a shipped product; the comment is evidence that a fix was planned but not written. Commented-out-code-is-testimony is about research artifacts where the capability was finished and deliberately withheld. Both patterns depend on reading comments as primary source material.

Content Is Command. Inverse relationship. Content-is-command describes attacker-controlled content that becomes command at an interpreter. Commented-out code is the opposite shape: the content does not execute, and precisely that non-execution is what makes it informational. The runtime's refusal to interpret the comment is why the text stays revealing.

Comments are testimony. Read them like evidence.