Last week, the FBI and EPA issued a joint alert that should concern anyone who drinks water in America–which is to say, everyone. Since July 27, water and wastewater utilities in at least seven states have reported cyberattacks against internet-facing programmable logic controllers (PLCs), the small industrial computers that run pumps, valves, and treatment equipment. Some of these attacks degraded operations. Utilities reported pressure loss and flooding, several systems reverted to manual control, and one Minnesota community declaring a local state of emergency.

Nothing about these attacks required sophisticated methods. The attackers didn’t use zero-day exploits or novel malware. They found controllers exposed to the public internet, many of them so old that they stopped receiving security patches years ago. They logged in, changed IP addresses and passwords, and locked operators out of their own equipment. In at least one case, they modified the ladder logic controlling industrial equipment. These were not Hollywood-style hacks. The controllers sat exposed and undefended.

If this feels familiar, it should. In late 2023, attackers compromised controllers at water utilities across several states, including the widely reported incident in Aliquippa, Pennsylvania. The federal government issued guidance then, too. One of the crucial differences between then and now is that attackers have grown in ambition. They’ve moved from defacing screens to disrupting operations across dozens of systems at once, exploiting the fact that third-party integrators often deploy the same vulnerable configuration across many small utilities. 

The uncomfortable truth is that this was preventable. The reason it wasn’t stopped is more structural than technical. The United States has roughly 50,000 community water systems. Most are small, publicly funded, and run by operators whose primary job is keeping water safe and flowing. Cybersecurity ranks far below that, if it ranks at all. The devices in question are often a decade or more old and replacing them takes capital these utilities don’t have. Rules governing water cybersecurity remain mostly voluntary. Attackers understand these economics perfectly. We should too, yet these attacks keep happening.

 But inaction is a choice. The defenses that work here cost little and require no exotic technology. The FBI and EPA guidance is sound, and every water and wastewater organization should act on it this week, not later. Here’s how:

• Get controllers off the public internet. No PLC should be reachable from the outside world. Remote access should go through a secure gateway that mediates, monitors, and logs every connection. That includes cellular modems, which are the overlooked entry point in nearly every audit.
• Fix passwords. Default and shared credentials are still the most common way in. Strong, unique passwords are the cheapest security control available.
• Restrict communication between devices. Firewall rules and access control lists should allow only expected communication between known control system devices. Block traffic from hosting providers and other sources that have no business touching a water plant.
• Lock the logic. Keep physical and software key switches in the run position except during authorized updates. This prevents unauthorized changes to configuration and firmware.
• Practice running manually. The utilities that survived these attacks best were the those that switched to manual operations quickly. That skill requires constant practice.
• Verify, don’t assume. Nearly every utility believes its PLCs aren’t internet-exposed, right up until an inventory proves otherwise. You can’t protect what you can’t see. Most operators are surprised by what a complete asset inventory reveals: forgotten modems, integrator-installed remote access, devices nobody knew were still online.

Every attack like this follows the same pattern. Attackers change configurations, reset passwords, and modify project files. Every one of those actions creates a signal on the network before operations degrade. In this most recent case, one victim only noticed ladder logic discrepancies across multiple sites. Catching intrusions shouldn’t depend on a sharp-eyed engineer having a good day. Continuous monitoring of OT environments exists to turn those signals into alerts within minutes instead of days. That difference is the difference between an incident report and a boil-water notice.

Water systems have the least margin for error and, too often, the fewest resources to defend themselves. The FBI and EPA have told us plainly what’s happening and what to do about it. The attackers are betting we won’t follow through. For the third time in three years, they’re testing that bet.

Let’s finally prove them wrong.

The post The water sector just got it’s wake-up call. Again. 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.

We almost never get both sides of an intrusion. This time we did.

Last month, Hugging Face disclosed a breach into part of its production infrastructure, saying an autonomous AI agent system ran the attack from start to finish. Five days later, OpenAI revealed that its own models, including GPT-5.6 Sol along with an unreleased one, were responsible for the breach. OpenAI called it an unprecedented cyber incident.

