I want to talk about AI hacking. There are three aspects: people hacking AI systems, people using AI to hack other systems, and AIs hacking systems on their own, not even maliciously. The last two matter more than the first. The third is the weirdest and potentially the most destabilizing.

I started writing about this in 2021 and in my 2022 book, A Hacker’s Mind. Back then I said it was mostly still science fiction, but not stupid science fiction. We’re seeing it more and more, especially in the past year. The trends I’m describing don’t require a major breakthrough in AI. They’re starting to happen now, and they’ll happen more often as AIs get better at autonomous problem-solving. And it will involve far more than computer code.

AI will hack all sorts of social, economic and political systems. It will find vulnerabilities and exploit them. This is a difference in kind, not just degree. We’re not ready for it, and we need to think about the implications now.

This article is adapted from a keynote speech delivered at the DEF CON 34 conference in Las Vegas on August 7, 2026.

First, I want to broaden the term “hacking.”

The tax code isn’t computer code, but it is code. It’s a series of algorithms with inputs and outputs. It has vulnerabilities, which we call loopholes, and exploits, which we call tax avoidance strategies. Black hat hackers exploit them for profit. We call them accountants and attorneys.

What is a hack? One definition: “Something that a system permits, but is unanticipated and unwanted by the designers.” It’s subjective and implies novelty and cleverness. A hack follows the rules of a system but subverts its goals or intent, just as a software hack follows the logic of code while doing something its authors neither anticipated nor wanted.

All systems of rules can be hacked, including professional sports, customer reward programs, financial systems and politics. Hacks even work against our cognitive functions. A curved hockey stick is a hack, and we know the name of the man who invented it. Mileage runs were a hack. The filibuster was originally a hack in Roman times. Gerrymandering is a hack. Hedge funds and private equity are full of them.

A system is just a set of rules or norms, and the rules aren’t always formal. Even the best-designed rules will be incomplete, inconsistent or ambiguous. As long as people want to subvert a system’s goals, there will be hacks.

AIs are becoming hackers. After decades of slow progress, they’ve gotten very good at finding and exploiting vulnerabilities in computer code. They do this largely autonomously, and they’re getting better scarily fast. But the implications extend far beyond software, to the tax code, financial regulations and all sorts of social, economic and political systems.

There are two distinct issues. First, someone might instruct an AI to hack one of these systems, feeding it the world’s tax codes or financial regulations to find profitable loopholes. Second, an AI might hack a system on its own, inadvertently. Both are dangerous, but the second is worse because we might never know it happened.

Now, reward hacking. AIs don’t solve problems the way people do. They stumble on solutions we never anticipated, and some subvert the intent of the system. They don’t share our context and don’t necessarily understand the implications, norms and values we take for granted.

Reward hacking is when an AI achieves a goal in a way its designers neither wanted nor intended.

Early pre-LLM examples are telling. In a two-person soccer simulation, an AI learned that kicking the ball out of bounds forced the opposing goalie to throw it in and leave the goal undefended. In a stacking simulation, an AI learned to flip a block upside down rather than stack it. In an evolution simulation where the goal was to cross a distant finish line, an AI made itself tall enough to fall over the line instead of growing longer legs or stronger muscles.

These are all hacks, the result of poorly specified goals or rewards. Today, they’d come from bad prompting.

The problem is universal. One researcher tried to teach a robot vacuum not to bump into things. Instead, it learned to drive backward, because there were no sensors in the back.

Any capable AI will find hacks wherever the rules have problems, inconsistencies or loopholes that still produce an acceptable solution. We see a hack because we understand context. The AI doesn’t, at least not in the same way.

This problem shows up often in myth.

In the story of King Midas, the god Dionysus grants him a wish: everything he touches turns to gold. Midas ends up starving when his food, drink and daughter all turn to gold. It’s a specification problem. He programmed the wrong goal.

In the Golem of Prague, a ghetto animates a clay statue to guard its residents. It guards them past all reason until they figure out how to turn it off. This is a guardrail problem. The villagers never limited the golem’s actions.

More generally, think of this as the genie problem. Genies are precise about the wording of wishes and can be maliciously pedantic when granting them. There’s no way to outsmart a genie. Whatever you wish for, he can grant it in a way you wish he hadn’t.

The reason is that in human language and thought, goals are always underspecified. We never include every caveat, exception and proviso, and we never close off every avenue for hacking. Any goal we specify will be incomplete. That’s largely fine in human interactions, because people understand context and usually act in good faith.

If I asked you to get me coffee, you’d pour a cup from the nearest coffee pot or walk to the corner shop. You wouldn’t bring me a pound of raw beans, buy a coffee plantation or snatch a cup from a stranger’s hands. I wouldn’t have to specify any of that. You’d just know.

Similarly, if I asked you to develop a technology that turns things to gold on touch, you wouldn’t build it to starve the person using it. You’d just know.

In 2015, Volkswagen was caught cheating on emissions tests. Human engineers programmed a regular computer to detect testing and behave differently during it. The cheat went undetected for years because it’s hard to tell what software is doing.

If I asked you to design engine control software that maximizes performance while passing emissions tests, you wouldn’t design it to cheat without realizing you were cheating. An AI would, because it will think “outside the box” when it has no concept of the box.

Unless programmers specify that the system must not behave differently during testing, an AI might come up with the same hack. The programmers would be satisfied, the accountants would be ecstatic, and no one would know until someone audited the code.

We can now constrain the goal to avoid that particular hack, but programmers won’t anticipate others. The lesson of the genie is that there will always be hacks programmers don’t anticipate.

We’re building AI genies: systems that take broad instructions and figure out how to carry them out, sometimes in ways we didn’t expect or intend. That’s the whole point of vibe coding. You underspecify what you want and let the AI work it out. Sometimes that produces genie behavior.

We can’t completely specify goals to an AI, and AIs can’t fully understand context. More precisely, current AIs have a shallow grasp of concepts. If we asked a current LLM to get me coffee, it would almost certainly do the right thing.

I worry about goals that aren’t well represented in training data, and about hacks that aren’t obvious, whose effects are subtle, like the Volkswagen hack.

Recommendation engines are an early example. They push people toward extreme content. No one programmed that. It emerged because that’s what people respond to. It didn’t take a bad actor. A basic automated system with feedback found the hack on its own.

We’re now seeing a second generation with today’s AI coding systems. AI researcher Simon Willison asked Fable to track down a stray scrollbar in a web app. When he returned, it had opened browsers, written its own screenshot tools, edited the framework’s internal templates to make the bug appear on cue and set up a local web server to collect measurements. It found the bug, but it also did many things he never asked for. Another researcher gave Fable a complex task, and it tried to hack its own memory limits because it needed more storage.

A new OpenAI model did something similar when it hacked into Hugging Face. It was being benchmarked on its ability to turn vulnerabilities into exploits. It decided the best way to reach its goal was to break out of its containment, access the internet and break into the Hugging Face network, because it thought the answers would be there.

Today’s LLMs are acting like genies, especially when powerful models are combined with sophisticated harnesses.

There are two kinds of genies. The Dionysus genie does the wrong thing. It understands your prompt literally but not correctly, and returns a mess you never intended. The Golem genie does the right thing but tramples everything in its path to get there. The paperclip maximizer is a Golem genie.

Consider some examples. Ask an AI to deal with spam calls, and a Dionysus genie might change your phone number. Ask it to book a particular flight, and a Golem genie might hack the airline database because the flight is full. Ask it to get a refund for an online purchase, and a Dionysus genie might draft a legal threat on fake letterhead and send it to the company. Ask it to buy tickets to a popular concert, and a Golem genie might discover the ticketing system is rate-limited and spin up thousands of cloud servers to hammer it. You’d know if some of these things happened, but you might never realize if others did. More detailed prompting won’t fix this. The lesson of the genie is that no amount of detail is good enough.

AI researchers aren’t surprised by any of this. Many are working on defenses against reward hacking and subtler forms of genie behavior. Some of this falls under “value alignment”: How do we teach AIs context? And how an AI satisfies a goal matters as much as whether it does. I want to build a benchmark to measure genie-like behavior, so we know where models stand and whether alignment is improving.

Think beyond LLMs and computer code. Consider specialized AIs built to find loopholes, and hacks of more general systems: the tax code, financial regulations and democratic procedures.

Financial systems are the most likely first target, because their rules are designed to be algorithmically tractable. High-frequency trading is itself a hack. Imagine giving an AI all of the world’s financial laws, plus all the news and financial data, and the goal of finding profitable loopholes. I suspect large investment banks are already doing this. The results will be novel tricks that are legal but unintended and unwanted, some of which might break the financial system.

Tax loopholes are the next likely target, for the same reasons. For a while, AIs will identify potential loopholes, and human hackers, namely attorneys and accountants, will decide which are feasible.

Further out, expect hacks of regulatory, legislative and procedural systems, and of the broader economy.

Hacking is as old as humanity. We’re creative problem solvers and loophole exploiters. We manipulate systems to serve our interests and strive for more influence, power and wealth.

Still, no human pursues their interests without constraint. Even sociopaths are limited by the complexity of society and their own contradictory impulses. They worry about their reputation and punishment, and they have limited time. These human qualities have limited hacking.

Hacking changed as everything became computerized. Computers are uniquely hackable because of their formalism and complexity. Today, nearly everything is a computer, from cars and appliances to phones. Our social, economic and political systems, including taxation, finance and elections, all involve computers.

Until recently, hacking was exclusively a human activity. Finding a novel hack required expertise, creativity, time and luck.

