OpenAI executive says maintainers cannot answer hundreds of AI bug reports; its pages print no advice for finders

OpenAI's own counts are of patches, not of the reports maintainers say they cannot read

OpenAI's Daybreak page prints four counts side by side: 65 codebases under review, 1,885 issues identified, 661 patches produced ("targeted fixes developed and tested before maintainer review") and 458 patches accepted upstream ("fixes accepted by maintainers for inclusion in the projects they steward"). CyberScoop quoted the last two on 27 October 2026. The page prints no date and no reporting period. Derived: 458 of 661 is 69.3 per cent, 661 of 1,885 is 35.1 per cent and 458 of 1,885 is 24.3 per cent. The 203 patches not accepted (derived) are not described as rejected, pending or withdrawn. The figures count issues and patches. They do not count reports sent to maintainers or reports a maintainer refused, and they say nothing about the "hundreds and hundreds" of AI submitted vulnerability reports that an OpenAI executive said a maintainer is "just not going to respond" to.

So the headline version of this story, that OpenAI has published advice for people who file AI found bug reports, needs correcting. What exists is a spoken answer. An OpenAI executive, whom CyberScoop calls OpenAI's cyber executive in residence in its text and its Daybreak lead in its standfirst, was asked at the DataTribe Challenge in Washington on Tuesday 27 October 2026 how OpenAI's Patch the Planet programme compares with open source maintainers refusing AI based submissions. CyberScoop published its account at 21:21 UTC the same day, and the conference's own page confirms the event (Cyber Innovation Conference 2026, 26 to 27 October, Washington, with the Challenge on the afternoon of 27 October). The three points of advice are first hand from nobody's page: they are the executive's words as CyberScoop quotes them. The three OpenAI pages read for this briefing, the Daybreak page, the Patch the Planet post of 21 October 2026 and the outbound coordinated disclosure policy of 22 September 2025, contain no list of advice for people who report bugs. They are covered in their own section below, and what they do say is mostly about how OpenAI sends and coordinates its own reports.

How this was read. CyberScoop's article and its linked report on the PHP release were read in full from 09:14 UTC on Wednesday 28 October 2026. A plain request to OpenAI's three pages answered with an HTTP 403 bot challenge, so this site did not read them that way and did not try to get past it. The three pages were then opened in a real browser tab by the site's editor, with no challenge, and saved as text snapshots of the page content at about 09:28 UTC on the same day. They were read in full from those snapshots. A snapshot holds the text, not the layout or any image. Where the briefing says first hand it means one of those pages; where it says CyberScoop reports, it is second hand. The maintainers' side comes from pages and posts read directly.

OpenAI's interest, in one sentence: it sells Daybreak and its GPT Cyber models (the Daybreak page offers a sales contact and says OpenAI is committing 1 billion US dollars in subsidised Daybreak access over six months), and it runs Patch the Planet, the programme the executive held up as the better route, so advice that favours well resourced, coordinated disclosure also describes OpenAI's own offering. Anthropic has a comparable interest, and our earlier briefing on its OSS Scanner records how it describes sending model generated reports to maintainers.

What was said, by whom, and the three pieces of advice

CyberScoop reports that the executive described the problem as "an ecosystem problem", with some maintainers who have "just stopped taking" submissions because they cannot get through them. He said that in most cases the reports are "likely real bugs of some degree", and that the question is whether they are critical and worth a maintainer's time. The advice, as CyberScoop quotes and paraphrases it, is for those who make vulnerability disclosures to open source maintainers:

1. Establish the quality of the finding: "really high quality". CyberScoop's paraphrase is more work in establishing the quality of the finding.

2. Write a report that is "consumable and readable by a single person".

3. Spend your own resources on coordinating the disclosure, which he called "another project" because it has to happen "across the whole ecosystem".

