What is Gemini 4 Carbon and what is its primary function?

Gemini 4 Carbon is a new Google AI model designed to identify and exploit security vulnerabilities. It is specifically engineered to perform significantly better than its predecessor, Gemini 4 Argon, in this area.

What is the access strategy for Gemini 4 Carbon, and who receives it initially?

Google intends to release Gemini 4 Carbon in stages, beginning with US intelligence agencies and selected defenders through the Fairwind program. General availability for the public is currently undefined and without a specific date.

What benchmarks does Gemini 4 Carbon utilize, and what do these benchmarks reveal about its performance?

Gemini 4 Carbon utilizes benchmarks such as Exploitgym, SEC-bench Pro, and CWE-bench to measure its performance. According to Google, it outperforms its predecessor in these benchmarks, particularly in vulnerability exploitation and fixing security vulnerabilities.

What is an exploit chain and why is it significant?

An exploit chain links multiple vulnerabilities to create a more powerful attack. This is significant because it demonstrates how a seemingly small bug can be amplified into a complete attack, highlighting the need for comprehensive security measures.

According to the article, what are some key recommendations for businesses regarding vulnerability patching?

The article recommends shortening patch cycles for operating systems and browsers, enforcing automatic updates, and establishing an emergency track for critical vulnerabilities. Prioritizing internet-facing systems and setting deadlines in days rather than weeks is also advised to mitigate the risk of rapid exploitation.

Can you describe the vulnerability found in Chrome related to the sandbox?

The Chrome vulnerability allowed code execution outside the sandbox, leveraging memory bugs, a race condition, and a use-after-free. This demonstrates the potential for attackers to bypass security protections and compromise systems, necessitating rapid patching and ongoing security monitoring.

What is the primary concern discussed regarding vulnerability hunting?

The article highlights the increasing use of powerful AI models for vulnerability hunting, raising the possibility that these models could identify and exploit weaknesses faster than traditional patching cycles. This creates a competitive advantage for those with access to these models.

How does the Cyber Resilience Act impact software vendors in Europe?

The Cyber Resilience Act establishes reporting obligations for actively exploited vulnerabilities, with initial requirements for reporting starting in September 2026 and broader obligations in December 2027. However, the exact deadlines within the legal text were not independently verified.

Gemini 4 Carbon: Exploit AI for Intelligence Agencies First

Google has unveiled Gemini 4 Carbon, a model that, according to the company, is clearly 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 October 28, 2026, Google unveiled 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 for general availability. One day before Google's announcement, on October 27, 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.

First come the benchmark claims and their limits, then the stages of access and the question of what this asymmetry means for organizations outside the USA. 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 how to check 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 just behind the competing model GPT-6 Astra. On the SEC-bench Pro benchmark, Carbon is at just over 88 percent and thus, according to the report, ahead of that competitor. For CWE-bench, a test of fixing security vulnerabilities, 71 percent is cited. A benchmark is a standardized set of tasks on which models are measured in a comparable way. How exactly the three tests are designed was not examined here. That is why the description deliberately sticks to what the report says.

Further claims also come from Google: so far, no prompt injection attempt has succeeded, meaning no manipulation of the model through smuggled-in instructions. The model is also said to hallucinate less and to ask follow-up questions more often. There are no independent measurements of this. As a side note, prices of 4 US dollars per million input tokens and 20 US dollars per million output tokens are mentioned, with a 50 percent discount at launch. By current standards that is not cheap in comparison, but in absolute terms – not really expensive either.

Benchmark scores answer a narrow question: how well does a model solve prepared tasks? They say only so much about how well it works in grown software with edge 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 this 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 how it reaches users. Google apparently is complying with 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 approved by them. Whether and how they use the model is not documented. Only the planned order is documented. The second stage is the Fairwind program, through which selected cyber defenders and other trusted partners are to be added step by step. The third stage is the general public. Google promises availability “soon” but gives no date. With Argon, two weeks passed between the unveiling and the release to paying users.

Diagram of staged access to Gemini 4 Carbon: US intelligence agencies first, then Fairwind defenders, then the general public — Order of access; there is no date for the general public.

How Fairwind works is described by Google DeepMind on the program page. It lists more than 650 partners. Governments and national cyber authorities, 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 access on is prohibited. However, the page names Argon as the model, not Carbon. Whether Carbon is subject to 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. Governments and large platforms get powerful tools earlier than small and medium-sized businesses and software vendors. Nobody knows how long this gap will be. Two questions can be separated: who decides on access, and what follows for organizations that are not included? Apparently the White House decides. For organizations outside the USA, what remains is to wait and to position themselves so that the head start of others 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 bugs 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, it would be speculation. For planning purposes it is enough to note that assuming a permanent head start for defenders is risky.

According to the Fairwind page, organizations 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 ways to AI-assisted bug hunting even without access to the top tier.

What Anthropic showed: 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 bug turns into a complete attack. Anthropic's Frontier Red Team describes on October 27, 2026 that an unreleased internal research model built working chains with initial instructions and little human involvement. The model is not named and is different from Carbon. Both reports, however, point in the same direction.