AI hacking will change everything again. AIs aren’t bound by the constraints that limit people. They’ll think like aliens, and they’ll change hacking’s speed, scale, scope and sophistication, sometimes at our direction and sometimes on their own.

Speed is the easiest to see. A creative process that takes a human months or years could be compressed into hours or seconds.

Scale is next. Once AI systems start discovering hacks, they can exploit them at a scale we’re not ready for. We already see this with AI-generated slop, which is rampant on social media. AI bots post around the clock, sometimes overwhelming real human discussion. It’s hard to know how much of social media is still people talking to people. What looks like boisterous political debate may be bots arguing with other bots, artificially shaping what we think and what we think others think.

Scope makes hacks more dangerous. AIs already make decisions that affect our lives, decisions we once thought belonged only to humans. As AI systems grow more capable, society will hand them more decisions, and more important ones. Hacks of these systems will do more damage.

Finally, AI hackers are more sophisticated. They can hold more variables in working memory and generate more complex hacks. What might happen if you fed an AI the entire U.S. tax code? Would it figure out, without being told, that it’s smart to incorporate in Delaware and register a ship in Panama? Consider the Double Dutch Irish Sandwich, the strategy Apple and Google used to avoid paying U.S. taxes. It involves U.S., Dutch and Irish law and an offshore tax haven. How many loopholes will an AI find that we don’t already know about? Dozens? Hundreds? Thousands? We have no idea.

These hacks will largely be perpetrated by the powerful against the rest of us. AI is fundamentally a power-enhancing technology, and so is hacking. The more power you already have, the more a hack gives you. If you or I found a tax hack, we might make a few thousand dollars. If a large investment bank found one, it and its clients could make billions.

Our societal systems for dealing with hacks were built when hackers were human, and they reflect the pace of human hacking. We have no system of governance that can handle hundreds, let alone thousands, of newly discovered tax loopholes. We won’t be able to recover from an AI finding unanticipated but legal hacks of financial systems, operating at AI speed, scale, scope and sophistication. Hacking becomes a problem society can no longer manage.

Now, defense. AIs that find software vulnerabilities help defenders as well as attackers. Vulnerabilities can be patched, removing them permanently, or turned into signatures that security systems use to detect and block attacks. In theory, AI could identify and patch every automatically discoverable vulnerability before a product ships. This is rapidly becoming routine in software development. We call it vulnops. We can imagine a future where accidental software vulnerabilities are a thing of the past.

Deliberate vulnerabilities are different. There will be an arms race. AI will craft increasingly obscure back doors, and AI will find them. It becomes a contest between the speed of creation and the speed of patching, and between obfuscation and reverse engineering.

The same logic applies to broader systems. Yes, AI hackers might find hundreds of vulnerabilities in the existing tax code. But the same technology can evaluate potential loopholes in any proposed tax law or ruling. A legislator, a watchdog group or a reporter could take the text of a bill and identify every exploitable loophole before it passes. The difference is that, unlike software, knowing about a tax loophole doesn’t mean it gets patched. In theory, though, we can fix them before the rich and powerful exploit them. So maybe defense will come out ahead here, too.

That requires resilient governing structures that can respond quickly. It won’t help if updating the tax code takes years, or if a legislative hack becomes so entrenched that it can’t be fixed politically. Maybe a lobbyist put it there on purpose. Maybe it was discovered after the law passed, and now lobbyists want to keep it. Microsoft can patch the vulnerabilities it finds. Patching is much harder when legislatures have to do it. We need society’s rules and laws to be as patchable as our computers.

This is a hard problem of modern governance, and it goes well beyond AI. It’s the problem of building governing structures for the speed and complexity of the information age.

The umbrella idea is trust. What do we need for AI systems to be truly trustworthy? Capability isn’t enough.

AIs won’t be trustworthy if the companies controlling them spy on us or subtly manipulate us. I call this the friend vs. tool problem. Will we have AI agents, or AI double agents?

AIs won’t be trustworthy if they’re insecure. How do we know they haven’t been manipulated? Almost all AIs operate in adversarial environments, so someone will benefit from hacking them. Unless we know they’re secure, we shouldn’t trust their output.

And AIs won’t be trustworthy if they act like genies. We need to know they’ll perform tasks the right way, not just perform the tasks we ask for.

I’ve written extensively about the need for “integrous” AI, including how to think about the problem, what a research agenda looks like and what good laws and policies look like. I predict integrity will be the key security problem of this decade, just as confidentiality was the key problem of the last one. This applies to both AI and the internet of things.

The big shift is agency, which I think of as Web 3.0. Computers now affect the physical world directly and with growing autonomy. Sensors go from data sources to attack surfaces, and actuators go from outputs to attack capabilities. An integrity failure no longer means bad spreadsheet data. It means the wrong dosage, the wrong valve position or the wrong braking distance.

Integrity isn’t one thing. I break it into input integrity, processing integrity, storage integrity and contextual integrity. Each is complex and important, and each deserves its own talk. I’ve written about them, and I hope you’ll read it.

Much of this isn’t really an AI problem. It’s not a technical problem so much as a capitalism problem or a democracy problem.

The failures of late-stage capitalism and democracy in the information age both stem from the rich and powerful getting too good at hacking our social, economic and political systems. This is the core argument of my 2021 book.

Seen this way, AI is exacerbating existing problems. Human inefficiency has largely kept those problems in check, and that won’t work much longer.

So consider this a call to action. Technically, we need to understand how AIs hack systems, build systems that are resilient to hacking and build AIs that won’t act as genies. Politically, we need to learn to govern and regulate at the speed of technology. Otherwise, market failures will overwhelm our ability to govern them.

I said hacking is as old as humanity and that AIs will overwhelm our ability to deal with it. The solutions aren’t specific to AI, but AI makes them more urgent. We need to understand them, and we need to implement them.

The post AI doesn’t have to go rogue to break the world appeared first on CyberScoop.

Alarm bells ratcheted up yet again about an AI-discovered vulnerability that could — if exploited in the wild — destabilize vast stretches of the internet. 

The critical defect — CVE-2026-111497 — affects the Google-developed Brotli decompression library that’s bundled into many components, applications and cloud services riding on open-source software. The buffer overflow vulnerability, which OpenAI Codex Security discovered and Node.js disclosed in a Oct. 21 security advisory, can trigger system crashes and remote code execution. 

Researchers haven’t observed any active exploitation of the defect in real networks, but concerns are mounting. Multiple vendors and software packages, including Microsoft and Python, that rely on vulnerable versions of Brotli have rushed emergency patches out to address the risk of exploitation in their respective systems.

Wiz researchers warned that “91% of cloud environments have resources vulnerable to CVE-2026-111497 and 82% of cloud environments have publicly exposed Node.js instances.”

The attack surface is “extremely broad and vast, but much of the impact of exploitation depends entirely on its implementation and how it is used within that piece of software,” said Jake Knott, head of threat intelligence at watchTowr.

Christiaan Beek, vice president at Rapid7 Intelligence, said the Brotli vulnerability is especially concerning because it’s effectively hiding out in the open, as are many open-source software libraries.

“Most businesses have no idea how deeply components like Brotli are embedded in their technology. A vulnerability in a compression library sounds almost boring until you realize it could affect applications your business depends on every day,” he said. “That’s the uncomfortable reality of modern software: a small component can create a very large business risk.”

The defect, dubbed “Node2Shell” or “Broccoli2Shell,” is the latest in a series of vulnerabilities that have provoked an emergency response. Defenders and researchers were on heightened alert last week over a pair of critical PHP vulnerabilities dubbed “PHP2Shell” that also have yet to be exploited in the wild as of Monday afternoon.

These cyclical and increasingly recurring so-called emergencies are putting organizations and defenders at a significant disadvantage. 

“After being part of numerous channels and message threads full of defenders trying to discern what’s real and what’s BS over the past several months — and especially the past week — I can say unequivocally that the human cost of these events is real, pronounced, and will have downstream impacts far beyond what the community can immediately predict,” Caitlin Condon, vice president of research at VulnCheck, told CyberScoop.

“None of this — high-profile vulnerability disclosures, the overblown exploitability assumptions, the community arguments, the race to weaponize — is new,” she added. 

“What’s changed now is that AI is pumping out complex — and often not clearly explained — finds at a much higher rate, exponentially increasing noise levels and making it much more difficult both to debunk overhyped vulnerability discoveries and to determine which vulnerabilities are broadly exploitable in real-world production configurations.” 

Researchers acknowledge the additional stress defenders and organizations are in because of this always-in-emergency mode.

“We’ve reached a point where everything seems to be an emergency. And when everything is critical, businesses risk losing sight of what actually matters,” Beek said. “The real cost isn’t just patching. It’s the constant disruption to operations, the diversion of resources, and the difficult decisions about which business systems deserve immediate attention.”

Experts also consider this the new normal as more high-impact vulnerabilities with far-reaching potential consequences are found. 

“We suspect in the very near future, defenders may lose the ability to tell what is a true emergency versus a loud and prevalent vulnerability in a ubiquitous product or library,” Knott said. 

Experts advise organizations to focus on their specific risk, weighing the Brotli vulnerability’s potential impact in their environment. 

“Attackers don’t care about CVSS scores,” Beek said. “They care about what they can compromise, disrupt, or monetize and that’s exactly how we should prioritize our defenses.”

The post Experts temper emergency-level alarms over critical Brotli defect appeared first on CyberScoop.

Flock, the controversial public safety company entangled in controversy amid recurring law enforcement abuse of its products, gained authority to assign CVE IDs to vulnerabilities in its own products and grade those defects as a CVE Numbering Authority.