His worked example was the recent PHP release. In CyberScoop's account a partner research organisation found the flaw, and OpenAI worked with the PHP Foundation to validate it, develop a fix and coordinate the release, which meant dealing with response partners and with operators. He added that it did not go perfectly and that OpenAI is learning as it goes. CyberScoop's report of 21 October and OpenAI's own post of the same day (the section below) record that two parties found the same PHP flaws independently, an outside firm using an OpenAI model and a security company, and that OpenAI expects similar findings to "increase sharply in the coming months". The advice is addressed to finders. The forecast is about volume.

What OpenAI's own pages say, first hand

Three pages, each read in full from a saved snapshot on 28 October 2026. The Daybreak page (no date printed) says OpenAI wants maintainers to benefit from frontier AI and, in its words, "not be overwhelmed by more unvalidated reports", and that Patch the Planet, "built with Trail of Bits", pairs models with expert review to validate findings, develop and test patches, coordinate disclosure and keep maintainers in control of what lands. It names Trail of Bits, Calif and Linux Arkrites in its commitment of API credits and direct support, and prints 17 million US dollars of credits and support alongside the counts above. HackerOne and Calypso, which the story brief expected, are not named on it.

The Patch the Planet post, dated 21 October 2026 and signed only "OpenAI", is about PHP. Over two months OpenAI "led a coalition of maintainers, researchers, and security providers". Calif found a critical flaw with GPT 5.6 Sol, and Wiz "also independently" discovered and reported both vulnerabilities, so the duplicate discovery is in OpenAI's own account. PHP's maintainers led the fixes and release, with partners "like Wiz, Cloudflare, and others". The post proposes a five stage framework for critical vulnerabilities in widely used software and asks the security community to help improve it. It says OpenAI expects "similar findings to increase sharply in the coming months". It contains no totals of reports or patches. A search summary seen earlier in the day quoted totals of 679 patches and 466 accepted from a 21 October dashboard; neither those numbers nor 68 codebases or 1,995 issues appear on any page read, and the Daybreak page shows lower counts (65, 1,885, 661, 458) than that summary on a later day, which a running counter should not do. They are left out as unverified.

The outbound coordinated disclosure policy, dated 22 September 2025, governs how OpenAI reports bugs it finds in other people's software. It is the closest OpenAI text to the executive's advice, and it is written about OpenAI's own conduct, not about what outside finders should do. Each finding is validated for security impact. Where an automated system finds a flaw, a security engineer reviews the disclosure before release. OpenAI follows the recipient's own inbound procedure where it can, prefers vendor security email or private GitHub reporting, avoids public trackers such as GitHub Issues by default, and says it does not commit to strict publication timelines. It lists the circumstances in which it may disclose publicly: vendor permission, credible evidence of active exploitation, a recipient that is unreachable or unresponsive, and others. It says it expects the policy to change substantially as security research becomes more automated.

Two things follow. First, OpenAI's pages do not contradict the executive, they just do not contain his advice: the quality and coordination points are practices OpenAI describes for itself, and the readability point is nowhere printed. Second, the disagreement with the kernel is now on the record from both sides. OpenAI's policy says private first and avoid public trackers; the kernel's text says an AI found bug should be treated as public because several finders tend to turn it up at once. OpenAI's own PHP account, with two independent finders, is an example of the kernel's concern, though it was handled privately and coordinated over two months. The kernel's embargo ceiling for a privately reported bug is 7 calendar days, exceptionally 14, against OpenAI's "past two months" on PHP: different projects and flaws, so a contrast and not a like for like comparison.

He says most are real bugs, which is not the slop story

The word that matters in the executive's answer is "real". The familiar account of AI found bug reports is slop: invented flaws, hallucinated code, nothing to fix. If most reports are real bugs of some degree, the problem is not detecting nonsense. It is the cost of reading, reproducing and ranking a large number of true but mostly minor findings. The best public numbers on that come from one project, curl, whose lead developer has posted them with graphs.

