Bug Bounty

OpenAI’s five-stage disclosure plan tests UK hacking law

OpenAI proposes a five-stage process for disclosing AI-found critical bugs. Its questions on remote patching collide with the UK Computer Misuse Act.

Bug motif illustration with the headline OpenAI drafts rules for AI-found bugs

OpenAI has published a draft five-stage process for disclosing critical bugs that AI finds in widely used software, and it wants researchers, maintainers and governments to help shape it. Several of the ideas it floats, especially internet-wide scanning that could patch vulnerable systems directly, would run into the Computer Misuse Act in the UK.

What happened

On 21 October 2026 OpenAI published a proposal for coordinating responses to critical vulnerabilities in software that underpins large parts of the internet. The trigger was PHP2Shell, the pair of critical PHP flaws patched in an emergency release on 21 October after a two-month response. Under OpenAI’s Patch the Planet open source programme, the research firm Calif found one of the PHP flaws with the GPT-5.6 Sol model, while Wiz separately identified and reported the pair. PHP’s own maintainers led the fix and the release.

OpenAI says those bugs belong to a larger batch it is still working through, and it expects many more such findings in the months ahead. The document sets out a staged model and ends with questions for the security community, plus a feedback form.

It is a proposal, not a policy: maintainers keep the final say over who is told what, and when.

The detail

The framework is meant for flaws that affect many products at once, where downstream distributors, hosting firms and security vendors need time to prepare before the details come out. There are five stages:

  1. Validate and fix. Maintainers, the finders and technical partners confirm the bug, judge its impact and build a patch. Part of this stage is using frontier models to try to break the fix and to look for variants.
  2. Early access for those who must act. Selected organisations get advance information so they can backport fixes to older releases, test mitigations or write web application firewall rules.
  3. Government engagement. Partners in government help guidance reach operators of critical infrastructure and essential services. For PHP, OpenAI names the White House’s Super Intelligence Force, the Office of the National Cyber Director and CISA, plus unnamed international partners.
  4. Wider notification. Once the fix and disclosure plan are settled, more distributors, providers and operators are told.
  5. Post-patch support. After release, responders publish guidance and help operators get the update deployed.

On who gets told early, OpenAI suggests three tests: the organisation’s protective role, how much lead time it needs, and whether it can be trusted with sensitive material. Each party gets only what its role needs, from indicators of compromise up to a working proof of concept. OpenAI also warns that “even limited details can reveal a vulnerability”, and says timelines should be reopened if a bug is exploited, leaks, or is given away by a revealing public patch.

The open questions matter more than the stages. OpenAI asks how long disclosure windows should run and what evidence should cut them short. It asks how to balance broad early notice against the risk of leaks, and how to protect older releases that have fallen out of support. The most contentious question is whether governments or operators should ever use a vulnerability to patch systems after losing normal administrative control, and what safeguards would apply. OpenAI also sketches a possible end state: always-on, internet-wide scanning that either warns site owners or patches the vulnerable system itself.

Flow diagram of OpenAI's five proposed stages for coordinating disclosure of critical AI-found vulnerabilities

Why it matters for UK organisations

Most of the framework is uncontroversial. It formalises what good multi-party disclosure already looks like. The parts that would land hardest in the UK are the ones about scanning and patching other people’s systems.

Under the Computer Misuse Act 1990, unauthorised access to a computer is an offence under section 1, and there is no good-faith carve-out. Anyone who scans the internet for vulnerable servers and then logs into them or changes them without the owner’s permission, however good their intentions, is taking legal risk in this country. Section 1 is unchanged today. The government has promised reform but has not yet delivered it.

Where reform is heading is also relevant. In Lords Grand Committee on the Cyber Security and Resilience Bill on 7 September, the minister, Baroness Lloyd of Effra, said the Home Office intends to offer a section 1 defence limited to “accredited cyber security researchers”. No accreditation body, eligibility test, cost or timetable has been published. Lord Clement-Jones withdrew his amendment calling for a review of a statutory defence but signalled he may return to it. Lords Report stage is provisionally scheduled for Monday 26 October, when withdrawn amendments can be tabled again and put to a vote.

If UK protection ends up depending on a membership scheme, volunteers, students and one-off reporters could be left outside both the safe harbour and the early-notice circle OpenAI describes.

Expert view

I welcome the proposal for one main reason: it treats disclosure as logistics, not etiquette. The hard part of a multi-vendor fix is rarely the patch itself; it is reaching everyone who repackages, hosts or protects the code before attackers diff it.

My worries are the gatekeeping and the scale. A tiered early-access list is only as good as whoever decides who is on it. Smaller UK hosting firms, managed service providers and public bodies are exactly the organisations that tend to hear last, yet many of them run very old PHP stacks. When we test public sector and SME estates, unsupported runtimes are still among the most common findings, and those systems are the ones a “notify the big players first” model can leave behind.

The idea of patching other people’s systems from the internet is where I would urge the most caution. Well-meant remote changes can break production, destroy forensic evidence and blur accountability, and in the UK they are likely to be unlawful without permission today.

What to do now

  1. Know what you run. Keep an accurate inventory of runtimes, frameworks and their versions, including on hosted and outsourced services. This is the foundation of the Cyber Essentials security update management control, and it is what lets you act on day one of a disclosure.
  2. Fix your intake. Publish a vulnerability disclosure policy and a security.txt file, and make sure reports reach someone who can triage them quickly. Plan for more AI-assisted reports and their duplicates.
  3. Get on the right lists. Make sure your hosting providers, distributors and key suppliers have a working security contact for you, and ask how they would pass on early warnings.
  4. Write down your authority. For in-house and contracted testing, keep written scope and authorisation for every engagement. Until the Computer Misuse Act changes, that paperwork is your main protection.
  5. Respond to the consultation. UK researchers, VDP owners and maintainers should send OpenAI their views on notification criteria and remote patching. They should also follow, and respond to, the Lords Report stage debate on researcher protections.

Bottom line

OpenAI’s five stages are a sensible draft for a problem that is about to get much bigger. In the UK, though, the hardest questions it raises are legal as well as technical. Until Parliament settles what a protected researcher is, organisations should tighten their own disclosure processes and not count on a safe harbour that does not yet exist.

Sources

Related Posts