GPT-6 Cyber: What Hundreds of Kernel Fixes Mean for SME Updates

In November 2026, OpenAI introduced GPT-6 Cyber, a model built to hunt for security vulnerabilities. What is new is less the technology than the scale: in the current Linux kernel, agents found approx. 1,700 confirmed bugs, and every finding comes with a price tag. For businesses without their own development team, the situation hinges on how quickly fixes reach their devices.

In the spring, Anthropic reported an unreleased model that is said to have found thousands of previously unknown vulnerabilities in operating systems and browsers. Shortly afterwards came Google's Gemini 4 Carbon with markedly better scores in exploit benchmarks. With OpenAI's announcement, a run across an entire kernel can now be put into figures for both cost and results.

Anyone who can find bugs this cheaply inevitably produces a lot of fixes. Servers, firewalls, NAS systems and cameras almost all run on Linux, and in most businesses someone else maintains the kernel.

GPT-6 Cyber at a glance

GPT-6 Cyber is a specialised variant of GPT-6 Astra for authorised security work. The model searches for vulnerabilities, builds matching exploits and proposes fixes. In the model card, OpenAI rates its cyber capabilities at the highest level of its own Preparedness Framework. In the ExploitGym exploit benchmark, it solves approx. 48% of the tasks, compared with approx. 42% for the base model.

Older benchmarks may be inflated by training data, reliably exploiting freshly disclosed vulnerabilities remains difficult, and fully hardened targets held up. The model shows a clear direction, but it does not crack every target.

Access is initially limited to selected, vetted customers. It is provided via the API and Codex, with identity verification, multi-factor authentication and allow-listed IP addresses. OpenAI recommends running the model in isolation and under human supervision. A gradual expansion has been announced, but there is no date for general availability.

Kernel bugs on a large scale

The centrepiece is a run across the current Linux kernel. First, agents narrowed down the security-relevant areas, approx. 7% of the code. Further agents flagged approx. 2,300 suspicious spots there, and approx. 1,700 of them could be confirmed in isolated virtual machines. Testing was done on an unmodified desktop Linux with the usual protection mechanisms designed to stop attackers from guessing memory addresses.

The confirmed bugs yielded approx. 1,200 working local privilege escalations, in which an ordinary account becomes administrator. Behind them are approx. 950 separate patches. Hundreds of findings therefore lead to hundreds of fixes. The kernel maintainers responded quickly: within ten days, more than 100 privilege escalations had been patched or had patches in preparation, and approx. 300 more were being discussed publicly.

The price is new as well. The run cost approx. USD 1.2 million in API fees, roughly USD 1,300 per result. A precursor scan in the summer came to approx. 170 privilege escalations for just over USD 500,000; the new run delivers several times as many findings at about twice the cost. Vulnerability hunting thus becomes a predictable cost item, comparable to cloud compute time. In Firefox, the model also found approx. 80 previously unknown severe vulnerabilities, which Mozilla has fixed.

Hundreds of fixes and update cycles

A finding on its own protects no one. Only the fix in the kernel and then its installation on the device change the situation. The number of CVE identifiers per kernel release is rising sharply, with approx. 40 million lines of code. Many of them concern low-priority bugs, but the pace at which maintenance updates arrive is rising noticeably.

The critical period is the time between a published fix and an installed update. As soon as a patch is public, it shows attackers where the bug was. An open model turned known but not yet shipped Firefox fixes into working attacks for approx. USD 1,000 per version, albeit only for reading files on a standard Ubuntu system. Every public fix is thus a blueprint for attackers.

A local privilege escalation needs an initial foothold, such as a stolen password, a web shell or an escape from a container. Whoever has one can use such a flaw to get all the way to root. That is why local kernel bugs matter even on servers that are only reachable via the web. Not every finding is exploitable, and not every server is at risk. But the second hurdle behind the initial break-in is getting thinner.

In day-to-day operations, this means no longer treating updates as a quarterly project. A fixed rhythm with short reboot windows, for example monthly and immediately for critical vulnerabilities, takes the fear out of each individual advisory. If you reboot regularly anyway, you do not first have to gather approval, a time slot and the people responsible for every kernel fix.

Vendor kernel patches

A kernel fix has a long journey. It first appears in mainline, is taken over into the long-term branches and makes its way into the distribution kernels. For devices, the vendor kernel, firmware build, approval and rollout come on top. Only then can the business install it.

The picture varies greatly by device group. Standard servers with a maintained distribution usually receive kernel updates within days to weeks. With live patching, the window can be shortened further for critical vulnerabilities, but a reboot remains the safest route.