The manufacturer of various surveillance systems, including automated license plate readers (ALPRs) and AI-powered cameras, said it joined the global footprint of more than 550 CNAs to assess, coordinate and prioritize response to vulnerabilities internally.

“It allows us to move faster when researchers report findings, eliminate confusion from duplicate or conflicting vulnerability entries and give our customers a single, trusted source for security information about our products,” Chris Castaldo, chief information security officer at Flock, said in a statement. 

Security experts acknowledge that many vendors are granted CNA authority for good reason. Separately, Flock’s business has drawn considerable public and legal scrutiny over privacy concerns, along with multiple reports of police abusing the technology.

Controversies stemming from such misuse have impacted Flock’s credibility and could cloud how security researchers view the company as a CNA. The development also highlights the limitations of the CVE program, including what constitutes a vulnerability. 

“The measure of Flock as a CNA is whether its records give cities, police departments, and the public enough detail and accuracy to let people track specific risks by product version, the nature of the vulnerability, and ideally how to mitigate or fix it,” Katie Moussouris, founder at CEO at Luta Security, told CyberScoop.

Flock declined to answer questions or make an executive available for an interview, and instead referred back to a blog post.

The company published its vulnerability disclosure policy in August and recently created a security advisories page where it will publish all newly discovered and confirmed vulnerabilities going forward.

Zach Edwards, a security and privacy researcher, noted that numerous activists have done technical teardowns of Flock’s products and said he expects some researchers to continue disclosing Flock vulnerabilities without coordinating with the company.

Researchers last year reported multiple defects in Flock’s license-plate reader and gunshot detection system, which the company submitted for inclusion in the National Vulnerability Database, but deemed not material because the vulnerabilities require physical access to the device. 

“These cameras sit on poles on public streets,” Moussouris said.

Because CNAs are “essentially grading their own homework,” as Edwards put it, credibility and trust have to be earned consistently by properly addressing every defect that meets a reasonable threshold.

“Vendors make sense as CNAs for their own products if they can be trusted to maintain accurate records. They know the code, they can confirm the flaw, and they can tie the record to affected versions and the fix,” Moussouris said. 

“The conflict of interest manifests when they lack the organizational and technical maturity to correctly assess the flaws and their impact,” she added. “A vendor in the CNA role writes the description and often sets the severity score, so an immature vendor may inaccurately represent an issue, either through ignorance or in a misdirected effort to downplay it.”

Flock’s vulnerability disclosure policy specifically disallows testing against live customer deployments, accessing law enforcement or investigative data, physical attacks, denial-of-service testing or social engineering. The company does not run a paid bug bounty program.

“Flock stands out as a CNA because its products track drivers’ movements, its customers are police, and its policy reserves the right to hold back publication if it decides disclosure would create a safety risk to law enforcement or the public,” Moussouris said. “The latter may lead to an abuse in their authority and control of CVEs unless they embrace a more mature customer-safety-first stance of timely, transparent, and accurate vulnerability disclosure.”

Edwards is also dubious about Flock’s position as a CNA, but adds that many vendors, including some offering similar products, are already in the program. 

There are also relatively few norms in how CNAs operate because the responsibility ultimately comes down to each participating vendor. Some companies granted CNA authority are incredibly active while others haven’t publicly disclosed vulnerabilities in their products for years.

“Only time will tell how Flock operates their CVE program and if they issue CVEs for vulnerabilities publicly disclosed,” Edwards said. “But, if their recent history is any indication, they will probably screw it up in some epic way that somehow unites people across the United States to demand CVE issuing reform.”

The post Flock can now issue CVEs for its own products. Should we trust it? appeared first on CyberScoop.

Anthropic announced a new program Thursday that will combine its AI tools with outside cybersecurity companies to find and fix cybersecurity vulnerabilities in critical infrastructure and open-source software.

Advertised as part of a new, “long-term commitment” to cybersecurity, the critical infrastructure defense program will pair Claude models, Anthropic engineers and threat research with the expertise of cybersecurity companies, including Accenture, Booz Allen, CrowdStrike, Deloitte, Dragos, Hitachi, Insane Cyber, Nozomi Networks, Palo Alto Networks, PwC, and Rockwell Automation.

“Defenders of critical infrastructure and the [open-source software] community have decades of security experience but have faced severe resource shortages that are exacerbated by this moment,” Anthropic wrote in a blog post. “We are recognizing their expertise in these domains and offering our support.”

Anthropic said it has offered frontier models and technical support to more than half the states in the U.S., as well as large operators of critical infrastructure to scan and patch code or assist in incident response and red teaming activities.

“Critical infrastructure is hard to defend in many ways that AI cannot fix, but we believe that frontier models can help find and repair weaknesses before those weaknesses are used to cut off power or make water unsafe, the company wrote. “Our first step is to work with a small cohort of providers to learn which strategies are most effective and practical.”

The company said it has engaged in similar work with maintainers of large open-source software projects, and some organizations asked for everything the model had found in their software, even unreviewed findings.

That spurred Anthropic to create a new opt-in scanning service for open source software, where organizations can get free, periodic scans of their projects with a proof of concept, explanation and suggested patching options. Anthropic noted that under this program, organizations will receive their reports faster but they may contain inaccuracies.

The long-term goal is to automate most triage and patching and develop new security architectures and coding standards.

As AI models have developed increasingly powerful cybersecurity capabilities, such as finding and exploiting known vulnerabilities, frontier AI companies have worried that bad actors could gain access to the tools faster than legitimate organizations. Anthropic and OpenAI have since both started programs funneling their tech to businesses and governments, free of charge, for defensive cybersecurity.

The post Anthropic rolls out program for ‘long-term commitment’ to secure critical infrastructure, open source software appeared first on CyberScoop.

Citrix customers just got through back-to-back weekends filled with varying levels of uncertainty and worry, as yet another actively exploited zero-day vulnerability was discovered in Citrix NetScaler products.

Researchers and security experts said the vulnerability — CVE-2026-88779 — is less concerning because exploitation triggers denial of service and only impacts instances that have SAML (security assertion markup language) enabled. 

“This means it doesn’t work out of the box against every NetScaler deployment,” Jake Knott, head of threat intelligence at watchTowr, told CyberScoop. “While this is very inconvenient, it doesn’t have organizations scrambling to trigger incident response.”

Citrix was much quicker and consistent in alerting customers to the emerging threat Friday, and followed up the next day with a more detailed blog post and security advisory that contained a patch for the high-severity defect. 

“After we were alerted to this issue we immediately developed and published a mitigation while concurrently developing, testing and deploying a fix,” a company spokesperson said in a statement. “The fix for this issue is available, and we urge all customers to quickly apply it to their NetScaler instance.”

The Cybersecurity and Infrastructure Security Agency added the defect to its known exploited vulnerabilities catalog Sunday.

The vendor’s response also provided some relief for customers and researchers who spent much of the previous weekend rushing to assess widespread rumors of other defects in the assailed network edge gateways. In that case, Citrix took most of the weekend to confirm attackers were actively exploiting a pair of NetScaler zero-days, some of which researchers said remained undetected for at least three weeks.

“Citrix did a better job with their response to this vulnerability,” and took steps that enabled customers to make their own risk-based decisions with more currently available information, said Joe Toomey, vice president of underwriting security at insurance provider Coalition. 

“Although it’s difficult to celebrate given this is the third publicly-exploited NetScaler zero-day vulnerability in a two-week window, it is a step in the right direction,” he added. 

Citrix declined to say how many customers are impacted by the latest zero-day or when the first instance of exploitation occurred. Yet, Knott at watchTowr said exploitation likely began Friday. 

The newer defect doesn’t share any technical links with the pair of zero-days Citrix disclosed less than a week prior, but it can accelerate one of those vulnerabilities — CVE-2026-88771 — by intentionally crashing machines to speed up exploitation, Knott said.

While risk is currently perceived low for CVE-2026-88779, it is “incredibly simple to trigger, with a single specially crafted request being all that is needed to knock an appliance offline,” Knott added. “Exploitation is already occurring in the wild, and disrupting an authentication gateway can prevent legitimate users from accessing the services behind it.”

Toomey also described the denial-of-service vulnerability as less serious than the previous week’s actively exploited zero-days. Yet, he noted, exploitation attempts of CVE-2026-88779 “clearly contain shellcode that implies that the threat actor believes they can use this vulnerability, or chain it with another vulnerability, in order to achieve remote-code execution.”

The post Citrix discloses third actively exploited NetScaler zero-day in less than a week appeared first on CyberScoop.

Citrix took most of the weekend to confirm that attackers were actively exploiting the newest round of NetScaler zero-days, leaving network defenders and threat hunters to react without official confirmation. 

Yet, behind the scenes, multiple CERTs, advisory firms, insurance providers, researchers and chatty security professionals warned their respective peers and communities of a live and serious threat. 

Nearly two days after the first unconfirmed rumors, Citrix published a security advisory Sunday disclosing the exploited zero-days, CVE-2026-88771 and CVE-2026-88772, releasing patches for them and six additional defects.

By then, criticism was at a fever pitch, and for some NetScaler customers the warning came too late. 

“The information vacuum was most striking. Customers were receiving warnings through unofficial channels while Citrix remained publicly silent,” Ben Harris, founder and CEO at watchTowr, told CyberScoop. 

“Customers were left without communication, guidance, or even acknowledgement that the vulnerability that was rumored to exist was real. Citrix could have warned customers that active exploitation was occurring and provided immediate defensive guidance without disclosing technical details that would help attackers,” he added. 

“When active exploitation is underway, hours matter,” Harris said.