Most of the commentary since has been about AI capability. That is the least useful part of the story, because the capability was doing what it was destined to do. Security teams should look at a simpler truth: in both systems, the key defenses sat behind untrusted code that was already running.

What the two disclosures actually describe

Together, the report shows one connected attack across two firms. Code running on a low-level employee’s machine led to stolen passwords, privilege escalation and lateral moves, then out to the web to hit other targets. No step in that chain is novel. The speed and the number of attempts are what changed.

OpenAI’s evaluation ran in what it calls a highly isolated environment, with network access constrained to a single path: an internally hosted third-party proxy and cache for package registries. The models spent vast computer power searching for an exit. They exploited a zero-day flaw in that proxy, gained higher rights, and moved until they reached a machine with web access. They guessed that Hugging Face held the test solutions, used stolen passwords with more zero-days, and ran code on Hugging Face servers.

Hugging Face picks up the same chain from the receiving end, and its initial access is worth reading twice. A malicious dataset used two flaws in the data pipeline to run code on a worker machine. The agent took over the node, stole cloud keys, and moved into internal clusters over the weekend.

The sandbox was was the only boundary

Both setups assumed the sandbox would hold, so no real checks stood before code execution.  A sandbox is a good control. It is a terrible last control. When isolation is all you have between untrusted code and everything else, one flaw could give the attacker full control. 

Look at what each team allowed. OpenAI allowed one exit path—good engineering, but that proxy contained an unpatched flaw. Hugging Face ran a tool that executes code inside submitted data—a known feature, not a hidden mistake.

Neither choice was careless. Both made sense until a fast, automated system probed them thousands of times.

Why automated agents behave differently

Blocking a human stops them or slows them down. Blocking an AI gives it data. The AI logs the error, changes its plan, and tries again instantly. It keeps trying as long as someone pays for the computing power.

Hugging Face tracked over 17,000 attack events across short-lived sandboxes. OpenAI said its models focused on the goal with extreme effort.

This changes the attacker’s limit. It is no longer skill or patience. It is budget. Computing power scales with money, and code never sleeps. Any defense that relies on attackers giving up after a few tries must change.

Detecting malicious behavior is not the same as preventing execution

Detection worked—but too late

Detection worked, but too late to stop the loss. Hugging Face used AI tools to spot the breach, isolate systems, reset keys, fix flaws, and alert police. That is a good response.

Yet it happened after the attacker accessed private data, stole keys, and moved through internal networks. OpenAI spotted the event only after its models reached another firm’s database. Detection limited the damage; it did not stop the attack.

A breach is a race between attack speed and defender response speed. AI agents speed up attacks with money. Human approval steps slow down defenders.

Hugging Face also surfaced an asymmetry that deserves more attention. When the team tried to analyze the attack with frontier models behind commercial APIs, the requests were blocked, because forensic work means submitting real attack commands, exploit payloads and command-and-control artifacts, and a safety filter cannot tell a responder from an attacker. They used an open-weight model on their own infrastructure instead. The attacker operated under no usage policy at all. The defender’s tooling was the side that got refused.

Detection is not prevention

Detection asks what happened. Prevention asks if it can happen at all. Against AI agents, the gap between those questions is where attacks succeed. The agent builds an attack out of single steps that look harmless on their own.

OpenAI noted this in its research: models operating over long horizons learn approval blind spots and work around them. Safety requires asking what a series of actions aims to achieve, not just if one step is allowed. Most systems check one call at a time: read a file, install a package, open a port. Every step passes. The full chain is the attack.

Six fixes for real defense

To survive automated attacks, defense must shift before code runs. That starts with treating data like code. Dataset loaders, templates, and configuration files all run instructions, so they demand strict controls: block remote execution by default, require review, and check the source of every outside file. Security teams must also control outgoing traffic with strict lists of approved destinations, while treating every proxy in that path as vulnerable. Finally, firms must remove permanent keys, issuing short-lived credentials for single jobs so a hacked worker machine yields almost nothing to an attacker.