Overview of five exploit chains for Chrome, Safari, Android, Windows and Linux with their patch status — Five exploit chains according to Anthropic, with patch status.

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 bugs in the V8 JavaScript engine, a race condition (a bug that depends on the timing of parallel operations) and a use-after-free (access to memory that has already been freed). Anthropic reported 62 CVEs, i.e. publicly numbered vulnerability entries, all critical or high, including, according to Anthropic, 13 sandbox escapes. 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 vulnerability; according to The Hacker News, no public entry was found.
Windows: a denial of service via HTTP/3. Anthropic describes a vulnerability in the kernel, while The Hacker News points 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 once. According to Anthropic, bypassing KASLR, a protection based on randomized memory addresses in the kernel, took 48 minutes, after which it took another five minutes to get a root shell. CVE-2026-98432 with CVSS 9.8 is cited, a score at the very top of the severity scale from 0 to 10. According to the sources, the fix has been in the Linux mainline since October 15, 2026.

The Linux chain calls for caveats. Anthropic attributes the chain to an MPTCP vulnerability and cites CVE-2026-98432. The Debian Security Tracker, however, describes the same CVE as a bug in the IPv4 TCP code, namely a use-after-free during the transition from a request socket to the child socket. So far, the link between the CVE and MPTCP comes only from the Anthropic post. It is possible that descriptions are incomplete or that the chain touches several bugs. 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 verified 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 (October 20, 2026) and the Apple version are only available via The Hacker News; the primary sources were not consulted.

Patch cycle: when vulnerabilities are found faster than fixes are rolled out

Finding a vulnerability is only one part of the cycle. Patching is decentralized: 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 more quickly, the window between fix and exploitation shrinks. Deriving an exploit from the fix is called patch diffing: comparing the old and new code reveals where the bug was.

Do European companies need to patch differently because of Gemini 4 Carbon?

Not because of a single model, but because of the direction things are heading. The now-patched cases from the Anthropic report show that AI models can find vulnerabilities faster and build exploit chains with little human help. Google's claims about Carbon, by contrast, have not been independently verified. Sensible steps are shorter patch cycles for browsers, operating systems and kernels, an up-to-date asset inventory and an emergency track for vulnerabilities that are already being exploited.

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: classify alerts by urgency and have an emergency track ready. What such a procedure can look like in the first minutes is described in the article on the ransomware action plan for the first 60 minutes.

Two consequences follow from the Anthropic cases. One concerns volume: a single browser release contained fixes for 62 reported CVEs. The other concerns speed: the Linux fix was in the mainline on October 15, 2026, the distribution packages followed later, and when they reach a server depends on the operator. How quickly exploits appear after a fix was also demonstrated recently by the PHP vulnerability described in the article on PHP2Shell.

Schematic comparison of the window between fix and exploitation: before, with AI tools and with a short patch cycle — The window between fix and exploitation, schematically.

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 review round.
Handle internet-facing systems first, and measure deadlines in days rather than weeks.

A vulnerability that a model turns into an exploit within hours does 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 and a 45-day extension. This presupposes that vendors can receive, assess and quickly fix reports. That includes a findable contact for security reports, for example via a security.txt file, capacity for triage, fixes for older stable branches too, 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 September 11, 2026, and the other main obligations from December 11, 2027. The exact deadlines in the legal text were not checked here and are therefore not stated.

It is unclear whether European vendors will get the same access to defense models. For the moment, alternatives remain: evaluate programs from other providers, use freely available tools and build code scans into your own pipeline. Our own conclusion is to assume that your software will be searched by powerful models. Those who search first find the bugs 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.

Check Multipath TCP

According to the kernel documentation, MPTCP is opt-in: applications must request it via the socket type IPPROTO_MPTCP. However, it can 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 may 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-amd64

The first command shows the switch, the second lists listening MPTCP sockets including the process (the -M option shows only MPTCP sockets, process names require root privileges), the third shows the running kernel version. The last two commands (for Debian and derived systems) show 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 per distribution: distributions often backport fixes into older kernels, so the output of uname -r alone (e.g. 6.1.x) says nothing about the fix status. What counts is the package version in the respective distribution's security advisory. 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 consulted and must be checked yourself. A reboot is required after the kernel update, unless live patching is used.

Browsers, operating systems, inventory

Browsers: Chrome to version 156 or higher, iOS and iPadOS to 26.5.2 or higher, install Windows updates. Enforce update policies in device management.
Deadlines: internet-facing browsers and operating systems first, deadlines in days. The figures are for guidance.
Inventory: without an asset list, nobody knows which kernel is running on which server or whether an MPTCP listener exists. The list is the basis for any fast patching.

AI on the defender side: code scanning for pull requests

A pull request is a proposed change to the source code that is reviewed before it is merged. Code scanning for pull requests has every change additionally checked by a model automatically. 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 must 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 outside view

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: gain 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 well-maintained inventory and automated checks in development.

Still open are the date for general availability, the rules for Europe and the independent measurement of Google's claims, all of which should continue to be monitored.