Citrix did not directly answer questions about the lengthy communication delay. 

“We recently identified critical vulnerabilities in Citrix NetScaler ADC and Citrix NetScaler Gateway that led us to immediately develop and release a new version of the software that addresses the issues,” the company said in a prepared statement.

The critical defects are both rated 9.5 on the CVSS scale and allow attackers to achieve remote code execution. 

Researchers are particularly concerned about CVE-2026-88771, a command-injection vulnerability that affects all NetScaler appliances in a default configuration. That gives attackers a broad pool of targets and a better chance at successful exploitation. A proof-of-concept exploit for the vulnerability is also publicly available. 

Palo Alto Networks said it identified more than 50,000 publicly exposed instances of Citrix NetScaler devices potentially vulnerable to both of the zero-days as of Sunday. 

The earliest known exploitation attempt occurred Sept. 24 when GreyNoise said it observed an unsuccessful exploitation attempt against a Citrix NetScaler Gateway under its control for malicious activity scanning purposes. But researchers warn that exploitation likely started before then.

Citrix did not say how many customers have been compromised thus far and researchers are still assessing the fallout.

Citrix said it is making generic indicators of compromise available to customers in their user consoles, and the company referred to previously issued guidance for customers who suspect compromise. 

Attribution for the attacks is also still under investigation, yet NetScaler products are a common, recurring target for financially-motivated cybercriminals and state-sponsored espionage groups. 

The Cybersecurity and Infrastructure Security Agency issued an alert Sunday after Citrix publicly confirmed the attacks on its customers, and added CVE-2026-88771 and CVE-2026-88772 to its known exploited vulnerabilities catalog. The vendor has appeared on the agency’s list of vulnerabilities known to be exploited five times this year, and a total of 26 times since late 2021.

Security leaders across the industry — including Charles Carmakal, chief technology officer at Mandiant Consulting, and Wendi Whitmore, chief security intelligence officer at Palo Alto Networks — also sprung into action Sunday, with direct warnings on LinkedIn about the urgent threat. 

The information vacuum that persisted through most of the weekend put cybersecurity professionals in sometimes unique positions. Joe Toomey, vice president of underwriting security at insurance provider Coalition, said the company notified potentially vulnerable customers with limited official data and no confirmation from CISA or Citrix.

In a LinkedIn post Sunday, he called Citrix “unconscionably irresponsible” for remaining silent for more than 36 hours after word began circulating about in-the-wild exploitation.

“I fully understand a vendor embargoing specific details about a vulnerability when a patch has not yet been published, but once the vuln is exploited in the wild, some of those rules no longer apply,” Toomey wrote.

Citrix and its customers are in familiar territory. The vendor’s products have been widely targeted in previous attack sprees, often involving zero-day exploits and some infamously referred to as CitrixBleed and CitrixBleed 2.

“Citrix has a history of delaying the publication of vulnerabilities, even when they’re being exploited in the wild and affecting customers. Citrix eventually released patches and an advisory, but an adequate response also requires timely, clear communication,” Harris said. 

“Customers shouldn’t have to rely on unofficial warnings, security researchers, and third parties to learn that critical infrastructure may already be compromised,” he added. “This latest incident raises serious questions about whether Citrix has learned from previous crises and meaningfully improved how it protects and informs customers.”

The post Citrix patches actively exploited NetScaler zero-days after a weekend of unofficial warnings appeared first on CyberScoop.

SonicWall customers are grappling with yet another pair of actively exploited zero-day vulnerabilities in SonicWall SMA 1000 appliances, a product that’s been besieged with recurring defects and attacks over the past nine months. 

The vendor disclosed and released patches for the defects — CVE-2026-83548 and CVE-2026-83549 — and noted both were already actively exploited in the wild in a security advisory Tuesday. The Cybersecurity and Infrastructure Security Agency added the defects to its known exploited vulnerabilities (KEV) catalog Wednesday. 

SonicWall customers have confronted a barrage of actively exploited vulnerabilities in SonicWall devices for years. Attackers have consistently exploited newly discovered zero-days and years-old defects in the vendor’s products to break into victim environments.

Rapid7 researchers said the new zero-days — a max-severity pre-authentication server-side request forgery vulnerability and a high-severity OS command injection vulnerability — can be chained together to achieve unauthenticated remote-code execution. 

SonicWall did not say how many customers have been directly impacted by active exploitation or when the first known instance of exploitation occurred. The company did not respond to a request for comment.

“Please stop us if you’ve heard this one before: Another appliance sitting at the edge of the network, another pair of vulnerabilities chained together, and another unauthenticated path to complete compromise,” Jake Knott, head of threat intelligence at watchTowr, said in an email. 

“SonicWall says these vulnerabilities were internally discovered, while also saying it investigated a case indicating active exploitation. Please pick one, or, at minimum, explain how both are true,” Knott added. “Those statements may be technically accurate, but without that context, the disclosure leaves defenders guessing about when and how the vulnerabilities were actually identified.”

The vendor’s security advisory did not include indicators of compromise. It urged customers to contact tech support for assistance in reviewing IOCs and hunting for potential signs of compromise, and if detected, to reimage or redeploy the appliance, change all user and administrator passwords and reset tokens. 

SonicWall did not attribute the known exploits to a specific threat group or describe the attacker’s motivations.

The freshly disclosed pair of vulnerabilities are the latest in a series of security issues confronting the vendor’s customers, including actively exploited zero-days, previously disclosed defects, and an attack last year that allowed a state-sponsored threat group to steal the firewall configurations of every SonicWall customer. 

In late July, Huntress researchers spotted an attack spree that compromised 30 SonicWall customers in less than two days. Earlier that month, the company acknowledged another pair of zero-days that were exploited for three weeks before the vendor disclosed and patched the defects.

Ransomware groups, including INC ransomware and Akira, have taken a special interest in SonicWall. Ten of the 19 SonicWall defects added to CISA’s KEV catalog since late 2021 are known to be used in ransomware campaigns.

The five defects added to CISA’s KEV most recently, since just mid-December 2025, all impact SonicWall SMA 1000 appliances.

The post Attackers exploit zero-days in consistently besieged SonicWall product appeared first on CyberScoop.

NATO’s cyber defense arm and a startup that uses artificial intelligence to find software flaws can now issue the ID numbers the industry uses to track those flaws, the European Union Agency for Cybersecurity announced last week. 

The NATO Cyber Security Centre, part of the NATO Communications and Information Agency, and AISLE, a cybersecurity company with offices in San Francisco and Prague, joined as CVE numbering authorities under the ENISA Root. The CVE program assigns a unique record to each publicly disclosed security flaw so that governments, vendors and researchers have a common marker when referring to particular vulnerabilities. 

Twenty numbering authorities now sit under the ENISA Root, with 12 brought in by ENISA itself and eight moving over from the MITRE Root, run by the U.S. nonprofit that has handled the program’s daily work for more than 20 years.

Hans de Vries, ENISA’s chief cybersecurity and operations officer, linked the growth to changes in how people find flaws. 

“Recent developments in the global cybersecurity landscape, coupled with the emergence of Frontier AI models and their impact on vulnerability discovery and exploitation, have underscored the need to build strong vulnerability management infrastructure and capabilities,” he said in a statement. He said ENISA’s role helps build a “more globally representative, resilient, and scalable vulnerability identification ecosystem.”

The two new members show how bespoke each member is within its authority. The NATO Cyber Security Centre can now assign CVE IDs to eligible flaws across the NATO enterprise. The agency said that will make tracking more consistent and let the alliance share information with trusted partners sooner. The center guards NATO’s networks, watches for threats and coordinates the response when incidents hit.

Meanwhile, AISLE’s authorization is narrower. The company said in a July press release that the designation covers vulnerabilities discovered in its own products, allowing it to publish identifiers without waiting for a third-party authority to process a request. 

Jaya Baloo, the company’s co-founder, described the step as “foundational” and said coordinated disclosure “starts with holding your own products to the same standard you expect of everyone else.” Separately from the designation, the company said its researchers have disclosed hundreds of vulnerabilities in widely used open-source software, including OpenSSL, Linux, Apache and OpenEMR, each coordinated through the relevant authority for that project.

The changes come as the CVE process continues to involve amid program upheaval and the torrent of vulnerabilities discovered by AI systems. 

The CVE program, run by CISA, narrowly escaped a sudden demise when a last-minute, 11-month contract extension averted a shutdown in April 2025. Since then, several competing databases from European nonprofits and other private entities have been stood up in order to better coordinate how vulnerabilities are tracked, disclosed, and ultimately patched.

Earlier this year, The Computer Incident Response Center Luxembourg (CIRCL) launched the Global CVE Allocation System, or GCVE, as an alternative to the CVE program.

The post NATO and an AI startup can now name and track software vulnerabilities appeared first on CyberScoop.

TeamPCP, the threat actor behind an unrelenting flurry of attacks on open-source software this year, has been active much longer than previously thought, according to research Oligo Security shared exclusively with CyberScoop. 

The threat actor, which gained notoriety and has captivated threat hunters as it compromised and injected malicious code into more than 1,000 software packages in less than four months earlier this year, was also responsible for attacks dating back to 2020, Oligo Security found. 

The security vendor’s research team found multiple attacks that bear the markings of TeamPCP, including a late 2025 campaign involving the exploitation of a ShadowRay vulnerability that resulted in the first self-propogating botnet running on hijacked AI infrastructure.

Evidence uncovered during that investigation into the ShadowRay 2.0 campaign was linked to more historical attacks originating from the same IPs, domains and other infrastructure TeamPCP used in attacks that captured widespread attention earlier this year. 

