The Vendor Disclosure Gap

This essay accompanies the public disclosure of two vulnerabilities in macOS (PING-01 and SMB-01A), both filed with Apple Security Bounty in April 2026 and both confirmed by Apple with a "Fall 2026" fix timeline. It examines the implicit contract between security researchers and vendors, describes what happens structurally when that contract is honoured in letter but not in spirit, and sets out the reasoning behind disclosing ahead of the vendor's scheduled window. It is not a grievance. It is an account.

1. The Implicit Contract

Responsible disclosure rests on an unwritten agreement. A researcher who finds a vulnerability in a vendor's product could, in principle, sell it, publish it immediately, or sit on it indefinitely. Instead, they notify the vendor privately, hold back technical detail, and wait. In exchange, the vendor acknowledges receipt, engages with the technical substance, fixes the issue within a reasonable window, and — eventually — either credits the researcher or at minimum does not treat their restraint as an invitation to delay without limit.

The political philosopher would call this a psychological contract: a set of mutual expectations that are implicitly understood by both parties even though they are nowhere formally recorded.¹ The researcher's obligations under this contract are clear and voluntarily accepted: confidentiality, good faith, time. The vendor's obligations are less formally articulated, which is precisely where the contract breaks down.

Most disclosure frameworks describe the vendor's side in terms of process: acknowledge within N days, provide status updates, ship a fix. What they rarely describe is substance: engage with the technical argument; give the researcher a credible reason, not just a placeholder; treat the submission as an input to engineering rather than as a legal liability to be managed. When vendors honour the process while ignoring the substance, the psychological contract is technically intact and operationally broken.

2. What "Fall 2026" Means

Apple's current response to confirmed security findings is to assign them to a seasonal release cycle. "Fall 2026" means September or October 2026 at the earliest. Filed in April 2026, that is a six-month window from initial report to public patch — not for a critical zero-click remote-code-execution vulnerability, but for a local BSS write primitive in /sbin/ping and a network-reachable resource exhaustion in smbd.

Six months is not unreasonable for a complex systemic vulnerability in a shipping OS. It is not obviously reasonable for a missing bounds check that requires a one-line fix and whose exploit primitive is limited to local, unprivileged, deterministic, non-escalating state corruption. The researcher is expected to sit on technical detail for six months while the vendor decides, at their own pace, whether to move the fix to an earlier release.

The follow-up exchange on 13 May 2026, for the PING-01 case, produced this response from Apple: “We have reproduced this report and are continuing to investigate. No additional information is needed from you at this time.” This sentence is carefully constructed. It confirms that the vendor has everything they need. It does not engage with the technical argument. It does not offer a narrower timeline. It does not explain whether the Fall 2026 date is a floor or a ceiling. It closes the conversation politely and completely, from the vendor's side, while leaving the researcher in an indefinite holding state.

This is not a complaint about the individuals at Apple Product Security, who are professional and prompt in acknowledgement. It is an observation about the system in which they operate: seasonal release cycles create a structural incentive to defer confirmed bugs to the next available window rather than to ship point fixes, regardless of severity.

3. The 90-Day Norm

Google Project Zero established the 90-day disclosure deadline in 2014 after observing that indefinite vendor-controlled windows were being abused to delay fixes for years.² The 90-day limit is not an arbitrary number: it is long enough for a competent engineering team to produce a fix for most vulnerability classes, and short enough to prevent the normalization of permanent researcher silence as the default outcome.

Project Zero's data, published annually, shows that the 90-day standard works: the median fix time for vulnerabilities disclosed under a deadline is substantially lower than the median fix time under indefinite "responsible disclosure" norms.³ The deadline is not punitive; it is calibration.

Apple has responded to the 90-day norm by generally meeting it — when the researcher is Google or a well-resourced team that will publish regardless. The treatment of independent researchers is less consistent. The bounty programme creates a financial relationship that the vendor can use to manage disclosure timing: a researcher whose bounty is "pending review" has a direct financial incentive not to publish, because publication may affect the bounty determination. This is not a conspiracy. It is a structural alignment of incentives that the vendor benefits from and the researcher bears the cost of.

4. The Two Case Studies

The two vulnerabilities disclosed alongside this essay illustrate the gap at different points on the severity spectrum.

PING-01 — /sbin/ping -G sweepmax

PING-01 is a missing bounds check. -G sweepmax lacks the validation that the adjacent -s flag has. The fill loop writes beyond the end of a 65,535-byte global array, overwriting adjacent BSS globals in a deterministic, byte-precise pattern. The socket file descriptor corruption at offset +128 is empirically confirmed: a specific sweepmax value produces a specific observable exit code, invariantly, across runs.

The fix is one line, symmetric to the existing -s guard. Apple confirmed reproduction on 16 April 2026, eleven days after the initial report. Apple asked whether an exploit primitive beyond state-corruption could be demonstrated. The researcher provided byte-precise analysis. Apple replied: "Thanks for the additional information. We will further review." Twenty-seven days later, on 13 May 2026: "We have reproduced this report and are continuing to investigate. No additional information is needed from you at this time." Bounty: "Pending review."

