Google has unveiled Gemini 4 Carbon, a model that, by the company's own account, is well ahead of its predecessor at finding and exploiting security vulnerabilities. US intelligence agencies get it first, selected defenders later, and there is no date for everyone else. This article sorts out what is documented, what remains a vendor claim, and what companies and software vendors in Europe can change in their patch cycles and review processes.
On 28 October 2026, Google introduced Gemini 4 Carbon, just four weeks after Gemini 4 Argon. The performance figures in the announcement are vendor claims and cannot be verified from the outside. More interesting is the order in which the model is to be distributed: government agencies first, then selected defenders, with no date given for everyone else. One day before Google's announcement, on 27 October 2026, Anthropic also published a report in which an unreleased research model is said to have built five exploit chains. According to Anthropic and The Hacker News, all five have since been fixed, although there is no public entry for the Android case and the mapping of the Windows case is unclear.
The article first describes the benchmark claims and their limits, then the stages of access and what this asymmetry means for organisations outside the US. After that come the Anthropic chains with their patch status, the consequences for patch cycles and software vendors, and a list of practical steps, including checking a Linux server. The situation may change quickly.
Gemini 4 Carbon: what Google claims and what can be verified
The information on Gemini 4 Carbon comes from Google and the coverage of the announcement.
According to Google, Carbon scores just under 55 percent on the Exploitgym benchmark. Argon reached 42 percent, putting it slightly behind the competing model GPT-6 Astra. On SEC-bench Pro, Carbon scores just over 88 percent, which according to the report puts it ahead of that competitor. For CWE-bench, a test on securing vulnerabilities, 71 percent is stated. A benchmark is a standardised set of tasks used to measure models in a comparable way. How exactly the three tests are structured was not examined here, so the description deliberately sticks to what the announcement says.
Further statements also come from Google: so far, no prompt injection attempt has succeeded, meaning a manipulation of the model through smuggled-in instructions. The model is also said to hallucinate less and ask follow-up questions more often. There are no independent measurements of this. As a side note, prices are given as 4 US dollars per million input tokens and 20 US dollars per million output tokens, with a 50 percent discount at launch. By current standards that is not cheap in comparison, but in absolute terms it is not really expensive either.
Benchmark scores answer a narrow question: how well does a model solve prepared tasks? They show only to a limited extent how well it works in grown software with special cases, legacy code and unclear responsibilities. A sober reading is therefore enough for an assessment. If Google's figures are accurate, the gap to the predecessor in exploiting vulnerabilities would be large. Whether the same holds in practice will only become clear once third parties can test the model.
Staged access: intelligence agencies first, then Fairwind, everyone later
What is really new about Gemini 4 Carbon is the way it reaches users. Google appears to be following a White House directive to make new AI models available initially only to US intelligence agencies and selected users. This results in three stages.
The first stage consists of US intelligence agencies and users they have approved. Whether and how they use the model is not documented. Only the planned order is documented. The second stage is the Fairwind programme, through which selected cyber defenders and other trusted partners are to be added gradually. The third stage is the general public. Google promises availability "soon" but gives no date. With Argon, two weeks passed between the announcement and the release to paying users.
How Fairwind works is described by Google DeepMind on the programme page. It lists more than 650 partners. Governments and national cyber agencies, operators of critical infrastructure, central technology platforms and academic labs can take part. Applicants are vetted. Requirements include phishing-resistant multi-factor authentication, logging and defensive use, and passing the model on is prohibited. However, the page names Argon as the model, not Carbon. Whether Carbon runs under the same conditions is open. The page does not mention any rules for Europe.
For European companies, this creates an asymmetry that is first of all a question of time. States and large platforms get powerful tools earlier than mid-sized companies and vendors. Nobody knows how long this gap will be. Two questions can be separated: who decides on access, and what follows for organisations that are not included? Apparently the White House decides. For organisations outside the US, what remains is to wait and to position themselves so that others' head start does as little damage as possible.
What matters is less how good the model is than how long others have to manage without a comparable tool.
The counterargument deserves weight. Staged access can limit misuse, and defenders with early access may find flaws before attackers do. It remains open whether attackers can obtain comparable capabilities elsewhere, for example from other providers or with freely available models. That is not documented and would be speculation. For planning purposes, it is enough to note that assumptions about a lasting advantage for defenders are risky.
According to the Fairwind page, organisations that are not eligible can use the CodeMender tool with publicly available models. This was not tested here. It does show, however, that there are paths to AI-assisted bug hunting even without access to the top tier.
What Anthropic demonstrated: five exploit chains and their patch status
An exploit is a piece of code that takes advantage of a security vulnerability. An exploit chain links several vulnerabilities so that a small flaw becomes a complete attack. Anthropic's Frontier Red Team describes on 27 October 2026 how an unreleased internal research model built working chains with initial instructions and little human involvement. The model is not named and is a different one from Carbon. Both reports, however, point in the same direction
The five cases at a glance, each according to the sources cited:
- Chrome: Visiting a page is enough to execute code outside the sandbox. The sandbox is the protective layer that separates web content from the rest of the system. The chain combines four vulnerabilities, including memory errors in the V8 JavaScript engine, a race condition (a flaw that depends on the timing of parallel operations) and a use-after-free (access to memory that has already been released). Anthropic reported 62 CVEs, i.e. publicly numbered vulnerability entries, all rated critical or high, including 13 sandbox escapes according to Anthropic. The fix is in Chrome 156.
- Safari: Read and write access to browser memory, bypassing the same-origin policy. According to The Hacker News, fixed in iOS and iPadOS 26.5.2.
- Android: Data access on a locked, stolen Pixel 9 via USB. Physical access is required. According to Anthropic, Google has fixed the flaw, but according to The Hacker News no public entry was found.
- Windows: a denial of service via HTTP/3. Anthropic describes a flaw in the kernel, The Hacker News refers to a CVE whose description names HTTP.sys. The mapping is unclear.
- Linux: Commands as root over the network, without authentication, if an MPTCP listener is running. MPTCP (Multipath TCP) allows a connection to use several network paths at the same time. According to Anthropic, bypassing KASLR, a kernel protection based on randomised memory addresses, took 48 minutes, followed by another five minutes to a root shell. CVE-2026-98432 with CVSS 9.8 is cited, a score at the very top of the 0 to 10 severity scale. According to the sources, the fix has been in the Linux mainline since 15 October 2026.
Some caveats apply to the Linux chain. Anthropic attributes the chain to an MPTCP flaw and cites CVE-2026-98432. The Debian Security Tracker, however, describes the same CVE as a flaw in the IPv4 TCP code, namely a use-after-free during the transition from a request socket to the child socket. The link between the CVE and MPTCP therefore so far comes only from the Anthropic article. It is possible that descriptions are incomplete or that the chain touches several flaws. This is not documented.
Three limits belong to the assessment. First, the share of human work is not broken down. What a model achieved on its own cannot be checked from the outside, only the vendors' patches are visible. Second, a figure like 62 CVEs shows volume, but not automatically exploitation in the wild. The texts reviewed contain no indication of that. Third, the dates for Chrome 156 (20 October 2026) and the Apple version are only available via The Hacker News; the primary sources were not retrieved.
Patch cycle: when vulnerabilities are found faster than fixes are rolled out
Finding a vulnerability is only one part of the cycle. Patching is decentralised: vendors publish fixes, distributions package them, operators install them. Each stage takes time. If models find more vulnerabilities faster and derive exploits from published fixes faster, the window between fix and exploitation shrinks. Deriving an exploit from the fix is called patch diffing: comparing old and new code reveals where the flaw was.
Do European companies need to patch differently because of Gemini 4 Carbon?
Germany's federal Cyber Agency currently sees attackers at an advantage. Exploits are now created in minutes to hours. For businesses without their own Security Operations Center, i.e. without round-the-clock monitoring, this means classifying alerts by urgency and having an emergency path ready. What such a process can look like in the first minutes is shown in the action plan for the first 60 minutes of a ransomware attack.
The Anthropic cases have two consequences. One concerns volume: a single browser release contained fixes for 62 reported CVEs. The other concerns speed: the Linux fix landed in mainline on 15 October 2026, the distribution packages followed afterwards, and when they reach a server depends on the operator. How quickly exploits appear after a fix was also evident recently with the PHP vulnerability known as PHP2Shell.
The following recommendations can be derived from this:
- Shorten the regular cycle for operating systems and browsers, for example weekly instead of monthly.
- Enforce automatic browser updates instead of leaving them to individual users.
- Set up a second track for emergencies that does not require a change board.
- Deal with internet-facing systems first, and measure deadlines in days rather than weeks.
A vulnerability that a model turns into an exploit within hours will not wait for the next Patch Tuesday.
Software vendors in Europe: what changes in development and disclosure
Vendors are both recipients and targets of such findings. According to its own report, Anthropic used coordinated disclosure with a 90-day deadline plus a 45-day extension. This requires vendors to be able to accept reports, assess them and fix them quickly. That includes a findable contact for security reports, for example via a security.txt file, capacity for triage, fixes for older stable branches as well, and a release rhythm that allows small fixes.
Legally, the Cyber Resilience Act is relevant. According to the European Commission, the reporting obligations for actively exploited vulnerabilities apply from 11 September 2026 and the other main obligations from 11 December 2027. The exact deadlines in the legal text were not checked here and are therefore not stated.
Whether European vendors will get the same access to defensive models is open. For the moment, alternatives remain: examine other providers' programmes, use freely available tools and build code scans into the own pipeline. The author's conclusion is to assume that the software will be searched by powerful models. Those who search first find the flaws before third parties do.
What companies can do now: Linux servers, inventory, patch deadlines
The commands are standard tools and should be tested in your own environment before production use.
Checking Multipath TCP
According to the kernel documentation, MPTCP is opt-in: applications must request it via the socket type IPPROTO_MPTCP. It can, however, also be forced from the outside, for example with the mptcpize tool. One example: since Go 1.24, listeners created via net.ListenConfig use MPTCP by default on Linux. Whether a server can be affected therefore depends on the software running on it. The net.mptcp.enabled switch applies per network namespace and is set to 1 by default.
Checks on a server:
sysctl net.mptcp.enabled
ss -Mlnp
uname -r
dpkg -l 'linux-image*'
apt policy linux-image-amd64The first command shows the switch, the second lists listening MPTCP sockets together with their process (the -M option shows only MPTCP sockets, process names require root privileges), and the third shows the running kernel version. The last two commands (for Debian and derived systems) show the installed kernel packages and their package version. If a Go service is running there, it may appear as an MPTCP listener. If the sysctl key net.mptcp.enabled is missing, the kernel does not support MPTCP.
Because of the unclear CVE mapping, disabling MPTCP is not enough. What matters is the kernel level, more precisely the package version of the installed kernel. The comparison differs by distribution: distributions often backport fixes to older kernels, so the output of uname -r alone (such as 6.1.x) says nothing about the fix status. The package version in the respective distribution's security advisory is what counts. The Debian Security Tracker lists as fixed under bookworm the versions 6.1.190-1 (security) and 6.12.113-1~deb12u1, under trixie 6.12.113-1 and under forky 7.2.12-1. This is the status according to the tracker and should be retrieved again on the day of implementation. The security pages for Ubuntu, Red Hat and SUSE were not retrieved and must be checked separately. A reboot is required after the kernel update, unless live patching is used.
Browsers, operating systems, inventory
- Browsers: Chrome at version 156 or higher, iOS and iPadOS at 26.5.2 or higher, install Windows updates. Enforce update policies in device management.
- Deadlines: browsers and internet-facing operating systems first, deadlines in days. The figures are for guidance.
- Inventory: without an asset list, nobody knows which kernel runs on which server or whether an MPTCP listener exists. The list is the basis for any fast patching.
AI on the defender's side: code scanning on pull requests
A pull request is a proposed change to the source code that is reviewed before it is merged. Code scanning on pull requests has every change automatically checked by a model as well. This complements static analysis and human review but does not replace them. Findings must be assessed by humans, because false positives are common and cost time.
Typical settings are a scan on every pull request, blocking on critical findings and documenting exceptions. Data protection and confidentiality need to be clarified in advance: the source code goes to a provider. The contract and zero data retention, i.e. the commitment that inputs are not stored, should be checked. The Fairwind page mentions this option for Argon with Gemini Enterprise. A product recommendation is deliberately avoided here.
The view from outside
A website check shows which services and technologies a website reveals to the outside. The security checks add visible configuration flaws. Neither replaces kernel updates or code review, but both provide an outside view like the one an attacker would have.
Conclusion: gaining time instead of chasing tools
Access to the most powerful models is unevenly distributed; for everyone else, the impact comes through more findings and faster patches. Defenders gain time through shorter cycles, a maintained inventory and automated checks in development.
Still open are the date for the general public, the rules for Europe and an independent measurement of Google's claims, all of which should continue to be monitored.
My name is Klaus Meffert. I have a doctorate in computer science and have been working professionally and practically with information technology for over 30 years. I also work as an expert in IT & data protection. I achieve my results by looking at technology and law. This seems absolutely essential to me when it comes to digital data protection. My company, IT Logic GmbH, also offers consulting and development of optimized and secure AI solutions.