“The scariest thing in this campaign is the speed at which the payloads evolved and changed and adapted to the environment they run in. We saw changes in the speed that we’re not used to seeing in these kinds of attacks. They’re usually slow, careful,” said Uri Katz, director of research at Oligo Security. “This was clearly with the help of AI — the payloads changed rapidly to adjust and change to the environment that they were trying to attack.”

One of the domains that Oligo Security identified in July 2025 was in the profile of TeamPCP’s official GitHub account, said Avi Lumelsky, AI security researcher at Oligo Security. “It’s public, they’re not even trying to hide their identity,” he said. 

From there, Oligo linked TeamPCP to activity tracked under multiple names, including TA-NATALSTATUS and IronErn, spanning from 2020 to late 2025. Much of that activity was traced to the same IPs, domain names, a file server and command-and-control server, researchers said. 

TeamPCP emerged publicly as a brand in late 2025. Soon after, “TeamPCP started to go really broad and do campaigns, which are much more noisy,” said Gal Elbaz, co-founder and CTO at Oligo Security. 

Widespread adoption of AI and TeamPCP’s use of the technology supported this growth as the threat actor built a brand, got more active on social media and boasted publicly about its activities and claimed victims.

“The ability to control the infrastructure and orchestrate the attack with AI was also super new, and I’m sure it helps them,” Elbaz said. 

“All of the companies in the world are in this race to adopt AI because they are afraid their business will die, and they understand, of course, the opportunity. But it’s also what gives the attacker this power to go into it,” he added. “If you don’t really have visibility in what’s going on there or how it behaves, that’s exactly what attackers are after.”

TeamPCP’s more recent attacks have capitalized on new security gaps created by developers’ increasing reliance on AI and the automated systems companies use to deploy code. The threat actor is also consistently wrecking the open-source frameworks and software packages these systems rely on. 

“Most AI infrastructure is open source by design because nobody has the manpower and money to develop everything from scratch,” Lumelsky said. 

“We love open source. We use many of these products ourselves, but it’s all about reading the documentation, and I think many of these tools place the responsibility of using it right and security on the user, and developers are not used to these new kinds of animals,” he added. “That’s why the trust can be exploited at scale.”

As it uncovered a long operational history spanning multiple campaigns, Oligo Security has gained more confidence in understanding how TeamPCP operates. It also means TeamPCP was likely involved in other attacks that haven’t been attributed to it yet or attacks that haven’t been detected. 

“There’s a lot more out there that we haven’t caught or been able to prove up until now,” Elbaz said.

The post Open-source software’s archenemy TeamPCP goes back further than anyone thought appeared first on CyberScoop.

Researchers said INC ransomware, one of the most active ransomware groups globally, has been the main attacker exploiting a pair of SonicWall zero-days soon after they were disclosed last month.

The prolific ransomware-as-a-service operation wasn’t the first group to exploit the flaws, which were actively exploited for three weeks before the vendor disclosed and patched the defects July 14, but it has been the most assertive and concerning group to target and chain both vulnerabilities together for full access.

“Since public disclosure, INC ransomware has emerged as the most commonly named threat actor actively weaponizing this vulnerability chain,” Brett Deroche, director of incident response at Rapid7, told CyberScoop. “While Inc is the name driving the post-disclosure wave, we can’t attribute the full body of exploitation to INC specifically.”

SonicWall did not respond to a request for comment.

The SonicWall vulnerabilities — CVE-2026-15409 and CVE-2026-15410 — are the latest in a series of security issues confronting the vendor’s customers, including actively exploited zero-days, previously disclosed defects, and an attack last year that allowed a state-sponsored threat group to steal the firewall configurations of every SonicWall customer. 

Just last week, Huntress researchers spotted an attack spree that compromised 30 SonicWall customers in less than two days. 

Ransomware groups have taken a special interest in SonicWall. Ten of the 17 SonicWall defects added to the Cybersecurity and Infrastructure Security Agency’s known exploited vulnerabilities (KEV) catalog since late 2021 are known to be used in ransomware campaigns.

INC ransomware, which has claimed nearly 900 victims across 71 countries since it was first discovered three years ago, is just the latest financially-motivated group to target SonicWall customers. 

Researchers haven’t determined how many organizations have been impacted by the latest SonicWall zero-days, including attacks linked to INC ransomware. 

“Attribution here isn’t a single clean answer. The earliest exploitation we observed, beginning June 22, traced back to common hosted infrastructure, though those attacks were largely unsuccessful,” Deroche said. 

“INC’s confirmed activity that we’ve observed came after public disclosure, using different infrastructure and moving from initial access to ransomware deployment in short order. That’s a meaningfully different operational tempo and skill level than what we saw pre-disclosure,” he added. 

Deroche said Rapid7 has successfully prevented data theft and encryption in the majority of recent cases, yet noted ransomware was deployed in at least one case the security vendor observed.

Yet, there could be other attacks outside the purview of Rapid7’s telemetry. INC ransomware has listed multiple new alleged victims on its data leak site, including organizations and government agencies in Australia, the United States, the United Arab Emirates, Colombia and Switzerland, Resecurity said in a blog post Saturday.

The company said it has aided several victims with incident response, and learned multiple victims received emails and phone calls from alleged hackers who pressured them to engage in negotiations.

The post Prolific ransomware group behind SonicWall zero-day attacks appeared first on CyberScoop.

Zero-knowledge proofs could let infrastructure operators answer key security questions without handing over the sensitive data behind their answers.

Imagine a major software flaw is discovered in equipment used across pipelines, power plants and telecom networks. The government needs to know as fast as possible which companies are exposed. But answering that question may require firms to share software inventories, network diagrams and vulnerability scans, which could become attack roadmaps for attackers if compromised. A lesser-known cryptographic concept could help solve this problem. The method, known as zero-knowledge proofs, allows companies prove a vulnerability exists without disclosing how their systems work or other proprietary information.

For more than a decade, Washington has tried to address companies’ concerns about sharing cybersecurity data. Congress has provided legal protections, and agencies have created information-sharing programs. Those efforts have helped companies exchange signs of an attack, incident reports, and defensive advice. But they’ve done much less to get companies to share data on vulnerabilities and security controls before an incident occurs.

The data that would help the most is what companies are least willing to share. A vulnerability scan can show which devices are connected, which software is running, how systems are configured and where defenses are weak. If unintentionally exposed, it would be a terrific guide for adversaries.

Another problem: Once sensitive data leaves a company, it can be stolen, subpoenaed, passed to another agency or used in a regulatory proceeding the company never expected. Industry is constantly asked to reduce security risk by creating more elsewhere.

Zero-knowledge proofs could reduce the need to disclose the underlying sensitive data. The idea is simple, even if the math is not: a company can prove that an agreed evaluation of its authorized scan data indicates that a specific software flaw is present, without disclosing its full asset inventory, network architecture or configuration data.

A computer does not read a vulnerability scan the way a person does. A security analyst might open a report, look through the devices and software versions, and decide whether a vulnerable product is present. A zero-knowledge proof turns that same evaluation into a local mathematical calculation.

For example, the government and a company could agree on a precise question: Does a specific vulnerability exist anywhere inside a defined group of systems? The company keeps its scan data inside its own network. A cryptographic tool checks that data against the agreed question, compares the software and version information against the vulnerability, and produces a proof tied to the final answer. If the scan data satisfies the agreed conditions for a “yes” result, the company cannot generate a valid proof supporting a false “no” answer under those same rules.

The government never sees the raw scan report, the device list, the software inventory, or the network map. It only receives and verifies the mathematical proof, confirming that the answer follows from the agreed rules and underlying data without exposing that data.

This isn’t theoretical. FDD’s Center on Cyber and Technology Innovation recently tested the approach with anonymized vulnerability data from three operational environments. The test asked yes-or-no questions about 38 known vulnerabilities while keeping the raw scans inside the participating environments. Results were promising: only the proofs and answers were shared, yet they revealed how widespread each vulnerability was across the environments.

The test proved the approach works, but that does not mean the government should rush to build a national system around it. A lot of work still needs to be done before agencies can rely on these for compliance, vulnerability reporting, or procurement decisions.

The next step should be structured pilot programs, not mandates. Federal cyber officials and standards bodies should test this with narrow, practical questions: whether a known vulnerability is present or whether a specific security control is in place.

Only after those pilots should agencies decide what underlying data can be trusted and what counts as sufficient proof in a regulatory setting. The Cybersecurity and Infrastructure Security Agency (CISA), the National Institute of Standards and Technology (NIST), and regulatory agencies are natural candidates to run these pilots. CISA already works with critical infrastructure operators on cyber risk, while NIST can help define what a trustworthy proof should look like before agencies try to rely on one. Regulatory agencies, meanwhile, could reduce private sector headaches by developing more secure mechanisms for companies to share compliance information.

Zero-knowledge proofs won’t solve every problem when it comes to cyber information-sharing. But they could solve one of the hardest: how to give the government a trustworthy answer without forcing companies to expose the very systems everyone is trying to protect. The government should test this concept now, while there is still time to learn, and avoid blindly entering the next cyber crisis.

The post How companies could share cyber risks without exposing their secrets appeared first on CyberScoop.

While AI is supposed to help defenders, it’s now creating more than twice as much noise as human-triggered incidents CrowdStrike detects as potentially malicious. The company’s threat hunting team and systems triaged an average of 14 million detection leads daily, resulting in about 36,000 customer alerts during the one-year period ending in June.