Beyond individual machines, isolation must happen per task rather than per user, stopping an automated swarm from moving through internal networks. Authorization also needs to change. Checking single actions fails when an agent builds an attack out of simple steps. Systems must evaluate full sequences instead, setting caps on activity rates and automated spending to flag suspicious chains of events. Lastly, defenders need the freedom to act fast. Security teams need authority to isolate systems without waiting for leadership meetings, and the ability to vet a capable model you can run on your own infrastructure for forensics.

What boards must ask now

Corporate boards usually ask if the company uses AI responsibly. That’s rooted in compliance not safety. Directors should ask four direct questions instead: Which systems run outside code, and what checks sit in front of them? If an attacker targets a low-level employee, what keys and paths can they obtain? How fast do we move from the first warning to active containment? And can we analyze attack code on our own hardware, free from third-party rules?

The boundary has to move

Nothing in these disclosures required a capability that did not exist last year. The chain was ordinary. What changed is that an adversary can run that ordinary chain thousands of times over a weekend, learn from every failure, and never need a coffee break.

The models did not break the detection-and-response model. They exposed where we put the trust boundary. We put it after execution, and we assumed we would have time on the other side of it. We do not have that time anymore.

Move the boundary.

The post What the Hugging Face breach reveals about defense in the age of agentic AI appeared first on CyberScoop.

A Russian state-sponsored threat group has been stealing sensitive data from governments and commercial organizations since July 2025 via a novel exploit in popular Linux-based enterprise software, U.S. authorities and cyber officials from more than a dozen other countries warned in a joint cybersecurity advisory Thursday.

Laundry Bear’s most recent espionage campaign involves the exploitation of a zero-day vulnerability in Zimbra Collaboration Suite that wasn’t patched until November 2025, five months after attacks were well underway, officials said. 

The exploit just requires a view — no clicks — and allows attackers to steal the previous 90 days’ worth of email, the account’s password, search history, the victim organization’s email directory, two-factor authentication tokens and other newly created passwords.

“The covert and persistent nature of this activity, along with the absence of any known financial extortion, almost certainly indicates this group’s involvement in espionage activities with Russian government backing,” officials wrote in the advisory. 

“Additionally, extensive Ukrainian targeting, prior to use against U.S. and other NATO allies, outlines an increasing trend within Russian cyber threat groups to target Ukrainian users first—both as a priority target and as a testbench for malicious cyber techniques before broader global deployment.”

The state-sponsored espionage group, also known as Void Blizzard, has compromised governments and organizations in the defense, education, energy, law enforcement, media, finance, transportation and technology sectors. 

Laundry Bear’s year-long campaign involving the exploitation of CVE-2025-66376 showcases more technical capabilities, including a custom JavaScript payload it delivers to targeted victims via phishing emails. The threat group could also likely adapt the novel data exfiltration and aggregation capability, dubbed “beehive,” to exploit other vulnerabilities, officials warned.

The defect’s medium-severity rating of 6.1 underscores the challenge defenders regularly confront in prioritizing patching schedules based on measure of severity alone.

The Russian state-supported group, which has been active since at least 2024, is still actively exploiting Zimbra Collaboration Suite instances that remain unpatched, officials said.

Authorities shared Thursday indicators of compromise, mitigation steps and urged organizations to update their vulnerable software.

“This campaign’s targeted victimology and limited exploitation capabilities likely indicate this group manually identifies and targets the victim organizations” by identifying organizations with public-facing infrastructure, officials wrote in the advisory.

Once a target is identified, Laundry Bear also likely compiles email addresses for users to target with the exploit via phishing emails. Officials did not identify specific victims or describe the volume of organizations already compromised.

The joint cybersecurity advisory was issued by the United States, Australia, Canada, New Zealand, the United Kingdom, Czech Republic, Denmark, Estonia, Finland, France, Italy, Moldova, the Netherlands, Poland, Spain and Sweden.