For appliances such as firewalls, NAS systems and routers, the vendor sets the pace. The update window is part of product maintenance, and the business can hardly influence it. Embedded and IoT devices fare worst. They often run vendor kernels that lag many months or several versions behind mainline, and some products never receive kernel fixes at all.

Three questions to vendors and suppliers bring clarity. How many days after the upstream fix does an update appear? Which kernel line is in the device? And until when is it supported?

What SMEs can do about late patches

It starts with a simple inventory. Linux is not only in servers, but also in routers, NAS, cameras, printers, firewalls and controllers. For each device, the kernel and firmware version and the name of the vendor are enough.

Next comes prioritisation. What is reachable from the internet, what processes credentials, what offers administrative access? Devices with several yes answers come first. A missing fix can be partly offset by isolation:

• Do not expose admin interfaces publicly; allow access only via VPN with multi-factor authentication.
• Put devices in separate network segments so that one compromised device does not open up the entire network.
• Keep privileges minimal: no shared admin accounts, separate service accounts, containers with restricted rights.
• Monitor logs so that unusual logins and privilege changes stand out.

OpenAI itself recommends layered defence and isolation when working with the model, for example with Firecracker or gVisor. That applies to any business: a bug in the kernel should not automatically open up everything else.

A second lever lies in the contract. Patch deadlines and end of support belong in supply and maintenance contracts, and reboot windows can be agreed in advance. If you fall under NIS2, you should extend your vulnerability management to suppliers as well. Critical fixes belong on the devices within days, not in the next quarter.

Your own website is part of the inventory too, because it is the part attackers see first. A website check and the security checks show what is visible from the outside.

Benchmarks at a weekly pace

The curve of frontier models is rising fast. Gemini 4 Carbon arrived about four weeks after its predecessor Argon and reaches approx. 55% in ExploitGym, up from approx. 42% for Argon. Anthropic held back its model in the spring because it was not meant to become generally available. The approach is similar at all major providers: the strongest model initially stays within a small circle.

Benchmarks are not the same as practice. For planning, direction and pace matter, not the individual percentage. The real news is that the gaps between model generations are shrinking to weeks or months. What was still an exception in the spring, with thousands of vulnerabilities found, now looks like a harbinger.

Open source AI and distillation

In AI, knowledge trickles down. In distillation, a large model, the teacher, generates answers and solution paths, and a smaller model, the student, learns from them. The result is often much smaller and cheaper without losing all its capabilities. For SMEs, this is the decisive point: what runs in data centres today slips within a few months onto hardware that fits into a server rack.

Open models such as GLM-5.2 and DeepSeek V4-Pro are 4 to 7 months behind the best closed models in cyber capabilities. In 2025, the gap was still 6 to 10 months. Averaged across all capabilities, it is approx. 4 months.

For access-restricted models such as GPT-6 Cyber, this means that access control gives defenders a temporary head start. Once released, open weights can neither be recalled nor monitored. The months until open models catch up are therefore the window for baseline protection, clean updates and AI-assisted defence. At the same time, open models also benefit researchers and defenders, because testing tools do not only emerge on the attacker side.

Local AI as the answer

Frontier models are access-restricted, vetted and monitored. Anyone who uses them for security work hands source code, configurations and logs to a provider that observes the actions. Protected processing without insight by the provider is only available to customers with Zero Data Retention. For most SMEs, that is not a realistic option.

A clear alternative is local AI with open models on your own hardware. The data stays in-house, and there is no dependence on prices, access rules or a shutdown. This is also a strategic advantage, because anyone who keeps knowledge and tools within their own business reacts more calmly to individual providers' announcements. Typical tasks are analysing logs, reviewing your own configurations, summarising security advisories and documentation.

Models that can run locally do lag well behind the best cloud models, which is a disadvantage when hunting for zero-days on a large scale. For everyday operations, however, they are often sufficient, and that is exactly where data security is decided.

Local installations need discipline too. Interfaces do not belong on the internet, models come from trustworthy sources, and agents' privileges stay limited so that external content cannot inject commands. Getting familiar with offline AI is a good way to start.

Conclusion

Bug hunting with agents is cheap, fast and scalable. The field for action therefore lies not in finding, but in installing. Anyone who knows their devices, agrees on deadlines and prepares isolation will not be overwhelmed by hundreds of kernel fixes. And anyone who keeps data and tools in-house stays capable of acting even when the next models become faster still.