Security

Mythos and GPT-6 Astra: the end of quiet vulnerabilities

A 27-year-old bug in OpenBSD, a 16-year-old one in FFmpeg, 23,019 issues found in a few weeks across a thousand open-source projects. Frontier models now find flaws faster than anyone can fix them, and two vendors have just acknowledged it officially. What Project Glasswing, GPT-5.6-Cyber and GPT-6 Astra really say, and what an SME server should conclude from it as of Monday.

A giant lens sweeping over a city of code blocks, revealing orange cracks in several of them, while an almost empty hourglass stands in the foreground
Contents (5 sections)
  1. Project Glasswing: the figures
  2. It was not a one-off
  3. What it means for an SME server, as of Monday
  4. And these models, on the defence side?
  5. Sources

There is a silent assumption behind the security of most servers: flaws that have not been found in twenty years will not be found tomorrow. That assumption died on 7 April 2026. That day, Anthropic announced that a model placed in a sandbox with ordinary development tools, without specialised training or human guidance, had found thousands of high-severity vulnerabilities in every major operating system and browser. Five months later, OpenAI announced a model that crosses its “critical” threshold. It is time to look at what this means for an infrastructure of forty machines.

Project Glasswing: the figures #

Project Glasswing brings together twelve organisations (AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorgan Chase, Linux Foundation, Microsoft, NVIDIA, Palo Alto Networks, Anthropic) around Claude Mythos Preview, a model its vendor says “surpasses all but the most skilled humans at finding and exploiting software vulnerabilities”. The published examples speak for themselves: a 27-year-old flaw in OpenBSD, a system renowned for its hardening; a 16-year-old flaw in FFmpeg, which had slipped through millions of automated tests; chains of vulnerabilities in the Linux kernel leading to privilege escalation; a chain of four flaws escaping a browser’s sandboxes. A hundred million dollars in usage credits, and a rare decision: the model will not be released to the public. An anecdote reported by The Hacker News: during testing, the model escaped from a secure environment and posted exploit details on public websites, which the vendor describes as a “potentially dangerous capability”.

The update of 26 May 2026 gives the scale: 23,019 issues identified in more than 1,000 open-source projects, of which 6,202 of high or critical severity; out of 1,752 cases checked by Anthropic and six independent firms, more than 90% true positives. Hundreds of vulnerabilities at Cloudflare and Mozilla, a cryptographic library embedded in billions of devices. And this sentence, which sums up the problem: “the relative ease of finding vulnerabilities, compared with the difficulty of fixing them, is a major challenge for cybersecurity”. Open-source maintainers, often volunteers, receive reports faster than they can process them.

Comparison of the time between a flaw being published and being exploited: weeks in the past, twelve hours for Citrix in August 2025, less than ten minutes to write an exploit; then the chain from discovery, disclosure and exploit to your server, with the levers of monitoring, patching, minimal attack surface and detection
The window has closed upstream. What remains for a hosting provider is speed of reaction and exposed surface.

It was not a one-off #

  • July 2025, Big Sleep. Google’s agent found CVE-2025-6965 in SQLite, a memory corruption that attackers were about to exploit: the first time an AI foiled an exploitation in preparation. Twenty more flaws in open-source projects the following month.
  • August 2025, DARPA AIxCC. In the final at DEF CON, seven autonomous systems found 54 of the 70 flaws injected into real software, fixed 61% of them, with an average fix in 45 minutes, and along the way discovered 18 real, previously unknown vulnerabilities. The winning team took home $4 million.
  • June 2025, XBOW. An autonomous penetration tester became number one on HackerOne’s US leaderboard, ahead of thousands of human researchers, with more than a thousand reports in a few months.
  • August 2026, GPT-5.6-Cyber. Through its Daybreak Red programme, OpenAI released a specialised model that succeeds at 95% of tasks involving exploit chain development, privilege escalation and authentication bypass, compared with 1.5% for the general-public model of the same generation. It found a high-severity flaw in Chrome’s JavaScript engine.
  • 3 September 2026, GPT-6 Astra. The first model to cross the “critical” threshold of OpenAI’s preparedness framework: according to the vendor, it can “find unknown flaws and develop ways to exploit them on many well-protected systems without a person guiding each step”. Priority access for defenders in the Daybreak programme, reinforced monitoring, and this sentence from OpenAI’s president: “welcome to the AGI era”.

What it means for an SME server, as of Monday #

A WordPress site, a VPN gateway, a file server, a self-hosted CRM: your software stack is a subset of what these models are combing through. The flaws they find today in FFmpeg, in the kernel, in TLS libraries, are in your machines too. Patches will follow, in a continuous stream. The only question that matters is: how much time passes between a patch being published and it being applied on your systems? Our doctrine rests on four building blocks, all documented on this blog.

  1. Know within hours. A live inventory of versions on every machine (PatchMon) and a daily scan of container images (Trivy): when a CVE drops, we know the same day which machines are affected, without searching.
  2. Patch within days, while watching. No blind automation, which breaks things at night and fails silently, but a deliberate run, with a snapshot before and a check after. For exposed critical flaws, the same day.
  3. Expose as little as possible. A flaw in a service that cannot be reached from the Internet is not an emergency. Segmentation, a firewall that is really active, a single bastion for administration, ports closed by default.
  4. Detect if it happened anyway. Because a twelve-hour window will always exist. Centralised logs, alerts on SSH keys and unusual logins: that is the role of the SIEM we describe on 21 September.

And these models, on the defence side? #

The general-public version of Claude can now “discover software vulnerabilities, but not develop exploits”. We use it to review our configurations and our code before someone else does, with strict guardrails: a dedicated account, least privilege, recorded sessions, and no action in production without human approval. The big vendors do the same at their scale: that is the whole point of Glasswing. The asymmetry does not work against small players, on one condition: do not wait. The model that will find the next flaw in your CMS already exists; the only question is who will have used it first.

Inventory, monitoring, deliberate patching, minimal surface, detection: this is not a premium offer, it is the minimum we consider defensible in 2026, and it is what our managed services contain. If you do not know today how many of your servers run a vulnerable version of something, let us talk before someone else finds out for you.

Sources #

About
01/Read nextThree articles

Related articles

Security

A stale lock file is a scan that lies

Dependency lock files are the source of truth for security scans. When a build pipeline quietly rewrites them instead of failing, the scan reads the wrong versions and returns a reassuring verdict. How we found out, and what we changed.

dependenciessoftware supply chain
Security

446 vulnerabilities, then zero: what an honest inventory changes

Each machine scanned its own images, and nobody could see the fleet. By centralising the analysis on the real inventory (111 unique images instead of 25 local databases), the counter went from 446 to 0 in one evening. The story of a measurement project, not a fixing one.

vulnerabilitiescontainers
Security

Rolling out a SIEM across 38 machines: Wazuh, from sizing to tuning

A log that stays on the compromised machine is worthless. We deployed Wazuh across the whole fleet in two days: a dedicated VM, twelve-month retention, 38 agents in three waves, and above all tuning that brought the noise down from 1,250 alerts per machine to 8 for the entire fleet. The installer pitfalls, compliance checks in containers, and the home-made detections that really matter.

wazuhsiem

What next

Spot problems before they cost you?

Centralised logs, alerts, patches applied on purpose, backups actually restored. First conversation free.

Discuss your project

Reply within 24 working hours, from one of the two founders. Or by phone: +33 7 59 96 14 99.