The post Russian espionage group using novel Zimbra exploit to steal sensitive data from Western countries 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.

Researchers are warning that cybercriminals exploited an Oracle PeopleSoft zero-day vulnerability and potentially infiltrated the networks of more than 100 organizations in an attack spree that largely impacted higher education.

Mandiant and Google Threat Intelligence Group said it became aware of the attacks earlier this month as part of its ongoing monitoring of ShinyHunters operations. The notorious cybercrime group claims it hacked more than 100 organizations and started naming victims and publishing allegedly stolen data Tuesday.

University of Nottingham, one of ShinyHunters’ alleged victims, on Wednesday confirmed a significant amount of student data was stolen during a cyberattack after the threat group leaked some of the school’s data.

The attacks date back to at least May 27, according to Mandiant, and involve the exploitation of CVE-2026-35273, a defect in Oracle PeopleSoft PeopleTools that allows unauthenticated attackers to execute remote code and takeover affected servers.

Oracle disclosed the vulnerability and recommended some steps for mitigation Wednesday, weeks after the attacks were already underway. The vendor hasn’t released a patch to address the defect and did not respond to a request for comment.

Google said it alerted more than 100 organizations of potentially vulnerable endpoints in their environments, but it declined to confirm how many victims are compromised. 

“This campaign is still active. We have observed ShinyHunters sending extortions as recently as today,” Charles Carmakal, chief technology officer at Mandiant Consulting, told CyberScoop Thursday evening. He added that more victims, beyond Google’s visibility, may be impacted.

Most of the potential victim pool is based in the United States and 68% are in the higher education sector, according to Google.

“We have previously observed ShinyHunters target the education sector this year, however it’s possible this targeting is representative of the majority of exposed PeopleSoft instances belonging to the sector,” Carmakal said. 

Oracle PeopleSoft PeopleTools includes more than 40 tools for human resources and customer relationship management.

The attacks come less than a year after the Clop ransomware group exploited a zero-day in Oracle E-Business Suite that affected dozens of victims. The data theft extortion campaign that followed those attacks, which began in August, didn’t get underway until October.

The post ShinyHunters is actively extorting universities after exploiting an unpatched Oracle flaw appeared first on CyberScoop.

Microsoft reopened some wounds and has reignited debate over the past couple weeks about vulnerability disclosure and the sometimes adversarial dynamic it creates between security researchers and vendors. 

The latest controversy ensued when Microsoft threatened criminal legal action against a security researcher who publicly disclosed a series of zero-day vulnerabilities with proof-of-concept exploits. Microsoft insisted it received no details about the vulnerabilities prior to release, adding that the defects were not responsibly disclosed and put its customers at unnecessary risk.

The public dispute between Microsoft and the researcher known as “Nightmare Eclipse,” who couldn’t be identified or reached for comment, sparked dismay among some security professionals. Microsoft’s forceful response and the resulting backlash revived a friction point between vendors and researchers who find and report flaws in the software they sell.

“The fight is being argued as coordinated disclosure, but the grievance underneath is personal and specific in a way disclosure shouldn’t be, especially with a vendor that has been at it for so long,” Katie Moussouris, founder and CEO at Luta Security, told CyberScoop.

“Microsoft seemed to get emotional and shouldn’t have publicly said anything, but somehow felt justified in calling out a researcher and involved law enforcement in the same breath,” she said. “That puts them right back in the first stages of vulnerability disclosure grief: denial and anger.”

The former longtime Microsoft employee who ran outreach with the security community, created the company’s first bounty program and has given conference talks on the subject as far back as 2013, said the company doubled down on its lack of responsibility in the whole saga.

Microsoft declined to answer questions in the wake of the fallout.

Nightmare Eclipse hinted at a breakdown and impending battle with the vendor in a series of blog posts leading up to Microsoft’s missive about the vulnerabilities RedSun, UnDefend, BlueHammer, YellowKey, GreenPlasma, and MiniPlasma.