“AI agent-driven behaviors have surged past human triggers,” said Adam Meyers, senior vice president of counter adversary operations at CrowdStrike. “AI has driven the detections significantly above what humans are causing, and this gives you a sense of how frequently AI is being used, and really just that it’s being used everywhere.”

The threat posed by AI showed up incessantly during the past year, sparking alarming shifts and heightened targeting across software defects, open-source supply chains and AI tools themselves — all of which create greater difficulties for defenders, CrowdStrike said in its annual threat hunting report. 

“The AI tools that are being implemented by every enterprise across the globe right now are also creating an extended attack surface,” Meyers said during a press briefing. 

“AI is now a tool, a target, and a force multiplier for adversaries,” researchers wrote in the report, adding that AI-enabled malicious activity surged 89% during the past year as attackers used the technology to scale operations, hasten tradecraft and target AI infrastructure.

Attackers are using frontier AI models to uncover vulnerabilities and develop resources, including AI-generated scripts, payloads and commands that increase their effectiveness and efficiency. The technology also allows threat groups to design more creative ways to run automated attacks and boost impact by manipulating, interrupting or sabotaging AI systems and data.

“AI is both the weapon and the target,” Meyers said. 

Most organizations don’t view it as such, and thus far haven’t secured or put proper guardrails around the AI tools they use or address the ways attackers can use AI against them, he added. 

AI’s mark on vulnerabilities is particularly concerning, as reflected by what Meyers described as “one of the scarier stats” in this year’s report: 88% of vulnerabilities were weaponized through AI within 48 hours. 

“This is creating a rich ecosystem of vulnerabilities for attackers to use against various systems,” he said. It also renders the 30-day patch window obsolete, forcing organizations to struggle under a new baseline patch cycle of 24 to 48 hours, according to Meyers.

The AI ecosystem also became the next software supply chain battleground during the past year, as evidenced by TeamPCP’s rampage through open-source software in the first half of this year. 

The threat cluster compromised more than 300 software dependencies in one day, Meyers said. 

AI tools are already in the crosshairs and the attack surface will continue to grow as agentic systems, AI application integrations and dependency managers for AI agents proliferate, the report concluded.

“The same AI tools driving modern businesses are creating under-defended attack surfaces that adversaries are exploiting,” Meyers said. “We have to secure AI. This is absolutely critical.”

The post CrowdStrike: AI is now both the weapon and the target in cyberattacks appeared first on CyberScoop.

AI systems like Anthropic’s Project Glasswing and Microsoft’s MDASH are aiding in the discovery of vulnerabilities, filling the ever-growing pool of defects that defenders have to address before exploitation occurs. Yet, through the first half of 2026, these vulnerabilities were no more or less likely to be exploited than all vulnerabilities disclosed during that period, VulnCheck said in a report Tuesday. 

Concerns remain high about AI-discovered vulnerabilities fueling more attacks, but VulnCheck’s review of exploitation data shows that those fears are unfounded, at least so far. 

Patrick Garrity, security researcher at VulnCheck and report author, identified 1,061 vulnerabilities attributed to AI-assisted discovery during the first six months of the year. Of those vulnerabilities discovered by AI, 14 ( 1.3%) were exploited in the wild, a breakdown that aligns with the exploitation rate researchers observed across all vulnerabilities during the same period. 

“While AI-assisted vulnerability discovery clearly has value for both attackers and defenders, the data does not suggest that AI discovered vulnerabilities are inherently more likely to be exploited than those found through traditional methods,” Garrity wrote.

While AI’s contribution to actively exploited vulnerabilities was muted in the first half of the year, it’s too soon to assume that trend will continue. Moreover, none of these major vulnerability-hunting models were running for that full period. Project Glasswing rolled out in April, while Microsoft’s MDASH and OpenAI’s Daybreak were both unveiled in May.

The upward trend in Microsoft’s monthly Patch Tuesday indicates how much the floodgates might open through the remainder of the year as AI models discover more vulnerabilities. The company’s July security update contained an all-time-record of 622 vulnerabilities, besting the previous record-breaking June update with 206 vulnerabilities.

VulnCheck’s state of exploitation report also found that vulnerabilities were exploited much faster after CVE publication, speeding up from an average of 120 days in 2025 to 80 days during the first half of the year.

The intelligence firm also determined which technology categories were actively exploited most often. Content management systems accounted for nearly one-third of the 495 known exploited vulnerabilities VulnCheck identified during the first half of 2026. Network edge devices were responsible for almost 14%, followed by operating systems at nearly 9%, server software at 8%, and AI products — an emerging attack surface — at almost 6%.

The post AI-assisted security tools are finding more bugs, but the threat level has not changed appeared first on CyberScoop.

After a year and a half spent downplaying calls for AI safety regulations, the Trump administration has sharply reversed course, embracing a level of government scrutiny of frontier AI systems before public release–a far stricter stance than the Biden administration took.

An executive order designed to be friendly to the AI industry was meant to let the federal government briefly review some new models on a voluntary basis.

When the Trump administration, suddenly and without much warning, slapped export controls on Anthropic’s Fable 5 and Mythos 5 in response to private sector threat intelligence reporting, the U.S. AI industry officially entered its regulatory era.

But key questions and gaps remain. It’s not clear why the administration drew the line where it did, or whether they will move it again in the future.

While newer models like Mythos and OpenAI’s Daybreak do have stronger cybersecurity capabilities, the private sector reports the administration relied on describe capabilities already available in older commercial, open-source and Chinese models that nearly anyone can access.

CyberScoop spoke with current users of the latest frontier models, including OpenAI’s ChatGPT 5.5 and Fable 5, to learn more about what these models are currently capable of in offensive and defensive cybersecurity.

Cybersecurity experts and former government officials say the administration may be playing catch up on threats that have been building for years as it has more fully realized the national security implications of the technology.

Are the models breaking new ground or just breaking things? 

Users of Chat GPT 5.5, introduced this past April, and Fable 5 tell CyberScoop those models have been largely helpful to their work, even as they complained about high token usage and safety guardrails that hinder,  but don’t meaningfully prevent, defensive cyber tasks.

Eyal Webber Zvik, chief strategy officer at Cato Networks, a cloud and cybersecurity network provider in OpenAI’s Trusted Access in Cyber program, said they use GPT 5.5 and later OpenAI models to scan and triage internal codebases for vulnerabilities, test new safeguards and provide “highly autonomized service” to their customers.

Zvik wouldn’t disclose how many bugs 5.5 has found but said the company’s view is that it helps both find bugs that humans missed and rank which ones to patch based on factors like each bug’s exploitability.

“It is now a native part of our development environment and cycles, and we use those models to scale our entire codebase and make sure what we release into the service that our customers use to run their networks and network security has the least likelihood of having any vulnerabilities that can be exploited,” said Zvik.

John Hopper, vice president of engineering at SpecterOps, an identity security company, said newer models like GPT 5.5 are sharper and more persistent in pursuing their tasks.

“That can be a good or bad thing,” he noted.

One metric that SpecterOps tracks is how long it can keep a particular agent working before it moves off task or fails. That metric “matters a lot” because the longer an agent works without human help , the more agents a single operator can run at once.

Hopper said this provides defenders with immense value, and pushed back on the idea that the offensive capabilities the models offer are automatically more beneficial to malicious hackers. There is “a modicum of grounding that the industry needs when we talk about these models.”

“Yes, AI frontier tools will lower the barrier of entry, but these problems have always existed,” he said. “I don’t actually believe that AI is going to remove the needle in the haystack problem, but by howdy, using my two hands to find that damn needle, compared to using a backhoe, I can tell you which one I’d rather be driving.”

Eran Kinsbruner, vice president of product marketing at software security firm Checkmarx, told CyberScoop that later models like OpenAI’s Codex Security and GPT 5.5 are noticeably easier to set up and run with local systems, even for less technical users. That alone gives them an edge over many cybersecurity tools where interoperability is a constant concern.

However, GPT 5.5 burns through tokens at a much faster rate. He recalled one instance of using it to scan a medium-sized repository in three different programming languages.

“After 26 minutes I almost ran out of tokens, and it didn’t provide anything, just created a threat model for me and told me you want to buy more tokens?” he said.

In other instances, some of the scan results he received were not comprehensive.

Further, he expressed frustration with some of the guardrails designed to prevent risk – like only allowing users to scan local files but not code repositories like GitHub – “makes not too much sense” given how often developers must work with remote code.

Those kinds of guardrails – which can prevent models or developers from injecting malicious code or prompting into their models – sit at the heart of the debate in Washington D.C. and around the world. Some users feel differently about their utility.

Kinsbruner said that doesn’t make sense for organizations like his, which work with thousands of different enterprise organizations with  thousands of different code repositories spread across the internet.

“I cannot imagine how large-scale developers could just jump into this solution and make it an enterprise-grade, enterprise-level, de facto cybersecurity solution” out of it, said Kinsbruner.

OpenAI did not respond to a request from CyberScoop for an interview on GPT 5.5. The company has since released another model, GPT 5.6, that they said is more efficient at token use.

The White House’s crash course in AI cyber risk 

 The White House keeps changing its line on whether and how the U.S. government should limit the release of commercial frontier models. The shift comes from lessons learned since coming into office in Jan. 2025. Trump threw out Biden-era regulations meant to steer the industry toward safer models. Top officials like Vice President JD Vance argued against restricting industry progress.

Less than two years later, administration officials worry about the impact of speed and scale – two things AI excels at – in cyberspace.

According to Will Loucks, senior director of intelligence at the Office of the National Cyber Director, over the past two years the number of exposed and known vulnerabilities has shot up. Threat actors exploit those flaws faster before defenders can fix them. Once inside, the time from initial access to full network control shrinks.