In January 2026 curl's lead developer ended the project's bug bounty, effective 31 January, citing AI slop. He wrote that more than 15 per cent of submissions had ended up as confirmed vulnerabilities in earlier years, and that from the start of 2025 the rate "plummeted to below 5%". Over the programme's life he counted 87 confirmed vulnerabilities and over 100,000 US dollars paid. On 22 April 2026 he wrote that the slop situation "is not a problem anymore": reports were arriving at about double the 2025 rate, the confirmed rate was back in the 15 to 16 per cent range, and almost every report now used AI to some degree. On 26 May he put the 2026 rate at four to five times 2024 and double 2025, on average more than one report a day, with twelve confirmed vulnerabilities pending for one release. His weekly email of 5 June says all the pending reports were rated low or medium severity and nearly all used AI, and projects about 60 curl CVEs for the year.

That fits the executive's words and not the slop story. It also sits oddly beside the claim that maintainers have stopped taking reports: curl has not. It dropped the money, changed the channel, and is working through the queue, and its lead developer says he spends almost all his days on it and may have to cut his hours. His 24 April weekly email gives the likely shape of the load: each new AI code analyser run against curl has produced "dozens up to hundreds" of newly found issues, "rarely actual vulnerabilities", mostly minor errors in rarely used corners. That is the executive's question, whether the bugs are worth the maintainers' time, stated from the receiving end.

Zoom

Zoom

Zoom

Three cautions. This is one project, reported by its own lead developer, who also asks companies that depend on curl to buy support contracts. The slides print no values and no definition of slop, and 2026 is a part year at the time of writing. And the fall in slop after the bounty ended is a fact about curl's queue, not proof of why it fell. Nothing here shows that other projects, or the reports the executive had in mind, look the same.

What projects and foundations say in their own words

The executive's advice, quality and readability and coordination, is general, as befits an answer in a Q&A. Projects that receive the reports have written the same ideas down as rules. These were read directly on 28 October 2026 unless a date says otherwise.

The OpenSSH project said something narrower in its 10.6 release notes, which our earlier briefing read against the CVE records, and Google paused a bounty over automated submissions, as another briefing records. Those are not repeated here.

The sources do not agree on one point that matters for the third piece of advice, and the disagreement now includes OpenAI's own policy. The executive says to spend the finder's own resources coordinating disclosure across the whole ecosystem, and OpenAI's outbound policy says private first, public trackers avoided by default. The kernel's text says a finder who used AI "must treat it as public", because such bugs "systematically surface simultaneously across multiple researchers, often on the same day", and asks that a reproducer not be posted publicly. curl sends low and medium reports to its public tracker. The OpenSSF guide lists duplicate reports as a named problem, and OpenAI's PHP post records two independent finders. None of the sources measures how often that happens, so whether an AI found flaw should start private or public is left open by the record.

Two routes into a maintainer's queue, and where the gates sit

The diagram draws only what the record names. The top route has no gate: output from a scanner becomes a report and lands in the queue. The bottom route has the three gates the executive named, in the order he gave them. Every gate carries a line saying what is not stated, because that is where a label stops being a control.

Zoom

The friendly name fallacy applies to all three gates. "High quality" has no test in the report, so a finder's own sense of quality passes it. "Readable by a single person" has no length or format limit, while the kernel's text sets one in effect by requiring a summary first, plain text and a reproducer. "Coordination" and Patch the Planet are names for effort, and OpenAI's figures, 458 of 661, count accepted patches and not the reports that were never accepted or never sent. A label is not a control. The controls are the project's own checklists, which is why the checklist below is built from theirs.

Why true bugs can still be too many: the arithmetic

The OpenSSF guide says each vulnerability report can take a developer 1 to 8 hours to review and evaluate. The executive said "hundreds and hundreds", without saying how many reach one maintainer. Taking the guide's range at face value and choosing batch sizes for illustration, 100 reports are 100 to 800 hours of review, which is 2.5 to 20 forty hour weeks, and 200 reports are 200 to 1,600 hours, 5 to 40 weeks (all derived). That is before any patch is written. Even the low end is a month of one person's time.