Attackers exploited three of the six vulnerabilities Nightmare Eclipse released before they were patched by Microsoft.

The researcher claimed Microsoft refused to communicate, didn’t pay or credit them for discovering and reporting some of the vulnerabilities, deleted the Microsoft Security Response Center account they used to disclose vulnerabilities and flagged their GitHub account for removal. 

“You are proving to everyone that you are actively escalating this conflict,” they wrote, before threatening Microsoft with a release in mid-July that “will make sure your bones are shattered that day.”

Vulnerability disclosure is a two-way street

The characteristics of proper vulnerability disclosure processes are nuanced and often framed in the eyes of the beholder.

Any successful dance between bug hunters and vendors comes down to meeting each other halfway, said Andrew Morris, founder and chief architect of GreyNoise. 

While vendors must fix software defects and prioritize security, Morris noted that irresponsible vulnerability disclosure harms both incident responders and potential victims. 

“Personally, I feel like this researcher is being extremely petty. It seems like they have an ax to grind,” he said.

“You’re not allowed to give somebody something and say it’s out of the kindness of your heart, and then be pissed when they don’t pay you for it.” 

But Morris also made clear that vendors bear responsibility for building trust with researchers.  

“If you actually care about being the first one to know about bugs in your software, not learning about it once harm has happened, or once somebody’s gotten popped, then you want to cultivate that trust with the security community,” Morris said. 

Microsoft said it recognizes that the relationship between security researchers and vendors is critical and, at times, fragile. 

“We deeply value the security community, and will continue to take your feedback seriously,” the company said in its post on X. 

Yet, the company remains steadfast in opposing the circumstances of Nightmare Eclipse’s disclosures, describing their actions as illegal, unjustifiable and irresponsible. 

“When an individual breaks the law and engages in malicious activity causing real harm to our customers, we will work with law enforcement as appropriate,” Microsoft said without naming the researcher by their moniker. “We continue to believe strongly in coordinated vulnerability disclosure as the foundation for protecting customers and improving our products. We know that, given the nature of this work, there will at times be misunderstandings. We remain committed to engaging in good faith and to providing a respectful and professional experience for all researchers, regardless of past interactions.”

The cost of pushback

Security researchers seek out defects for various reasons: bounty payouts, recognition, industry credibility, or simply the thrill of the hunt that comes with finding vulnerabilities and getting them fixed.

At its best, this process happens behind the scenes, with patches released and customers warned before exploitation occurs.

This collaborative approach has taken root and improved considerably, but there are still cases where researchers feel slighted. 

“The public has no idea what went on behind the scenes to judge why a researcher that previously coordinated finally had enough and decided to drop a zero-day [vulnerability],” Moussouris said. As such, she’s less inclined to criticize Nightmare Eclipse’s actions, adding that “they come off as someone who needs help.” 

Yet, trust breaks down between vulnerability researchers and vendors often. Earlier this week, security researcher Ammar Askar claimed his last interaction with Microsoft’s security team was so poor that he decided to publicly disclose any bugs he finds in VS Code going forward. He made good on that threat by dropping a vulnerability and exploit code for a defect that allows attackers to steal GitHub tokens. 

While actions like this can sabotage trust and drive a wedge between vendors and vulnerability researchers, recourse to a large extent is limited. Moussouris said most of the time, the legal and ethical boundaries are clear to those involved. Researchers can report bugs, withhold them, sell them, or publish them. “The one red line is crime: using a flaw to extort or attack people,” Moussouris said. 

“Threatening to publish on a set date is a threat to disclose, and disclosure is lawful. You can find the tone ugly. [Nightmare Eclipse] still broke no rule and violated no duty.” 

The timing couldn’t be worse 

Both sides are partly responsible for what happened, but Microsoft made things worse, Morris said. Threatening legal action and taking an aggressive approach have never worked. Building a good relationship between researchers and vendors requires open communication and trust. 

