The Vendor Disclosure Gap

This essay accompanies the public disclosure of three vulnerabilities in Apple platforms: MAILDROP-01 (filed July 2023, disclosed May 2026 — thirty-four months later); PING-01 (filed April 2026, disclosed forty days later); and SMB-01A (filed April 2026, disclosed twenty-six days later). 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. The thirty-four-month case is what made the forty-day decision possible. 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. Three Case Studies

The three vulnerabilities disclosed alongside this essay sit at very different points on the severity, urgency, and time-elapsed axes. Reading them in chronological order — the long one first — is the right way to see what changes when a vendor stops engaging.

MAILDROP-01 — Apple Maildrop unsigned parameters (the long case)

MAILDROP-01 was filed with Apple Security Bounty on 7 July 2023 (vendor reference OE1950888220). The finding: the per-attachment URLs that Apple's Maildrop service generates carry three unsigned, client-controlled parameters — f= (filename), sz= (file size), and a template substitution that interpolates ${f} directly into the CDN download path. Any party with a valid Maildrop URL can rewrite the filename, the file size, and the inferred file- type icon displayed on the icloud.com landing page. The CDN then echoes the spoofed filename through a Content-Disposition header to the recipient's browser. The result is a phishing primitive hosted on an Apple domain.

The vulnerability is straightforward. The fix is straightforward: sign the parameters, or stop interpolating user-controlled values into a path. CVSS 3.1 base score 5.4 (medium). No special tooling is required to reproduce; the proof is two URLs and a browser.

Apple's response over the following thirty-four months consisted of four status transitions on the bounty portal, the most recent being “Prioritised for review” as of 8 April 2026 — the identical status the case had carried, on and off, since 2023. No technical response. No reproduction confirmation. No fix shipped. No estimate of when a fix would ship. No clarification of what "prioritised" meant given the elapsed time. The bounty band was never assigned.

The researcher's options at the thirty-month mark were three: continue to wait indefinitely; sell the finding privately (the finding had market value); or publish. The researcher chose to publish. The case was escalated in parallel to MITRE as a root-CNA dispute — MITRE being the body that adjudicates when an authorised CVE Numbering Authority (Apple) declines to assign a CVE to a confirmed finding within reasonable time. That escalation is on the public record.

The thirty-four-month case is the canonical example of process-honoured-but- substance-ignored. The portal acknowledged. The status fields updated. The psychological contract, on the researcher's side, was kept in full for almost three years. The vendor's side was honoured in form and abandoned in substance. What MAILDROP-01 demonstrated — not as theory, as case — is that the vendor's "Fall 2026" timeline on PING-01 and SMB-01A could plausibly be no timeline at all. The researcher's calculus on the later disclosures was made in that light.

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.

Legal note

This essay is published under the Defamation Act 2013 facts-and-opinion convention. Statements of fact — dates, vendor-portal status transitions, quoted vendor responses, technical details of the three vulnerabilities — are accurate to the best of the author's knowledge and are evidenced by the author's contemporaneous correspondence with Apple Security Bounty and by the public-record CVE / MITRE escalation documentation. Where any fact has been described inaccurately, the author will correct it; please email stuartpaulthomas@gmail.com.

Statements of opinion — characterisations such as "the psychological contract is operationally broken", "deliberate uncertainty is a disclosure- management tool", "honoured in form and abandoned in substance" — are the honestly-held views of the author, identified as opinion, and based on the cited facts. They are protected by the honest-opinion defence under s.3 of the Defamation Act 2013.

The subject matter of this essay — the ethics of coordinated vulnerability disclosure between independent researchers and a major platform vendor — is a matter of legitimate public interest under s.4 of the Defamation Act 2013. The essay is published in good faith on that basis.

No individual employee of Apple Inc. or any other party is named or identified in this essay. Criticism is directed at process, terms of programme, and publicly-attributable corporate statements — not at any natural person. Apple Product Security personnel are described, where mentioned, as "professional and prompt in acknowledgement", which is the author's honest experience of them.

All three disclosed vulnerabilities have been independently verified by the author on hardware owned by the author. No third-party systems were accessed in the course of the research. The research was conducted within the scope permitted by the Computer Misuse Act 1990 (England and Wales) own-hardware exemption. The author asserts no claim of negligence, recklessness, or bad faith against Apple Inc.; the essay's claim is the narrower one that the disclosure-process incentive structure produces predictable researcher-side costs that warrant public discussion.