SMB-01A — smbd FSCTL_SRV_COPYCHUNK

SMB-01A is a specification non-conformance. Apple's smbd does not enforce any of the three limits that MS-SMB2 §3.3.5.15.6 requires: MaxChunkCount (256), MaxChunkSize (1 MiB), MaxDataSize (16 MiB). An authenticated SMB session can send a 256-byte IOCTL request that drives up to 64 GiB of disk I/O. The amplification ratio is the defining feature: 256 bytes in, up to 64 GiB out.

Apple upgraded the case to "In progress" on 25 April 2026, eight days after the initial report. No further communication occurred before 13 May 2026. Bounty: not yet assigned to a band.

26 days is shorter than the 90-day norm. The researcher acknowledges this and sets out the specific reasoning in the disclosure document. The short interval reflects the combination of: vendor confirmation already received; immediate mitigations available to operators; conditional attack surface (non-default configuration required); and the availability of that mitigation guidance being the primary public-interest argument for disclosure. A reader who disagrees with the specific judgement is entitled to; the reasoning is published for that purpose.

5. The Incentive Misalignment in Bounty Programmes

Security bounty programmes create a financial relationship between vendors and researchers. This is net positive: they fund independent security work and create a formal channel for disclosure. They also create a structural tension that is rarely discussed openly.

A researcher whose bounty is "pending review" is financially incentivised to remain quiet. Publication changes the calculus in ways the researcher cannot fully predict: it may be treated as a condition that reduces the award; it may be cited as justification for declining to pay. Apple's bounty terms do not explicitly state either, which means the researcher operates in deliberate uncertainty. Deliberate uncertainty is a disclosure-management tool.

The researcher in these cases has chosen to publish despite the pending bounty. This is not because the money is unimportant. It is because the alternative — treating the bounty as an implicit non-disclosure agreement with no stated end date — is worse for the field than the financial cost of potential non-payment. If bounty programmes routinely defer confirmed-bug payments until after patch ship, and patch ship is six months away, and disclosure before patch ship affects payment, the effective non-disclosure period is vendor-controlled and indefinite. That is not a bounty programme. That is a hush arrangement with a variable payout.

This critique applies to the structure, not to the individuals at Apple Product Security. The individuals are operating within a system whose incentives do not align with researcher interests. The system is what needs examining.

6. The Researcher's Calculus

The decision to publish ahead of a vendor's scheduled window is a specific judgement, not a general principle. The factors the researcher weighed in this case:

The researcher does not assert that this calculus is universally applicable. These are specific judgements for specific bugs in a specific window. Someone with a different risk model, a different view of the operator population, or a different level of confidence in Apple's fix timeline would weight these factors differently and might reach a different conclusion. That is legitimate. The point of publishing the reasoning is to allow readers to audit it.

7. What Good Vendor Behaviour Looks Like

This is not a counsel of despair. Some vendors handle disclosure well, and the contrast is instructive.

The OpenBSD project does not have a formal bounty programme. It does have Theo de Raadt, who replies to bugs@openbsd.org submissions within hours, in plain technical language, with a clear answer: this is intended behaviour and here is why, or this is a bug and here is the commit. The researcher knows where they stand. There is no ambiguity about what the vendor is doing with the report. The psychological contract is not a six-month vague promise; it is a conversation.

Google Project Zero's self-imposed 90-day standard is the most influential positive norm in the field. It works because it is reciprocal: the researcher commits to 90 days; the vendor knows that 90 days is the window; both parties treat it as a real constraint. The deadline is not the point. The commitment is the point.

What better vendor behaviour looks like, concretely:

• A named date, not a season. "We are targeting the 15 July point release" is a commitment; "Fall 2026" is not.
• Engagement with the technical argument, not just acknowledgement of receipt.
• Explicit statement of whether disclosure ahead of the fix date affects the bounty determination.
• A process for moving simple fixes to earlier releases when the severity and fix cost justify it.
• Default to the 90-day norm. Where the vendor needs more time, request it explicitly, with a reason and a new date.

None of this is difficult. Most of it is communication discipline. The gap between current practice and better practice is not technical; it is organisational.

8. Conclusion

The vulnerabilities disclosed alongside this essay are limited in scope. Neither is a headline finding. Both are confirmed. Both have a vendor fix scheduled. The researcher chose to publish because the public-interest argument for disclosure — operator mitigations, independent verification, the analytical record — outweighed the harm risk of disclosure in these specific cases, and because waiting for a vendor-controlled endpoint with no committed date is not a condition of responsible disclosure. It is a condition of compliance.

The security research community funds vendors' security work for free, voluntarily, in good faith. The vendors that understand this invest in reciprocal good faith: clear timelines, technical engagement, transparent processes. The vendors that treat researcher patience as an inexhaustible resource will, in time, find it exhausted.

This is not anger. This is a record.