“I thought we were past this. It turns out that we are not,” he said. 

The Nightmare Eclipse incident comes at a fraught time in this space. Vendors and their customers are confronting a deluge of more vulnerabilities, and the rise of artificial intelligence models that discover them is exacerbating this challenge, leaving security experts alarmed about what’s coming.

The prospects for where vulnerabilities will be discovered and exploited next, and to what impact, are unknown and wildly unsettling. 

These signals imply that the classic, CVE-based system with responsibly disclosed processes is probably broken, Morris said. “There’s just so many CVEs. It’s like, is this even working anymore?”

For now and despite all its faults, coordinated vulnerability disclosure programs are widely viewed as the most sensible and scalable approach to this dilemma.

“Coordinated disclosure is what happens when a vendor gets lucky. Someone they did not hire hands them a real bug instead of using it or selling it. That puts the whole burden of keeping coordination alive on the vendor,” Moussouris said. “Silent patching with no CVE and calling out researchers who don’t follow your timeline for disclosure squanders the vendor’s luck.”  

She stressed the stakes: “I hope Microsoft and all vendors learn that coordinated vulnerability disclosure is a gift and a grace from the security researcher community to them, and public disclosure is still better than non-disclosure or crime.”

The alternatives to a deteriorating relationship could wreak havoc and leave every vendor and customer more susceptible to attack. 

“If vendors unlearn how to receive free intellectual property and labor from the security community in the form of vulnerability reports with gratitude, we’re headed for a world where nobody bothers to give vendors any heads up, or they move to a timed disclosure model that gives no grace,” Moussouris said.

She concluded with a direct message: “Product vendors wrote the vulnerable code, own the risk, and they owe it to their users to do everything in their power to reduce that risk.” That includes “keeping their grievances to themselves and learning from introspection on coordinated vulnerability disclosure gone wrong.”

The post Nightmare Eclipse incident shows the researcher-vendor fights may never fully go away appeared first on CyberScoop.

Google researchers found a zero-day exploit developed by artificial intelligence and alerted the susceptible vendor to the imminent threat before a well-known cybercrime group initiated a mass-exploitation campaign, the company said in a report released Monday.

The averted disaster probably isn’t the first time attackers used AI to build a zero-day, but it is the first time Google Threat Intelligence Group found compelling evidence that this long-predicted and worrying escalation in vulnerability-exploit development is underway.

“We finally uncovered some evidence this is happening,” John Hultquist, chief analyst at GTIG, told CyberScoop. “This is probably the tip of the iceberg and it’s certainly not going to be the last.”

Google declined to identify the specific vulnerability, which has been patched, or name the “popular open-source, web-based administration tool” it affected. It did, however, note that the defect impacted a Python script that allows attackers to bypass two-factor authentication for the service.

Researchers also withheld details about how they discovered the zero-day exploit or the cybercrime group that was preparing to use it for a large-scale attack spree.

The threat group has a “strong record of high-profile incidents and mass exploitation,” Hultquist said, suggesting the attackers are prominent and well-known among cybersecurity practitioners. 

GTIG is fairly confident the threat group was using AI in a meaningful way throughout the entire process, but it has yet to determine if the technology also discovered the vulnerability it ultimately developed into an exploit.

Whichever AI model the attackers used — Google is confident it wasn’t Gemini or Anthropic’s Mythos — left artifacts throughout the exploit code that are inconsistent with human developers. This evidence, which included documentation strings in Python, highly annotated code and a hallucinated but non-existent CVSS score, tipped Google off to the fact AI was heavily involved, Hultquist said. 

GTIG has been warning about and expecting AI-developed exploits to hit systems in the wild, especially after its Big Sleep AI agent found a zero-day vulnerability in late 2024.

“I think the watershed moment was two years ago when we proved this was possible,” Hultquist said, adding that there are probably several other AI developed zero-days in play now. 