“So in other words, every stage of the cyber operations lifecycle that a threat actor has to move through to get to a victim network and achieve an outcome, they’re just moving through more quickly faster,” said Loucks at a July 16 event in Washington D.C.

Speaking about AI in particular, Loucks said one of the defining characteristics of the technology is its ability to lower barriers for threat actors.

“Sometimes speed and volume have a threatening aspect alone, even if sophistication isn’t quite increasing in the same way, and the reason for that is because it places pressure on defenders…to triage alerts more quickly,” he said.

Jordan Rae Kelly, former director for cyber and incident response on the White House’s National Security Council during Trump’s first term, told CyberScoop that the changes over the past two years reflect the lessons the White House has learned on the issue since returning to office.

In the early days of this administration, Kelly said, “there is a sense and a spirit that the Biden administration was limiting AI and there was a kind of a rip-it-all-off [attitude], everybody go and do whatever, we will be the biggest and boldest and brightest.”

“I love that talking point, but I think what you’ve seen is probably an education over the last 19 months, where people [in the White House] have said that’s a challenging premise to put into place, knowing about the potential downsides and capabilities,” she added.

Michael Daniel, former White House cyber coordinator under President Barack Obama, thinks the horse may already be out of the barn.

Daniel, now head of the Cyber Threat Alliance, a membership nonprofit group focused on cyber threat information sharing between industry and government, said his members report that AI is being used to do things “faster and at a slightly bigger scale” but aren’t yet seeing the flood of exploitation that analysts have warned about. Not yet.

“I think what we’re seeing right now [and] talking about is ‘okay, where are the step changes [in the cyber threat landscape] actually going to occur?” said Daniel. “Are we and when will we see the explosion in vulnerability reporting from these Mythos-like capabilities? That’s what’s really got their attention right now.”

But Mythos and OpenAI’s Daybreak models are restricted to select organizations, and neither has publicly released its most powerful cybersecurity models to the public. That dynamic won’t last.

The UK’s AI Security Institute estimates that open source and foreign LLM models are between 4-7 months behind frontier U.S. models. In that setting, it’s hard to stop the development of AI models worldwide through export controls or other limits.

“It’s not like we’re buying ourselves five to ten years on this,” he said. “We’re not, and so I’m not sure the impact on the defenders who are trying to obey the law is worth whatever small hiccup we cause for our adversaries.”

Kelly said there’s merit to the administration’s current position, even if it took time to get there. Many federal cybersecurity procedures that operated even a decade ago – such as a Vulnerabilities Equities Process that could take days or weeks to consider the pros and cons of keeping an exploit – are no longer practical.

“All of that work to some degree, is out the window, because you can’t meet with the regularity you would need to meet to adjudicate vulnerabilities that are being found in seconds and exploited in minutes,” said Kelly.

But Kelly and others say that’s also because AI capabilities in cybersecurity are developing faster than policymakers can react, even in the best of times.

Key questions remain and the administration’s balance between national security and backing domestic industry will likely shift  in response to new events.  The administration wants a framework that can predict and manage the risks of AI models today and tomorrow. That may be harder than it sounds.

“Do I think they’ve been clear? No,” said Kelly. “But I think it’s a place where clarity is really hard to achieve.”

The post Where’s the Trump administration line on AI regulation? appeared first on CyberScoop.

SonicWall customers are attempting to dodge another security challenge as attackers are exploiting a pair of zero-day vulnerabilities that have been confirmed by the vendor. 

The company publicly disclosed the vulnerabilities — CVE-2026-15409 and CVE-2026-15410 — in a security advisory Tuesday. SonicWall credited an employee with discovering the defects, but it hasn’t said when the discovery occurred or the earliest known instance of exploitation. 

Rapid7 researchers told CyberScoop both vulnerabilities were first exploited June 22. “From the cases that our team has observed, the goal is likely ransomware, though we have prevented the actors from achieving exfiltration and encryption,” said Seth Lazarus, senior manager of detection and response services at Rapid7.

Overlapping tactics, techniques and procedures from the attacks observed by Rapid7 indicate the same threat group or attacker discovered and exploited the zero-days, Lazarus added.

SonicWall did not answer questions about the impacts of these attacks thus far, and the company hasn’t attributed the attacks to a known group or described the attacker’s origins and motivations.

The vendor did, however, confirm to CyberScoop that both vulnerabilities have been chained together for exploitation. The vulnerabilities affecting SonicWall SMA1000 appliances, including a max-severity defect that allows attackers to make authenticated requests and a 7.2-rated vulnerability that allows authenticated command injection.

“When these two are chained, an attacker can go from zero access to a complete system compromise for the affected appliance,” said Landon Rice, senior exploit developer at VulnCheck.

Ben Harris, founder and CEO at watchTowr, said two characteristics of the vulnerabilities fuel a sense of dread. “Both were exploited as zero-days before fixes were available, and together they offer a plausible path to remote-code execution from the internet,” he said.

The Cybersecurity and Infrastructure Security Agency added both zero-days to its known exploited vulnerabilities catalog Tuesday. 

SonicWall encouraged customers to patch the vulnerabilities by upgrading to the latest software version, which it released upon disclosure, and shared some indicators of compromise to help customers hunt for potential malicious activity on their systems.

“Speed of response was a priority for us,” said Bret Fitzgerald, senior director of global communications at SonicWall. “Within days of becoming aware of the issue, our team had developed a script that we can run on behalf of affected customers to assist with resolution, and mitigation efforts are already underway.”

SonicWall and third-party researchers haven’t said how many SonicWall customers are impacted by the exploited vulnerabilities, but the vendor did say it already investigated multiple cases of active exploitation. 

Fitzgerald said the company monitors about one million sensors globally and “SMA1000 appliances represent a very small subset of that footprint, less than 5,000 units.”

SonicWall said support staff are also helping customers work through instances of suspicious activity, warning that patching alone is not sufficient. 

The vendor and its customers have been hit by a barrage of actively exploited zero-days and previously disclosed defects in SonicWall devices for years. In 2025, an undisclosed state-sponsored threat actor intruded the company’s cloud environment and stole firewall configurations of every SonicWall customer. 

Seventeen defects affecting the vendor’s products have been added to CISA’s known exploited vulnerabilities catalog since late 2021. Ten of those defects are known to be used in ransomware campaigns, according to CISA, including a wave of about 40 Akira ransomware attacks between mid-July and early August.

“As always,” Harris said, “when something is confirmed as already exploited in the wild, patching is the bare minimum, and breach should be assumed.”

The post SonicWall customers under threat as attackers exploit 2 zero-days appeared first on CyberScoop.

Microsoft’s monthly Patch Tuesday security program reached an unrivaled pinnacle this month, as the vendor addressed 622 vulnerabilities across its suite of business products and systems. 

“The bug apocalypse has finally descended upon us,” Dustin Childs, head of threat awareness at Trend Micro’s Zero Day Initiative, wrote in a blog post Tuesday.

“The mother of all releases. To call this record-breaking is an understatement,” he added. “The CVE count year-to-date exceeds all other years’ totals.”

The startling increase in vulnerabilities reflects a compounding effect taking root across software as artificial intelligence plays a growing role in discovering and developing patches for defects lurking in error-riddled applications. 

Microsoft’s June Patch Tuesday update broke the previous all-time record with 206 vulnerabilities.

The company last week warned forewarned customers and defenders that a flood of defects would be uncovered as it applies its multi-model agentic scanning harness (MDASH) to discover and address vulnerabilities at greater speed and scale.

The monthly exponential rise in Microsoft vulnerabilities already puts the vendor on pace to break a full-year record, ending 2026 with the largest annual collection of defects, beating the previous record of 1,245 CVEs in 2020, Satnam Narang, senior staff research engineer at Tenable, said in an email. 

“It’s probable that we will not only exceed 2,000 CVEs in a calendar year, but potentially over 3,000 CVEs this year or more,” he added.

“The volume is striking, but it reflects how good these tools have become at finding bugs, not how many of those bugs actually pose a risk to organizations,” Narang said.

Microsoft disclosed two actively exploited zero-day vulnerabilities — CVE-2026-56155 and CVE-2026-56164, privilege escalation defects in Active Directory Federation Services and Microsoft SharePoint Server, respectively. 

The monthly batch of patches included 416 defects in Windows, 82 in Office and 46 in Microsoft Edge. More than 1 in 10 vulnerabilities the vendor disclosed — 63 total — were rated as critical.

“The products covered this month are also astonishing,” Childs said. “Just about everything you’ve ever heard of is getting patched.”

The full list of vulnerabilities addressed this month is available in Microsoft’s Security Response Center.

SAP also addressed a fresh assortment of vulnerabilities Tuesday, including critical defects CVE-2026-44747 in SAP NetWeaver Application Server and CVE-2026-27690 in SAP Approuter.

The post Microsoft discloses ‘the mother of all’ vulnerability loads, tripling June’s previous record appeared first on CyberScoop.

AI-generated code is part of everyday software development. Developers use it to prototype, refactor, troubleshoot, and move from idea to implementation with less friction than ever before. The productivity gains are undeniable, which means that security leaders now face a hard question: whether their organizations can govern the risk that AI creates at that same speed.

That challenge is rooted in scale. AI changes how quickly software can be created, while many application security programs still depend on controls designed for a slower development model. When code generation accelerates beyond the capacity to review, test, and remediate issues, security debt accumulates faster.

