Why is fixing a reported security bug in a normal public pull request a disclosure?
answer
- the fix explains the flaw
- public history is read instantly
- users are not upgraded yet
- message, linked issue, new test
- attackers derive exploits from patches
basics
~20 sBecause the patch describes the bug. A public diff, its commit message, linked issue and new test show an attacker exactly what was broken and how to trigger it, while every user is still running the unfixed version.
solid answer
~40 sA fix is a description of the flaw written by the person who understands it best. The moment it lands in a public repository the diff is readable, and public history is mirrored and indexed by bots within seconds, so "nobody will notice for a few days" is not a real assumption. The commit message, a linked issue, and a regression test that reproduces the flaw make it easier still. The dangerous part is the gap: between the public commit and the released, upgraded version, an attacker can derive a working exploit against a population that has no fix available. That gap is what people mean by *patch gapping*. So an embargoed fix is prepared out of public view and lands at release time, together with the advisory that tells consumers to upgrade.
go deeper
Be ready to say plainly that the patch itself reveals the bug, and that users stay exposed until they have upgraded, not until you have committed. Naming the commit message, linked issue and new test as extra leaks is what a good answer adds.
Explain the timing: the exposure is the interval between a readable public fix and an installable fixed release, and merging early only widens it. Be able to list the metadata around a commit that leaks as loudly as the diff.
Show that you have thought about who watches repositories and how fast, and that you can distinguish a genuinely embargoed fix from a fix that is merely undiscussed. Explain why silently shipping a security fix fails downstream consumers.
Own the policy: when the project treats a report as embargoed, who decides, and what the maintainers commit to doing between report and release. Be ready to argue when the privacy discipline should be abandoned because the flaw is already public or exploited.
## The core idea When someone reports a vulnerability privately, you now hold two things: knowledge of the flaw, and a fix. The fix is not a neutral artifact. **A patch is a precise, expert description of the bug** — it shows the exact function, the exact missing check, and by inversion the exact way to trigger it. Publishing the patch publishes the vulnerability. That would still be tolerable if publishing the patch also protected everyone. It does not. Users are protected by *running a released, upgraded version*, and that happens hours, days or months after a commit lands. Between those two moments, everybody is exposed and the exploit recipe is public. This asymmetry is the whole reason embargoed fixes are prepared privately. ## Who is actually reading your commits Maintainers routinely underestimate this. A public repository is not a quiet place: - Mirrors and archive bots clone or sync new commits continuously — often within seconds of a push. - Commit feeds, notification emails and activity streams fan the diff out to anyone watching the project. - Researchers and attackers both run tooling that watches security-relevant repositories specifically for suspicious-looking commits: a bounds check appearing in a parser, a new allow-list, a type check added to a deserialization path. Consider a widely used framework with a deserialization flaw. A single commit adding a class allow-list to the object-reading path is not subtle. An anonymous observer with no access to your issue tracker, no relationship with you, and no knowledge of the report can read that diff, infer the pre-patch behaviour, and build a working attack against every deployment still on the previous release. ## The gap that gets exploited The window between a public fix and widespread upgrade is the exposure. Practitioners call deriving an exploit from a published fix **patch gapping**, and it is a normal, industrialised activity — it is often cheaper to read a fix than to find a bug. Everything you do around an embargoed release is aimed at making that window as small as possible and at making sure that when it opens, the remedy already exists. This also explains a rule that surprises newcomers: *an unreleased commit is still public*. Merging early and tagging later does not buy safety; it does the opposite, because it maximises the gap. ## What leaks besides the diff itself The code change is the loudest signal, but rarely the only one: - **The commit message.** "Fix RCE in the config parser" removes any need to read the diff at all. - **A linked issue or ticket.** Even a private link's *title* often appears in public metadata, and a public issue closed at the same moment is a pointer. - **The regression test.** A test that reproduces the flaw is frequently a working proof-of-concept with a nicer name. - **Milestones, labels and release-note drafts** that mention a security fix scheduled for the next version. - **CI output.** A build log, a failing-then-passing test name, or a pre-release artifact published to a publicly readable channel. ## What you do instead The fix is developed where the public cannot see it — a private fork or private mirror with a small, explicit set of people — and it becomes public at the same moment the fixed release is available to install, alongside an advisory that names the affected versions. The commit message is written to be uninformative before release and honest after it; the regression test is written so it proves the invariant without shipping a ready-made payload, or it lands with (not before) the release. ## The tempting wrong answer: fixing silently A related mistake is to ship the fix in a normal release and simply never say it was a security fix. This is worse than it looks. Attackers diff consecutive releases as a matter of routine, so the flaw becomes known anyway — just to them, and not to your users. Meanwhile downstream consumers have no signal that this particular upgrade is urgent, automated tooling has no version ranges to match against, and organisations that must justify an out-of-band deployment have nothing to point at. Quietly fixing protects the maintainer's reputation for a while and nobody else. ## When the calculus changes If the flaw is already public — posted to a forum, exploited in the wild, or described in a paper — the reason for privacy is gone and speed dominates: get a fix out and tell people plainly. The private-preparation discipline exists to protect users during the period when *only you and the reporter* know, and it stops mattering the moment that stops being true.
- If the commit is quiet enough, can you just ship it and never mention it was a security fix?No. Attackers routinely diff consecutive releases, so the flaw becomes known to them regardless. Your users get no signal that this upgrade is urgent, automated dependency tooling has no affected ranges to match, and teams that need justification for an out-of-band deployment have none. Silent fixing hides the problem from defenders far more effectively than from attackers.
- The regression test proves the fix works. Why is that a leak too?Because a test that reproduces the flaw is usually a working proof-of-concept with a friendlier name — the malicious input, the crafted payload, the trigger sequence. Either write it to assert the correct behaviour without embedding a usable exploit, or hold it back so it lands with the release rather than ahead of it.
- Does merging the fix but delaying the release tag make it safer?It makes it worse. The commit is public from the moment it is pushed, so delaying the tag widens the window in which the exploit recipe is available and no fixed version exists to install. Time between public fix and installable release is exactly the exposure you are trying to remove.
Repairing the broken lock on a shared building's back door and posting a photo of the repair. Anyone who sees it now knows which door was open, and every neighbour who has not yet replaced their own lock is worse off than before.
saying these in an interview costs you the question
- Assumes nobody reads commits on a small project
- Thinks an unreleased commit is not yet public
- Believes a vague commit message alone is sufficient
- Says fixing silently protects users
- Treats the regression test as harmless