Future historians will remember spring 2026 as the dawn of AI-driven security vulnerability reporting. On April 7, Anthropic announced a preview of its Claude Mythos AI model, made available to select companies as part of Project Glasswing. The initiative claimed it had discovered thousands of high and critical severity vulnerabilities across the open source ecosystem. Three weeks later, the Xint initiative announced a Linux kernel local privilege escalation vulnerability it named Copy Fail. A few days later, the world woke up to another vulnerability named Dirty Frag, and then another named Fragnesia. More will follow.Project Glasswing, Copy Fail, and Dirty Frag share responsible disclosure problems. Project Glasswing shared little actionable information, despite its fanfare. The researchers behind Copy Fail shared findings with kernel.org developers, but not with system vendors. Somebody prematurely leaked details behind Dirty Frag, forcing researcher Hyunwoo Kim to disclose details in a public email thread before anyone could develop patches.This blog post examines Red Hat’s response to Copy Fail and discusses how our Technical Account Management Service for Product Security can help organizations manage their security posture in this new era of rapid and relentless AI-generated disclosures.Red Hat Product Security history and backgroundThe Red Hat Product Security team has been a leader in the IT security community since 2001 and has constantly evolved with the threat landscape. CVE.org manages software vulnerability reporting across the IT industry using a concept called Common Vulnerabilities and Exposures (CVE). A CVE Numbering Authority (CNA) is a member organization that publishes CVEs. CVE.org has more than 500 CNA members across the IT industry. A CNA-LR is a CVE Numbering Authority of last resort. Member organizations rely on them to resolve disputes about CVEs. Root organizations teach other CNAs how to submit CVEs.Today, Red Hat is the only private-sector company in the world to hold the CNA-LR role, and one of only 2 private-sector companies to hold the root role. This means Red Hat holds a well-earned position of respect, responsibility, and trust across the industry. We’re often the ones in the middle, translating an arcane kernel commit into something actionable while the rest of the world chases headlines.With the rise of AI-driven security vulnerability reporting, the threat landscape isn't just evolving, it's accelerating. Mozilla recently collaborated with Anthropic to discover 22 security-sensitive bugs in its JavaScript engine, followed by 271 additional vulnerabilities in a subsequent pass that looked at the entire browser codebase. Across the broader software ecosystem, by mid-May 2026, AI-driven discovery tools, led in large part by Mythos, flagged over 10,000 potential issues, nearly a year’s worth of traditional discovery in just 2 weeks.Red Hat is in the middle of this explosion. In 2025, Red Hat Product Security triaged 7,722 security vulnerabilities. In the first 4 months of 2026—Jan. 1 through April 30—the number was 2,826, which, if that rate continued, would bring the annual total up to 8,596. From May 1 through May 15, 2026, the number of triaged vulnerabilities grew to 712, which balloons to more than 17,000 for the full year, or more than double 2025.Copy Fail: The first of many to followOn any given day, CVE.org publishes hundreds of vulnerability records. On April 22, 2026, one CNA, kernel.org, published 100 vulnerabilities, numbered CVE-2026-31431 through CVE-2026-31530. CVE-2026-31431 offers this description.“In the Linux kernel, the following vulnerability has been resolved: crypto: algif_aead - Revert to operating out-of-place This mostly reverts commit 72548b093ee3 except for the copying of the associated data. There is no benefit in operating in-place in algif_aead since the source and destination come from different mappings. Get rid of all the complexity added for in-place operation and just copy the AD directly.”This was nothing to get excited about, until a week later, on April 29, a service named Xint.io from a company named Theori posted a proof-of-concept attack and named it Copy Fail. Buried behind that arcane description was a means for any unprivileged local user, whether on bare metal, in a virtual machine (VM), or inside a container, to gain root access to a system.Fortunately, this attack requires access to the machine. An attacker needs to login first. Unfortunately, Red Hat and other Linux distributions learned about the attack the same day the public learned about it.Press articles and online threads exploded. The race was on.Red Hat Product Security immediately updated its vulnerability rating on this CVE to Important and updated its security bulletin with a mitigation strategy and remediation timeline. Red Hat delivered the first of many security advisories 5 days later, on May 4. Several more quickly followed.But the story doesn't end there.Deploying to customersBy noon U.S. Central Daylight Time on May 12, Copy Fail generated 1,132 support cases from customers running Red Hat Enterprise Linux (RHEL), Red Hat OpenShift, and Red Hat OpenStack. Later in May, that number had grown to more than 1,300 cases. Many of these support cases included detailed questions or tricky problems that can't fit into a tidy FAQ document. For example:Some organizations depend on applications with limited or no support that tend to break with operating system upgrades and patches. In this new age of fast and furious patches and upgrades, these applications present even greater risk.Questions always come up about how to use Common Vulnerability Scoring System (CVSS) scores to assess risk. The best answer is, it depends. CVSS scores assign severity levels in a vacuum. Assessing risk depends on customer specifics, and demands human judgment.How does anyone keep up with a never-ending flood of AI-flagged issues? The "patch everything" answer is a broken model. Instead of constant disruption for patching, architect your IT environment to mitigate vulnerabilities with defense-in-depth, use old-fashioned human judgment to assess which vulnerabilities actually pose a threat to your specific environment, and patch those.At least one customer needed to know how to patch OpenStack 17.1, which depends on RHEL 9.2. The answer was to use the RHEL 9.2 SAP release stream.Another customer needed to know what would happen if they used newer, patched kernels with older RHEL 8 systems. Some organizations were running old OpenShift versions and needed a patch strategy.Many needed help to coordinate patch deployment with application teams who want zero downtime.Other organizations were concerned about performance.Several needed help with risk analyses for various compliance initiatives.And in numerous cases, customers asked for official Red Hat statements of assurance for upper managers.These are just a few examples. Security scares are always stressful and we've found it valuable for someone to work directly with customers to help separate speculation from reality, especially when headlines erupt about the most alarming Linux bug in a decade. The need for a commercial partner to help bridge the gap between upstream innovation and enterprise-grade security protections has never been more clear.Red Hat Technical Account Management Service for Product SecurityTo help handle security situations like this, Red Hat now offers Red Hat Technical Account Management Service for Product Security. Technical Account Managers (TAMs) act as communication liaisons between customers and product and engineering groups across Red Hat and the open source community. While most TAMs focus on a particular product or technology, Red Hat security TAMs focus holistically on security footprints across the Red Hat product portfolio. These TAMs help with:Sharing ad hoc education about various attack tacticsHelping customers use Red Hat security and compliance toolsSuggesting hardened configurations and deployments as appropriateExplaining how Red Hat helps reduce risk and mitigate vulnerabilitiesProviding more accurate vulnerability analysis for Red Hat productsAssisting in triaging vulnerability scan reportsFacilitating communication with customers, Red Hat teams, partners, other vendors, and the open source community where feasibleInfluencing Red Hat product management, product security teams, partners, other vendors, and the open source community by representing customer points of viewFostering awareness about the software value chain and supply chain attacksAdvising on potential mitigations in the face of major security incidentsHelping produce post-mortem security incident assessmentsOngoing communication is always critical, especially during a crisis, and even more so as AI increases the speed and severity of security vulnerability reports. Red Hat security TAMs are uniquely positioned to help customers discern noise from reality and address other concerns. Peace of mindIn this new age of AI-driven vulnerability reports, the biggest threat isn't just the volume of bugs, it's overreliance on automation. AI can find vulnerabilities, but it can’t provide a risk-based security strategy or deliver the integrity required to stand by your organization during a crisis. Human judgment remains the only thing you can truly count on. Breakdowns in responsible disclosure processes present another threat, because any time somebody discloses a new vulnerability before developers can release a mitigation or a patch, they enable attackers to blindside customers.Nobody can promise full immunity to attacks, but Red Hat security TAMs can help by closely coordinating with Red Hat Product Security and the community to help provide the strategic guidance and technical advocacy that AI can't provide. The ability to discern the difference between hype and reality, or gain a few hours early warning of an imminent attack, might mean the difference between applying a just-in-time mitigation and a disaster. Don't wait for the next major disclosure to protect your infrastructure. Learn more about how a Red Hat security TAM provides the proactive planning and technical advocacy your organization needs.Contact your Red Hat account team to learn more, or contact Red Hat. Find these numbers by navigating to the human-readable Red Hat CVE database, selecting an appropriate date range, and looking at the count at the bottom of the page.