That is the hidden cost of AI-assisted development. Risk now enters the enterprise at machine speed, while many organizations still manage it with human-scale processes. CISOs should govern AI-generated code as a high-risk input: tested automatically, checked for unsafe dependencies, remediated quickly, and blocked from production if it fails policy.

The metric that matters is risk velocity

Application security has long been measured through discovery. Teams count vulnerabilities, categorize severity, report trends, and show whether the numbers are improving. Those questions still matter, but AI adds a more urgent metric: risk velocity. Security leaders need to know how quickly the organization creates new software risks and how quickly it can reduce or eliminate them.

AI changes the economics of security debt. A development team that produces significantly more code without a matching increase in security capacity will create more issues than it can reasonably review or fix. Even when AI-generated code is comparable to human-written code on a per-line basis, the total risk can rise because the volume of change is higher. The backlog grows, vulnerabilities persist, and security debt eventually constrains the business.

AI expands familiar failure modes

The failure modes are familiar. AI coding tools can reproduce insecure patterns found in training data, including weak input validation, unsafe authentication flows, insecure direct object references, hard-coded secrets, and vulnerable dependency choices. They can also miss the context that determines whether code is secure in a specific environment: authorization models, tenant boundaries, data sensitivity, production configurations, and how services interact in a real application.

There is also a human factor. Under the pressure of deadlines, developers may accept code that works without fully understanding how it does so. The result is misplaced confidence. Code compiles, tests pass, features ship, and hidden risk enters the system. Over time, the organization may lose sight of the security concerns that naturally arose during manual development.

The supply-chain risk is bigger than the code itself

The software supply chain adds another layer of risk. Modern applications are assembled from open-source components, frameworks, plugins, containers, APIs, and cloud services. AI coding tools can recommend outdated packages, vulnerable libraries, or nonexistent dependencies. Veracode’s 2025 GenAI Code Security report found that AI coding tools produce insecure code nearly half (45%) of the time. It may sound like an amusing hallucination until attackers register malicious packages with similar names and wait for developers or automated tools to pull them in. At that point, a coding shortcut becomes a supply chain exposure.

AI is already part of the development lifecycle, and its use will continue to expand. Security teams need a control model built for that reality.

“Shift Left” needs an enforcement layer

The industry has spent more than a decade moving security earlier in the development lifecycle, improving visibility and helping teams catch issues sooner. Many organizations, however, moved findings closer to developers without also moving enough ownership, automation, and remediation capacity with them. Developers received more alerts, while security teams gained more visibility into risks they still struggled to reduce.

AI makes that operating gap more urgent. As software output increases, security cannot remain a checkpoint near the end of the process. It must become a continuous control system built into the way software is created, tested, approved, and deployed.

Secure-by-design has to become infrastructure

Secure-by-design in the AI era requires an engineering environment where unsafe choices are harder to make and easier to catch. Approved frameworks, secure defaults, reference architectures, dependency controls, automated testing, and policy enforcement should be embedded directly into developer workflows and CI/CD pipelines.

Remediation also must move closer to the point of creation. When a coding assistant introduces a vulnerable pattern, the ideal response is an inline fix that is proposed, validated, and governed as part of the normal development process. AI can help defenders here when it is connected to reliable security signals, policy context, and evidence from real testing. Counterintuitively, developers using AI to write code often don’t trust AI to automatically remediate code without human review. This takes one of the best ways to keep up with machine-speed created vulnerabilities and slows it down to human speed. An acceptable balance between risk and speed must be found.

Approval is not governance

CISOs should focus on governance, not just approving AI coding tools. Governance means tracking where AI-generated code enters your environment, documenting the policies and tests applied, recording what issues were found and fixed, and keeping proof of these decisions. This documentation becomes critical as AI-assisted development becomes standard. If vulnerable code reaches production, you’ll need to show that adequate controls were in place and risks were managed according to policy.

What leaders should do now

CISOs and engineering leaders should treat AI-generated code as untrusted until proven otherwise. They must require automated testing before release, enforce dependency controls, prioritize remediation based on exploitability and business impact, and measure success by the rate at which critical risk is reduced.

Additionally, boards and organizational policymakers should ask whether organizations can demonstrate that AI-assisted software is governed before it is deployed. The key evidence should include the policies applied, the tests performed, the vulnerabilities remediated, the risks accepted, and the approvals recorded. Today, many organizations can confidently track what their AI tools produce, but they cannot demonstrate how that output was secured, reviewed, and governed before reaching production. The industry is still working to close this gap.

AI is changing how quickly software risk moves through the enterprise. The organizations that succeed will make security move just as quickly by embedding governance, remediation, and proof directly into the software delivery pipeline.

The post AI-generated code has made security debt a governance problem appeared first on CyberScoop.

China-aligned attackers broke into the networks of U.S. and Canadian universities to steal sensitive data and establish persistent access via webshells and backdoors, Proofpoint threat researchers said Tuesday. 

The espionage-motivated attacks targeted physics and engineering departments, focusing on administrators and professors with national security links or organizations researching astrophysics and particle physics.

Proofpoint identified less than 10 university victims and estimates a few dozen universities may be impacted, Greg Lesnewich, principal threat researcher at Proofpoint, told CyberScoop. The company first observed the campaign in May and believes the campaign is ongoing. 

“There is a high likelihood that many victims have not been made aware of this activity yet,” Lesnewich added.

Researchers traced the attacks to a pair of critical vulnerabilities in Roundcube, an open-source email client, that were exploited and chained together to steal credentials and gain long-term access.

The threat cluster, which Proofpoint tracks as UNK_MassTraction, exploited CVE-2024-42009 to execute JavaScript inside the victim’s browser, then exploited CVE-2025-49113 to gain a foothold in the mailserver. 

The initial exploit in the chain only requires a victim to open an email, and the attackers sent victims a series of generic lures to trigger the initial access.

Proofpoint attributes the campaign to a China-aligned cluster because the attackers used a known covert network used by multiple China-aligned threat groups, an infection chain leading to VShell and left Chinese language artifacts in the phishing emails. 

Researchers haven’t drawn any conclusions about why attackers targeted the universities and what they are seeking. 

“We do not have data to suggest what got stolen, as we only observe the initial inbound email attempt,” Lesnewich said. 

The engineering aspects do align with China’s strategic initiatives, he added. Google threat hunters recently spotted a Chinese state-sponsored espionage group that burrowed into systems for years, stealing data across academia, medicine, military, cybersecurity and foreign policy. 

“China-aligned adversaries have been targeting other types of edge devices such as routers and VPN concentrators for years with various exploits to create a foothold into a target network, not using email for delivery,” Lesnewich said. “This campaign flips that on its head, using email to deliver an exploit chain to compromise a mail server, instead of using email to deliver a credential harvesting URL or malware to target an end user, not a server.”

The post Suspected Chinese espionage group used a Roundcube exploit chain to burrow into universities appeared first on CyberScoop.

I keep hearing the same frustration when I talk with security leaders. The real problem sitting on their desk isn’t finding vulnerabilities. It’s deciding which ones actually matter.

The industry has spent billions on better visibility. We’ve convinced ourselves that if we could just discover more vulnerabilities, collect more data, and ingest more threat intelligence, we’d become more secure. But look around. Organizations still aren’t more secure. They’re just overwhelmed.

Then AI arrived and changed the game entirely. In a matter of months, vulnerability discovery accelerated dramatically. AI systems review code faster than human researchers ever could. They identify weaknesses at unprecedented scale. They scan continuously without the limitations of time, staffing, or attention. The headlines have been everywhere. Government leaders are reevaluating AI laws. CEOs are tossing and turning at night.

But we are focusing on the wrong issue. None of this is actually solving what matters most.

For years, security teams have been drowning in findings. Every new threat feed promised greater visibility. What arrived instead was noise—more data, more alerts, more dashboards, more vulnerabilities. Rarely clarity. Now AI is pouring gasoline on that fire.

The conversations around AI in cybersecurity often get stuck in the wrong place. People debate whether it will help defenders move faster or enable attackers more easily. Both matter, but they are not the core issue.

The real consequence of AI is that it’s exposing something organizations have avoided facing. A vulnerability is not risk, it’s just a clue. Risk emerges when information connects to context: how critical the affected asset is, what controls surround it, how likely exploitation is, the business processes it supports, and what happens operationally if it fails.

Without that context, prioritization becomes impossible. Resources get spent on low-risk issues while mission-critical, vulnerabilities sit unfixed.

Now AI is now making the data volume problem almost impossible to comprehend. An enterprise working with hundreds of software vendors, cloud providers, contractors, and technology partners must investigate every relationship. It’s like a cybersecurity nesting doll where AI continuously identifies vulnerabilities across that entire ecosystem, every minute of every day.

The real challenge today isn’t discovering weaknesses. It’s determining which of tens of thousands of newly discovered weaknesses could actually disrupt operations, impact customers, halt revenue, or create regulatory exposure. Most organizations can’t answer that question quickly.

Some still rank risk using severity scores built for technical teams rather than business leaders. Others rely on manual triage that was already struggling before AI. Many still measure security maturity by how many findings they identify rather than the speed and accuracy of their decisions.

These approaches don’t work anymore. They probably didn’t work yesterday either.

What’s uncomfortable to acknowledge is that AI isn’t creating a cybersecurity crisis. It is revealing one that’s existed for years. The organizations that succeed in this an AI world will transform discovery into judgment faster than their competitors. When AI can find nearly every weakness, security belongs to those who know what to act on. It belongs to those who can connect data to business reality.

That’s the real edge. That’s what separates secure organizations from those that are just collecting more findings.

The post Finding vulnerabilities was never the hard part appeared first on CyberScoop.