pattern·published·1 exhibit

Todo That Shipped

The fix was in a comment. The code shipped without it. Audit your oldest TODOs.

There is a comment in the codebase that names the fix. The comment says, in some form, that the code below needs validation, or escaping, or a length check, or a type guard. The comment has been there for years. The code has been there for the same years. The fix has not.

A security researcher finds the comment. The comment is the researcher's map. It tells them what the original author knew was wrong, and what the original author never got around to doing. The researcher writes the exploit that targets the exact gap the comment documents. The CVE that follows reads like a sentence the codebase wrote about itself, long before the exploit existed.

The pattern is the TODO that shipped. Not as a stylistic annoyance. As a published record of a known vulnerability that the project chose to leave in place.

Mechanism

A TODO comment is contemporary documentation. Someone who understood the code well enough to write the function also understood its gap well enough to name the gap. At the moment of writing, the author knew what was missing. They chose to ship without it. The decision may have been deliberate (ship now, fix in a follow-up) or accidental (the follow-up never happened, the person left, the codebase lost the context).

The shape this pattern describes is the case where the comment's claim is a security-relevant property: input validation, authentication, escaping, bounds checking, type guarding, authorization. If the comment says "TODO: verify this path is under the base directory" and the code concatenates the input path into a filesystem call without the verify, the codebase has declared its own path-traversal vulnerability. The comment is not evidence of bad faith. The comment is testimony that the issue was seen, named, and deferred.

Attackers read commented-intentions-now-public the same way maintainers should: as a shortlist of where the code self-identifies as weak. Grepping a repository for TODO, FIXME, XXX, HACK across security-sensitive code paths is a cheap and consistently rewarding exercise. Shipped TODOs compound over time because every year of uncorrected TODO is a year of additional certainty that nobody with commit access is going to fix this one. CVE issuance for long-standing TODOs consistently reveals that the comment pre-dates the exploit by years.

The pattern is not that TODO comments exist. Every codebase has them. The pattern is that a specific TODO in a specific file describes a specific security failure that the code below the TODO performs, and the combination has shipped long enough for researchers to find it.

Exhibits

Boundaries

Not every TODO is this pattern. Most TODOs are operational: "clean up this API", "add logging here", "factor out this duplication". They name ergonomic or maintenance debts, not security properties. The pattern specifically requires that the TODO names a security-relevant control (auth, validation, escaping) AND the adjacent code operates without that control.

Not every commented-out block. Removed code that was meant to be restored and never was is a different shape, closer to commented-out-code-is-testimony (reader reads the comment for capability). Todo-that-shipped requires that no code for the named fix was ever written; the comment is the fix's only manifestation.

Not every deferred fix. Some teams mark security issues via tickets in a tracker rather than TODOs in source. A ticket that sits in a backlog for five years is the same organizational problem with a different storage location. The pattern is specifically about the in-source artifact: comments attackers can read by cloning the repository.

Defender playbook

Grep your own security-sensitive codebases for TODO, FIXME, XXX, HACK in paths that handle authentication, input parsing, filesystem operations, subprocess spawning, or template rendering. Sort by age (git blame). Anything older than eighteen months is accumulated technical debt with security implications; act on it or remove the comment with an explicit decision.

Treat a TODO next to unsafe code as a shipped vulnerability, not a note. If the code is in production and the TODO describes a control that is not in place, you have the vulnerability regardless of whether anyone has weaponized it yet. The comment is the codebase telling you it exists.

When reviewing dependencies, grep their source the same way. grep -rE 'TODO|FIXME|XXX|HACK' vendor/ is a cheap audit that consistently surfaces latent issues in libraries you depend on. Upstream a fix or plan a migration before the library's own CVE makes the decision for you.

Do not accept "that's from the previous team" as a disposition. Code you run is code you own. If a TODO pre-dates your tenure and the control is absent, the control is absent in your deploy. Fix it or accept it as a risk with a signed owner, but do not let it sit unattributed.

In code review, reject new commits that add a TODO next to unsafe code unless the commit also includes a ticket reference with a bounded timeline. A TODO with no owner and no date is a forever-TODO, and forever-TODOs become shipped vulnerabilities by default.

Kinship

Commented Out Code Is Testimony. Sibling reading skill. Both patterns treat comments as evidence about what the author knew. Commented-out-code-is-testimony reads what was built and withheld. Todo-that-shipped reads what was named and not built. Same discipline, different artifact.

Design Debt Driver. A codebase whose TODOs accumulate in security paths for years is a design-debt-driver in the slow sense. Each TODO is an instance. The maintenance culture that lets the TODOs shipped is the substrate. Fixing the specific TODOs is necessary; fixing the culture that produced them is the only thing that keeps new ones from landing.

Disclosure After Exploitation. Attackers who discover a shipped TODO often exploit quietly for a while before the CVE lands, because the exploit was cheap to produce and the defender had no particular reason to audit that function. The window between the TODO getting exploited in the wild and the vendor's CVE is a specific case of disclosure-after-exploitation.

The codebase wrote the sentence before the attacker did. The attacker just read the repository.