Zoom

Two checks against curl's figures. At one report every 20 hours, curl's own average for early 2026, there are 1.2 reports a day (derived: 24 divided by 20). At 1 to 8 hours each that would be 1.2 to 9.6 hours a day (derived, assuming the guide's range applies to curl, which neither source says). Its lead developer wrote on 26 May that he works through the HackerOne list "almost all" of his days. The arithmetic shows why that is plausible. It does not measure it.

What the record does not establish, and what OpenAI's pages settled

Not established: how many AI found reports are invalid. OpenAI's pages give no validity rate for reports, and the executive's only statement is "likely real bugs of some degree". curl's rates are one project's, and they point the other way from slop. Not established: that maintainers have stopped accepting reports in any number. CyberScoop says "some", names none, and curl, the best documented case here, has not stopped. Not established: that following the three pieces of advice reduces maintainers' load. No survey, no before and after count and no enforcement is cited. Not established: that OpenAI follows the advice itself. Its outbound policy describes validation and engineer review for its own reports, but no page gives how many reports it has sent, how many maintainers declined, or the period behind 661 and 458.

What the OpenAI pages settled: the 661 and 458 are printed by OpenAI, with their definitions (before maintainer review; accepted for inclusion), beside 65 codebases and 1,885 issues; the page prints no date or period; no page lists advice for reporters or triage steps for receiving reports (the post lists five stages for responding to a critical vulnerability, and the policy lists the contents of OpenAI's own reports); the Patch the Planet partners named on the pages are Trail of Bits, Calif, Linux Arkrites, Wiz and Cloudflare. What stays open: when the Daybreak counters were last updated; how many reports sit behind the 1,885 issues; whether the three points appear in writing elsewhere; and the 679, 466, 68 and 1,995 figures from a search summary, which match no page read.

Before you file, and before you read: two ranked checklists

Both lists are built from the projects' and the foundation's own texts read for this briefing, not from OpenAI's. They are in the order worth doing.

Technical details

None of the sources read here prints a payload, a configuration change or an indicator, and this briefing prints no exploit or proof of concept. The artifacts that exist are the reporting requirements. The first three blocks are copied exactly from the saved pages. The fourth is a field list that this site derived from them and marks as derived. A defender, meaning a maintainer, can adapt the fields into a report template. A reporter can paste the blocks into the instructions given to an AI tool, which is what the kernel's text asks.

The Linux kernel's four required items. This is the text a reporter's tool must satisfy before a report is processed; the page says a version given as "latest mainline" is not acceptable.

affected kernel version range: with no version indication, your report
will not be processed.  Note that a time-dependent version such as “latest
mainline” is not acceptable.  A stable identifier such as a commit ID or an
exact version is required.  Versions designating kernels not coming from
kernel.org (such as distro kernels) are meaningless to maintainers and
will not be processed.  A significant part of reports are for bugs that
have already been fixed, so it is extremely important that vulnerabilities
are verified on recent versions (development tree or latest stable
version), at least by verifying that the code has not changed since the
version where it was detected.
description of the problem: a detailed description of the problem, with
traces showing its manifestation, and why you consider that the observed
behavior as a problem in the kernel, is necessary.
reproducer: developers will need to be able to reproduce the problem to
consider a fix as effective.  This includes both a way to trigger the issue
and a way to confirm it happens.  A reproducer with low complexity
dependencies will be needed (source code, shell script, sequence of
instructions, file-system image etc).  Binary-only executables are not
accepted.  Working exploits are extremely helpful and will not be released
without consent from the reporter, unless they are already public.  By
definition if an issue cannot be reproduced, it is not exploitable, thus it
is not a security bug.
conditions: if the bug depends on certain configuration options,
sysctls, permissions, timing, code modifications etc, these should be
indicated.

The kernel's rules for AI assisted reports: length, formatting, impact, reproducer. The page adds that the assistant must also propose and test a fix and include a Fixes tag, and that the report is posted to a public list.

Length: AI-generated reports tend to be excessively long, containing
multiple sections and excessive detail. This makes it difficult to spot
important information such as affected files, versions, and impact. Please
ensure that a clear summary of the problem and all critical details are
presented first. Do not require triage engineers to scan multiple pages of
text. Configure your tools to produce concise, human-style reports.
Formatting: Most AI-generated reports are littered with Markdown tags.
These decorations complicate the search for important information and do
not survive the quoting processes involved in forwarding or replying.
Please always convert your report to plain text without any formatting
decorations before sending it.
Impact Evaluation: Many AI-generated reports lack an understanding
of the kernel’s threat model (see The Linux Kernel threat model)
and go to great lengths inventing theoretical consequences. This adds
noise and complicates triage. Please stick to verifiable facts (e.g.,
“this bug permits any user to gain CAP_NET_ADMIN”) without enumerating
speculative implications. Have your tool read this documentation as
part of the evaluation process.
Reproducer: AI-based tools are often capable of generating reproducers.
Please always ensure your tool provides one and test it thoroughly. If
the reproducer does not work, or if the tool cannot produce one, the
validity of the report should be seriously questioned. Note that since the
report will be posted to a public list, the reproducer should only be
shared upon maintainers’ request.

Django's disclosure and verification rule for AI assisted reports, which a maintainer can adopt as policy text.

If you use AI tools to help prepare a report, you must:
Disclose which AI tools were used and specify what they were used for
(analysis, writing the description, writing the exploit, etc).
Verify that the issue describes a real, reproducible vulnerability
that otherwise meets these reporting guidelines.
Avoid fabricated code, placeholder text, or references to non-existent
Django features.
Reports that appear to be unverified AI output will be closed without response.
Repeated low-quality submissions may result in a ban from future reporting.

OpenAI's own description of what its reports contain, from the outbound coordinated disclosure policy. It is the only report structure OpenAI prints, and it is for reports OpenAI sends, not advice to others.

Upon discovery, each finding is validated for security impact. Reports typically include:
Impact summary (e.g., denial‑of‑service, memory corruption)
Affected versions / commit ranges
Reproduction steps or a proof‑of‑concept (PoC) where possible
Reproduction aids (e.g., Docker image) where feasible

A field list for a report, derived. It is not OpenAI's, which was not readable, and it contains no exploit. The values after each colon are descriptions, not data.

Title: one line naming the component and the flaw class
Affected version: exact release number or commit ID, not latest
Still present on current release or development tree: yes or no, and how it was checked
Summary: two or three sentences in plain text, impact first, no severity score unless asked
Conditions: configuration options, permissions, timing needed to trigger it
Reproducer: attached privately, or available on request, or could not be produced
How the reproducer was run: build, platform, command line
Proposed fix: tested patch, with the project's commit conventions
Duplicate check: where searched and on what date
Tool use: which AI tools, used for what

Triage steps for receiving reports: OpenAI's pages list none. The only process the executive described is the PHP coordination, and the Patch the Planet post lists five stages for responding to a critical vulnerability, copied below. They are about a response across maintainers, providers and governments, not about how a maintainer sorts an inbox.

Validate and fix the upstream vulnerability.
Give affected organizations time to act.
Coordinate with government partners to help protect critical systems.
Prepare updates across affected products.
Once a patch is available, publish guidance and support deployment.

The question that exposes the gap

The advice asks finders to be high quality, readable and coordinated, and to pay for it themselves. It offers no way for a maintainer to check any of the three before spending the first hour. If a tool hands one maintainer 200 reports and each takes between one and eight hours, who has agreed to spend those 200 to 1,600 hours, and where, in writing, did the maintainer agree?

Key facts