Yet, to him, the discovery of a zero-day exploit developed by AI is less concerning than what this single instance forebodes even further.

“The game’s already begun and we expect the capability trajectory is pretty sharp,” Hultquist said. “We do expect that this will be a much bigger problem, that there will be more devastating zero-day attacks done over this, especially as capabilities grow.”

The post Google spotted an AI-developed zero-day before attackers could use it appeared first on CyberScoop.

Attackers are hitting Ivanti customers yet again — circling back to a common target and consistently susceptible vendor in the network edge space — by exploiting a zero-day vulnerability in one of the company’s most besieged products. 

Ivanti warned customers that attackers have successfully exploited CVE-2026-6973, an improper input validation defect in Ivanti Endpoint Manager Mobile (EPMM) that allows authenticated users with administrative privileges to run code remotely. The company alerted customers to the threat in a security advisory Thursday while also disclosing four additional high-severity vulnerabilities in the same product.

“At the time of disclosure, Ivanti is aware of very limited exploitation in the wild of CVE-2026-6973, which requires authenticated administrative access to implement,” a spokesperson for Ivanti said in a statement.

Ivanti did not say when the first instance of exploitation occurred, or precisely how many customers have already been impacted.

The Cybersecurity and Infrastructure Security Agency added the zero-day to its known exploited vulnerabilities catalog within hours of Ivanti’s disclosure.

The company released patches for all five vulnerabilities Thursday, including the four additional defects — CVE-2026-5787, CVE-2026-5788, CVE-2026-6973 and CVE-2026-7821 — which it said haven’t been exploited in the wild.

“Ivanti discovered these vulnerabilities in recent weeks through internal detection processes which are supported by advanced AI, customer collaboration, and responsible disclosure,” the company spokesperson said. One of the defects was discovered and responsibly reported to Ivanti by a former employee.

The company suggested at least one of the root causes for the latest zero-day may be traced to lingering risk posed by a pair of separate, critical zero-days — CVE-2026-1281 and CVE-2026-1340 — that were exploited starting in late January. The fallout from those exploited vulnerabilities in Ivanti EPMM spread to nearly 100 victims, including The Netherlands’ Dutch Data Protection Authority and the Council for the Judiciary, by early February.

The latest Ivanti EPMM zero-day “requires authenticated administrative access to exploit, which is why customers who followed Ivanti’s recommendation in January to rotate EPMM credentials are at significantly reduced risk. Customers unaffected by the prior vulnerability are also at a much lower risk,” the company spokesperson said.

Caitlin Condon, vice president of security research at VulnCheck, said the administrative privileges required to exploit CVE-2026-6973 indicates it was possibly exploited as part of an attack chain relying on another method for initial access. 

“No attribution was shared on threat actor exploitation of CVE-2026-6973, but two other 2026 CVEs in Ivanti EPMM — CVE-2026-1281 and CVE-2026-1340 — have been exploited by a range of threat actors, including China- and Iran-attributed groups,” Condon told CyberScoop. 

“Those vulnerabilities notably were code-injection vulnerabilities that were remotely exploitable without authentication, unlike CVE-2026-6973,” she added. “Both CVE-2026-1281 and CVE-2026-1340 appear to have been fixed in today’s Ivanti release. Comparatively, these earlier vulns were of higher initial concern than today’s fresh zero-day vulnerability, which requires admin authentication.”

Attacks involving Ivanti defects are a recurring problem for the vendor’s customers and security practitioners at large, including many vulnerabilities that attackers exploited before the company caught or fixed the errors. 

The Cybersecurity and Infrastructure Security Agency has flagged 34 Ivanti defects on its known exploited vulnerabilities catalog since late 2021. At least 22 defects across Ivanti products have been exploited in the past two years, including five vulnerabilities in Ivanti EPMM in the last year.

During an interview with CyberScoop in March at the RSAC Conference, Ivanti Chief Security Officer Daniel Spicer said the company’s transparency partly explains the high number of vulnerabilities reported and disclosed in its products. 

