For the second time in Google Chrome’s history, Google awarded a $250,000 bounty for a full-chain exploit… to @XBOW. Here’s the full story: At an all-hands at the start of 2026 in Malta, I set the team a crazy challenge. A full-chain exploit of Chrome by the annual Black Hat cybersecurity conference in August. I believed there were few better tests of whether @XBOW could move beyond web applications to desktop software, servers and devices. Chrome is one of the most hardened pieces of software on the planet, used by more than half the world’s population. A full-chain exploit lets an attacker take total control of a machine, where they can read every email, password and bank login the user types. You don’t need to download anything or click a phishing link. Visiting the wrong site is enough. So @moyix, Andres Luksenberg, Baul Lee, and Willem Pinckaers took on the challenge along with a fifth teammate: OpenAI's GPT-5.6 Sol. They built a chain they thought would win, but Google told us they already knew one of the bugs. We were already in Las Vegas for Black Hat and DEF CON, and the team didn’t want to go home without the win. So Brendan and the agents built a new exploit in just 6 days. We submitted it to Google and waited. The news came through that we'd done what should’ve been impossible. A full-chain bounty of $250,000, the first awarded under Google’s 2026 rules. It took just 6 days and $40,000 of compute to construct an exploit that affects a billion users of Chrome on Windows. An intelligence-agency veteran told me his team used to spend 6 months on this kind of vulnerability. My takeaway: the cost of finding truly critical vulnerabilities is collapsing, for attackers and defenders alike. Restricting powerful models is not the answer; GPT-5.6 Sol is already public. But defenders have one advantage attackers never will: they can test their own code first. Assume your software is exploitable. Whoever is hunting your bugs has the same building blocks we did. This is cause for urgency but not panic. XBOW is now developing an autonomous product for testing compiled software (desktop applications, servers, embedded devices), and partnering with the world’s top organizations to design that product. If you’d like to be one of them, get in touch. P.S. Restart Chrome whenever the Update button appears!

This will be an interesting session!

Vibe coding has created a security epidemic. (And I’m partially to blame) When we launched GitHub Copilot in 2021, it combined GPT’s code generation with GitHub’s data. It could auto-complete a function from just its docstring. 5 years on, AI coding agents are orders of magnitude more powerful. Now a single prompt can send Astra or Fable off to write 1000s of lines of code without human intervention. These models are trained on public source code, which doesn’t follow secure coding best practices. They generate more vulnerabilities than seasoned professionals would. Almost half of AI-written code fails basic security tests. If you're shipping AI-written code, here's what I'd do: 1. Embed secure coding in your agents. Don't leave it to each developer to remember. Write your secure coding requirements into the prompts every coding agent in your org runs with. Then review AI-written code with the same rigor as human-written code. 2. Closely scrutinize access controls. AI is getting better at avoiding textbook bugs. Where it still struggles is your business logic: who should see what, and who can do what. We recently tested an app where users upload documents for AI analysis. Nobody told the AI the documents should be private, so every user could see everyone else's… 3. Runtime testing at the speed you ship. If agents write code around the clock, an annual pentest is not enough. Security testing has to be continuous and automated. 4. Assume attackers are already deploying autonomous attacks. They won't tell you what they find. You need to find it first.

Hacking governments used to take serious brains and resources. Today, hackers just need a $20 Claude subscription and a laptop. Earlier this year, a hacker got past Claude's guardrails and used it to attack at least 9 Mexican government organizations, including the national tax authority, Mexico City's civil registry, and the National Electoral Institute. The attack used models from Anthropic and OpenAI with a human at the keyboard. The attacker told the model they were on an authorized "bug bounty." When it refused to comply, they tricked the model into saving an MD file with a 1,084-line hacking cheatsheet that reloaded at the start of every session. Less than 40 minutes after the first prompt, the hacker had remote code execution, the worst kind of access, on a server at SAT, Mexico's tax authority. The model asked, "What command do you want to execute now?" The hacker went on to steal 195M taxpayer records, 50,000 patient records, and the files of 17,000 domestic violence victims. The hacker even built a live API to query government systems in real time. "Vibe-hacking" attacks like this will only become more common. In September, Google reported an AI agent building and running an entire credential theft campaign with preconfigured MD instructions and little human intervention. Earlier this month, CrowdStrike linked a wave of breaches at Shinhan and at least six other South Korean financial institutions (68,000 customers exposed) to a single hacker running ARTEX, an open-source AI pentesting tool, alongside Claude Code. The attacker used the same playbook: a CLAUDE.md file telling the model how to hack. The hacker even had Claude write a résumé listing the breaches as accomplishments. AI now enables a single hacker to do the damage of 100. The only way defenders can protect themselves is by finding and fixing their holes first. That's why we built @Xbow - to find and patch vulnerabilities before attackers do.

AI is exposing cybersecurity vulnerabilities in mass: - Google Chrome - Microsoft Bing - Exim - the mail server behind much of the internet. So what should you do about it? Test your systems using AI the way an attacker would. In 2018, attackers took about two and a half years to exploit a bug after it was made public. Now they often exploit it before it's public. A pentest once a year isn’t enough.

AI tools make it incredibly easy to find errors in source code. Which ones should a company fix? Many are real problems, but most large organizations can't fix, test and deploy at that speed. Here’s how to prioritize: 1. Focus on what's exploitable. Many real bugs aren't reachable, or are already mitigated by a WAF. Those can wait. The key is focusing on reproducible exploits. That’s what we focus on at XBOW. 2. Check the impact. Is sensitive data exposed? Many exploits are embarrassing. Only a few are a disaster. 3. Block it at the firewall. Add a rule that stops the payload, then check for bypasses. A rule often blocks one payload but not its equally harmful variants. 4. Investigate the logs. Did attackers find it before you? Customers are understanding when you're open about what happened and how you're fixing it. 5. Fix the root cause. Test that the fix holds up against those variants too, and doesn't break anything. 6. Deploy. Only then is the bug actually gone. At @XBOW, our mission is to help CISOs with every one of these steps.

You’re right, @Jason! This is a golden age for white hats. The bounties are real. Companies pay for confirmed bugs from whoever finds them first. What we're lacking is enough skilled hackers to check all the code being written. The way we see the market going is white hats directing teams of AI agents. Just like we did here ↓ xbow.com/blog/xbow-built-a-c…

No one explains it better than @moyix!

Thanks for the partnership @gdb, and for making terrific models like GPT-5.6 Sol available to defenders. We're proud to be part of Daybreak!