“My position here at Ivanti is it doesn’t do our customers any good to be quiet about this,” he said, describing the company’s communication stance with the public, CISA and global partners as “very aggressive.”

That’s not always the case with other vendors, Spicer said. “I don’t know that transparency is a core tenant of all other organizations.”

The company, which serves many government agencies and critical infrastructure operators, also routinely notes that highly skilled and resourced attackers, including those backed by nation-states, are often responsible for these waves of attacks on its customers.

Ivanti maintains that it’s trying to consistently improve the security of its products. “Through continued investment in its product security program, including the use of advanced AI paired with human verification, Ivanti is strengthening its ability to identify, remediate, and disclose issues quickly, helping customers stay ahead of an increasingly compressed threat landscape,” the spokesperson said.

The way Spicer put it in March: “We want to make sure that people understand that we are trying to do the right thing.”

The post Ivanti customers confront yet another actively exploited zero-day appeared first on CyberScoop.

Attackers are actively exploiting a zero-day vulnerability affecting some Palo Alto Networks’ customers’ firewalls, the security vendor said in an advisory Tuesday.

The critical memory corruption vulnerability — CVE-2026-0300 — affects the authentication portal of PAN-OS, and allows unauthenticated attackers to run  code with root privileges on the vendor’s PA-Series and VM-Series firewalls, the company said.

Palo Alto Networks did not say when or how it became aware of active exploitation, nor when the earliest known exploitation occurred. The Cybersecurity and Infrastructure Security Agency added the defect to its known exploited vulnerabilities catalog Wednesday.

The company hasn’t released a patch for the vulnerability or described the scope and objective of confirmed attacks.

“This vulnerability is specific to a limited number of customers with their User-ID Authentication Portal (Captive Portal) exposed to the public internet or untrusted IP addresses. We have observed limited exploitation of this issue and are working to release software fixes, with the first updates expected to be available on May 13,” a Palo Alto Networks spokesperson told CyberScoop.

The company said firewalls exposed to the buffer-overflow vulnerability, which has a CVSS rating of 9.3, are broadly exposed in real-world deployments, and it described the attack complexity as low.

Shadowserver scans found more than 5,800 publicly exposed VM-Series firewalls running PAN-OS as of Tuesday, yet it’s unknown how many of those instances have restricted authentication access to trusted internal IP addresses or disabled the feature altogether.

“We have provided clear mitigation guidance to our customers to secure their environments immediately. This issue does not impact Cloud NGFW or Panorama appliances. We remain committed to a transparent, security-first approach to protect our global customer base,” Palo Alto Networks’ spokesperson added.

Benjamin Harris, CEO and founder of watchTowr, noted that Palo Alto Networks proactively alerted customers to the zero-day, a step that allowed defenders to take action on potentially exposed instances. 

“In a bad situation, that is the best they can do immediately. However, that also alerts everyone to the existence of a vulnerability,” he told CyberScoop.

Despite the risk, Harris said watchTowr expects attacks linked to the zero-day exploit to be “very limited.” 

Palo Alto Networks and its impacted customers remain the only parties to have observed exploitation in the wild, but researchers warn that will likely change soon. 

“It’s likely rules will also start to fire in third-party organizations and honeypots shortly,” Caitlin Condon, vice president of security research at VulnCheck, told CyberScoop. 

“Management interfaces, login pages, and authentication portals have been common adversary targets for both opportunistic and targeted campaigns in recent years,” she added. “With researcher and community eyes on the vulnerability, it’s likely that we’ll see public exploits and broader exploitation quickly, provided the issue isn’t prohibitively difficult to exploit.”

Palo Alto Networks has yet to attribute the attacks to any known threat group, publish indicators or compromise, nor disclose the type of organizations that have been targeted and impacted. 

Researchers are hunting for malicious activity and advise customers to apply patches upon release.

The post A critical Palo Alto PAN-OS zero-day is being exploited in the wild appeared first on CyberScoop.