Researchers at Google Threat Intelligence Group (GTIG) say that a zero-day exploit targeting a popular open-source web administration tool was likely generated using AI.

The exploit could be leveraged to bypass the two-factor authentication (2FA) protection in a popular open-source, web-based system administration tool that remains unnamed.

Although the attack was foiled before the mass exploitation phase, the incident shows that threat actors are relying more on AI assistance for their vulnerability discovery and exploitation efforts.

Based on the structure and content of the Python exploit code, Google has high confidence that the adversary used an AI model to find and weaponize the vulnerability.

"For example, the script contains an abundance of educational docstrings, including a hallucinated CVSS score, and uses a structured, textbook Pythonic format highly characteristic of LLMs training data," GTIG says in a report today.

The large language model (LLM) used for the malicious task remains unclear, but Google rules out the possibility that Gemini was involved in the process.

Additional evidence suggesting the use of LLM tools in the discovery process is the nature of the flaw - a high-level semantic logic bug that AI systems excel at identifying, rather than memory corruption or input sanitization issues typically uncovered through fuzzing or static analysis.

Source: Google

Google notified the software developer about the significant threat and timely action to disrupt the attack.

“For the first time, GTIG has identified a threat actor using a zero-day exploit that we believe was developed with AI,” GTIG researchers say.

Apart from this case, Google notes that Chinese and North Korean hackers, such as APT27, APT45, UNC2814, UNC5673, and UNC6201, have been using AI models for vulnerability discovery and exploit development, continuing the trend observed in the .

Russia-linked actors were also observed using AI-generated decoy code to obfuscate malware such as CANFAIL and LONGSTREAM.

CANFAIL code comments for the decoy logic Source: Google

Google has also highlighted a Russian operation codenamed “Overload,” where social engineering threat actors used AI voice cloning to impersonate real journalists in fake videos promoting the anti-Ukraine narrative.

The , documented by ESET earlier this year, is also highlighted in Google’s report for its integration with Gemini APIs for autonomous device interaction.

However, Google also found an autonomous agent module named "GeminiAutomationAgent" that uses a hardcoded prompt to enable the malware to interact with the device in an automated way.

According to the researchers, the role of the prompt is to assign a benign persona so it can bypass the LLM's safety features. The goal is to calculate the geometry of the user interface bounds, which PromptSpy could use to interact with the device in multiple ways.

Furthermore, the malware makes use of AI-based capabilities to replay authentication on the device, be it in the form of a lock pattern or a PIN, Google researchers say.

The company is warning that threat actors are now industrializing access to premium AI models using automated account creation, proxy relays, and account-pooling infrastructure.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

Password resets are often the first response to a suspected compromise. It makes sense; resetting credentials is a quick way to cut off an attacker’s most obvious path back in.

However, that doesn’t always completely solve the issue. In both Active Directory (AD) and hybrid Entra ID environments, password changes do not immediately invalidate the old credential across every authentication path.

Even a short window is an opportunity that potentially allows attackers to maintain access or re-establish a foothold.

For security architects and IT administrators, this gap has real implications during incident response.

The password reset gap

Windows systems cache password hashes locally to support offline logon. If a device hasn’t reconnected to the domain, it may still hold the previous credential in a usable form. In , there can also be a short delay before the new password syncs to Entra ID.

This means there are three possible states created after a password reset:

1. The user has logged in with the new credential while connected to AD. The cached credential store updates, invalidating the old hash.

2. The user has not logged in to a particular machine since the reset. The old cached credential may still be usable for certain authentication attempts.

3. In hybrid deployments, the password has been reset in AD but the new hash has not yet synchronized to Entra ID. The old password may still authenticate during the password hash synchronization interval.

Verizon’s Data Breach Investigation Report found stolen credentials are involved in 44.7% of breaches.

Effortlessly secure Active Directory with compliant password policies, blocking 4+ billion compromised passwords, boosting security, and slashing support hassles!

How attackers exploit the gap

Cached credentials

Attackers take advantage of cached password hashes with methods like , where the hash itself is used instead of the plaintext password. If that hash was captured before the reset, changing the password doesn’t immediately invalidate it everywhere.

Limiting that exposure is crucial to defending AD environments. Solutions like enable secure self-service password resets by enforcing end-user ID verification to reduce the risk of reset abuse.

When combined with the Specops Client, uReset can update the local cached credential store immediately on the device where the reset is performed, closing the window where the old hash remains usable on that endpoint.

This doesn’t remove identity drift entirely, but it does reduce exposure at the network edge, where corporate laptops and remote systems are frequently targeted.

Specops uReset

Active sessions

AD authentication is primarily handled through Kerberos tickets, which are valid for a set period of time. If a user or attacker already has a valid ticket, they can continue accessing resources without re-entering a password.

That means an attacker with an active session remains authenticated even after the password has been changed. In some cases, that window is long enough to establish additional persistence or move laterally.

Unless sessions are explicitly invalidated, through logoff, reboot, or ticket purging, access can continue well beyond the reset itself.

Service accounts

Unlike user accounts, service accounts tend to have long-lived passwords, with elevated privileges tied to critical systems. Attackers can expose those credentials through techniques like or discover them when moving laterally through a network.

Because these accounts are tied to running services, they’re less likely to be reset quickly, especially if there’s a risk of disruption. That makes them a reliable fallback for attackers after an initial access point is closed.

Ticket attacks

As mentioned above, in environments using the Kerberos authentication protocol, access is controlled through tickets rather than repeated password checks. If an attacker can forge those tickets, they don’t need valid credentials at all.

A Golden Ticket attack, made possible by compromising the Kerberos Ticket Granting Ticket account, allows attackers to create valid ticket-granting tickets for any user in the domain. Silver Tickets are more targeted, granting access to specific services without contacting a domain controller.

In both cases, these attacks effectively bypass password changes. Resetting user passwords won’t invalidate forged tickets, and access can continue until the underlying issue is addressed.

Permissions

AD is heavily driven by Access Control Lists (ACLs). If an attacker grants a compromised account (or a new one they control) rights like resetting passwords for other users, they’ve effectively created a backdoor. Even if the original password is changed, those permissions remain.

Furthermore, accounts protected by AdminSDHolder (like Domain Admins) inherit permissions from a specific template. Attackers who modify the ACL on the AdminSDHolder object can ensure their permissions are re-applied every hour by SDProp.

How to ensure attackers are removed

The time between a password reset and it synching across AD and Entra ID is small, typically just a few minutes, which severely limits the opportunity attackers have to exploit the gap. Forcing more frequent synchronizations is also possible, for instance turning on AD Change Notification or manually initiating a Sync to the Entra ID tenant.

However, the gap still exists, and by the time an account compromise is discovered, attackers may have been able to establish additional footholds. If password resets aren’t enough on their own, defenders need to look at fully closing off access.

That starts with invalidating anything already in play. Active sessions should be terminated, and Kerberos tickets cleared by forcing logoffs or reboots on affected systems. For more serious compromises, resetting the KRBTGT account (twice) is often necessary to invalidate forged tickets.

Next comes credential hygiene beyond standard user accounts. should be rotated, especially those with elevated privileges, and any cached credentials on endpoints should be cleared as systems reconnect.

Just as important is reviewing what’s changed in the directory itself. That means auditing:

• Group memberships

  • Delegated rights and ACLs

  • Privileged accounts and roles

Look for anything that could allow access to be re-established without relying on a password.

For serious breaches, there isn’t a single step that guarantees eviction. It’s a combination of cutting off sessions, rotating the right credentials, and verifying that no hidden access paths remain.

Secure your AD today

Hardening your AD requires every account to be protected by strong passwords, combined with a secure reset process that limits opportunities for abuse.

Specops helps you do both, giving you confidence that password resets strengthen your security rather than introduce new gaps.

to see how our solutions can support your identity security strategy.

Sponsored and written by .*

A malicious Hugging Face repository that reached the platform’s trending list impersonated OpenAI’s “Privacy Filter” project to deliver information-stealing malware to Windows users.

The repository briefly reached #1 on Hugging Face and accumulated 244,000 downloads before the platform responded to reports and removed it.

The Hugging Face platform lets developers and researchers share AI models, datasets, and machine learning (ML) tools. Models are pre-trained AI systems hosted on the platform comprising weight files, configuration, and code.

Researchers at HiddenLayer, a company focused on safeguarding AI and ML models against attacks, discovered the campaign on May 7, after noticing a malicious repository named Open-OSS/privacy-filter.

“The repository had typosquatted OpenAI's legitimate Privacy Filter release, copied its model card nearly verbatim, and shipped a loader.py file that fetches and executes infostealer malware on Windows machines,” the .

Instructions from the malicious repository Source: HiddenLayer

The ‘loader.py’ Python script included fake AI-related code to appear harmless, but in the background, it disabled SSL verification, decoded a base64 URL pointing to an external resource, and then fetched and executed a JSON payload containing a PowerShell command.

The command, which is executed in an invisible window, downloads a batch file (start.bat) that performs privilege escalation, downloads the final payload (sefirah), adds it to Microsoft Defender's exclusions for it, and executes it.

The final payload is a Rust-based infostealer that targets the following sensitive data:

• Browser data from Chromium- and Gecko-based browsers (e.g., cookies, saved passwords, encryption keys, browsing data, session tokens)

  • Discord tokens, local databases, and master keys

  • Cryptocurrency wallets and wallet browser extensions

  • SSH, FTP, and VPN credentials and configuration files, including FileZilla

  • Sensitive local files and wallet seeds/keys

  • System information

  • Multi-monitor screenshots

The stolen data is compressed and exfiltrated to a command-and-control (C2) server at recargapopular[.]com.

HiddenLayer highlights the malware’s extensive anti-analysis features, which include checks for virtual machines, sandboxes, debuggers, and analysis tools, all with the purpose of evading analysis systems.

The exact number of victims in this incident is unclear, and the researchers note that the vast majority of the 667 accounts that liked the malicious repository on Hugging Face appear to be auto-generated. Additionally, the 244,000 download count may have been artificially inflated.

By examining those, the researchers uncovered other repositories that used the same malicious loader infrastructure. HiddenLayer researchers also noticed overlaps with an npm typosquatting campaign distributing the WinOS 4.0 implant.

Users who downloaded files from the malicious repository are advised to reimage the machine, rotate all stored credentials, replace cryptocurrency wallets and seed phrases, and invalidate browser sessions and tokens.

Threat actors have abused Hugging Face in the past to , despite the platform's security measures.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

The website for the popular JDownloader download manager was compromised earlier this week to distribute malicious Windows and Linux installers, with the Windows payload found deploying a Python-based remote access trojan.

The supply chain attack affects those who downloaded installers from the official website between May 6 and May 7, 2026 via the Windows "Download Alternative Installer" links or the Linux shell installer.

According to the developers, the attackers modified the website's download links to point to malicious third-party payloads rather than legitimate installers.

JDownloader is a widely used free download management application that supports automated downloads from file-hosting services, video sites, and premium link generators. The software has been available for more than a decade and is used by millions worldwide across Windows, Linux, and macOS.

The JDownloader supply chain attack

The compromise was first reported on by a user named "PrinceOfNightSky," who noticed that downloaded installers were being flagged by Microsoft Defender.

"I been using Jdownloader and switched to a new PC a few weeks ago. Luckily I had the installer in a usb drive but decided to download the latest version," posted PrinceOfNightSky to Reddit.

"The website is official but all the Exes for windows are being reported as malicious software by windows and the developer is being listed as 'Zipline LLC.' And other times it's saying 'The Water Team' The software is obviously by Appwork and I have to manually unblock it from windows to run it which I will not do."

The JDownloader developers that the site had been compromised and took the website offline to investigate the incident.

In an , the devs said their website was compromised by attackers exploiting an unpatched vulnerability that allowed them to change website access control lists and content without authentication.

"Changes were made through the website's content management system, affecting published pages and links," reads the incident report.

"The attacker did not gain access to the underlying server stack — in particular no access to the host filesystem or broader operating-system-level control beyond CMS-managed web content."

The developers stated that the compromise affected only the alternative Windows installer download links and the Linux shell installer link. In-app updates, macOS downloads, Flatpak, Winget, Snap packages, and the main JDownloader JAR package were not modified.

The developers also said that users can confirm if an installer is legitimate by right-clicking the file, selecting Properties, and then clicking the Digital Signatures tab.

If Digital Signatures shows it was signed by "AppWork GmbH," then it is legitimate. However, if the file is not signed or is by a different name, it should be avoided.

Signed legitimate JDownloader installer Source: BleepingComputer

The JDownloader team said that analyzing the malicious payloads was "out of our scope," but shared an archive of the malicious installers so that others could analyze them.

Cybersecurity researcher analyzed the malicious Windows executables and shared indicators of compromise (IOCs) for the malware.

According to Klemenc, the malware acts as a loader that deploys a heavily obfuscated Python-based RAT.

Klemenc said the Python payload acts as a modular bot and RAT framework, allowing attackers to execute Python code delivered from the command and control (C2) servers.

The researcher also shared two command and control servers used by the malware:

https://parkspringshotel[.]com/m/Lu6aeloo.php https://auraguest[.]lk/m/douV2quu.php

BleepingComputer's analysis of the modified Linux shell installer found malicious code injected into the script that downloads an archive from 'checkinnhotels[.]com' disguised as an SVG file.

Malicious code in the modified JDownloader Linux installer Source: BleepingComputer

Once downloaded, the script extracts two ELF binaries named 'pkgandsystemd-exec` and then installs 'systemd-exec' as a SUID-root binary in '/usr/bin/'.

The installer then copied the main payload to '/root/.local/share/.pkg', created a persistence script in '/etc/profile.d/systemd.sh', and launched the malware while masquerading as '/usr/libexec/upowerd`.

The 'pkg' payload is also heavily obfuscated using Pyarmor, so it is unclear what functionality it performs.

JDownloader says users are only at risk if they downloaded and executed the affected installers while the site was compromised.

As arbitrary code could have been executed by the malware on infected devices, those who installed the malicious installers are advised to reinstall their operating systems.

It is also possible that credentials were compromised on devices, so it is strongly advised to reset passwords after cleaning the devices.

Hackers have increasingly targeted the websites of popular software tools this year to distribute malware to unsuspecting users.

In April, hackers to change download links that served malicious executables for the popular CPU-Z and HWMonitor tools.

Earlier this month, threat actors to distribute trojanized installers containing a backdoor.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

By Rich Perkins, Principal Sales Engineer, Prophet Security

Your security spend has roughly . Your time-to-investigate and respond hasn't moved. Your CFO is asking why the security headcount keeps growing while the metrics that matter to the business don't.

The architecture under your SOC is the reason. Not your team. Not your tooling investment. Not your hiring funnel. The operating model your program inherited assumed human-driven at the volume the business was producing five years ago, and the business stopped producing alerts at that volume a long time ago.

This is a piece about why hiring more analysts won't close the gap, what changes when you fix the model instead, and the specific limitations and questions that should shape any . It includes a four-question diagnostic you can run on your own program in the time it takes to finish a coffee.

The math the industry doesn't want to admit

Google Mandiant's recent reporting puts global median dwell time at 14 days. The same report found that in 2025 the “hand-off” window between initial access and subsequent transfer to secondary threat group collapsed to just 22 seconds, a 95% drop from the 8 hours from 2022. Crowdstrike’s 2026 Global Threat report uncovered similar trends, with the average breakout time falling to 29 minutes, from initial access to exfiltration.

IBM's most recent research puts the average time to identify and contain a breach in 2025 at 241 days, with an average cost of $4.88 million. That’s a drop of 16% from 2020, when the time to identify and contain a breach stood at 281 days. Those numbers have not improved at the pace security spending would suggest, despite that spending having roughly doubled in five years, nor have they kept up with the shorter “breakout” or “hand-off” window

This isn't framed to scare defenders into chasing the next hype. It's the operating reality. Money in, complexity in, but the curve from detection to investigation and containment barely moves.

SOC teams have already done the obvious efficiency moves. They tier severity. They auto-close known-benign alert classes. They suppress noisy detection rules. They tune. They route. That's not the problem.

The problem is that even after all of that work, the volume that lands on humans for actual investigation still exceeds what humans can investigate at the depth required. We’ve written an entire ebook on how the SOC queue is the breach, which you can .

In the deployments I've worked across, the post-tiering volume that hits human triage typically lands in the 120 to 150 alerts per day range. At 20 minutes per investigation including documentation, that's 40 to 50 analyst-hours daily. SOC teams of 5 to 10 analysts can cover the top of that range during business hours, leaving the rest of the queue for the next shift, the next day, or never.

That's the gap that doesn't close with more headcount. You can't hire enough analysts to investigate 100% of post-tiering volume at the depth the work requires. You can hire your way to better coverage at the margins. You cannot hire your way to the model change.

Most breaches don't trigger a high severity alert. Instead the first signs appear in a low severity alert that gets buried in a queue no human can clear.

This ebook from Prophet Security breaks down why the alert backlog is the actual attack surface, and what changes when AI investigates every alert.

A diagnostic you can run on your own SOC

Before going further, run these four questions on your program. Honestly. The answers map your blind spots more reliably than any vendor pitch will.

1. What percentage of alerts above your defined investigation threshold did your team actually investigate last quarter? If less than 90%, you have a coverage gap that's hiding real risk. The gap exists because of how the work flows, not because anyone is dropping the ball. More headcount won't close it.

2. How many detection rules has your team suppressed in the last 12 months without an engineering ticket to replace the coverage? Suppressing noisy rules is healthy tuning. Suppressing them without follow-up engineering to replace what they were watching is debt. Each undocumented suppression is an attack surface you've stopped watching, and the threats those rules were designed to catch don't go away because you disabled them.

3. What was your senior analyst turnover last year, and how long did each replacement take to reach productive contribution? If turnover exceeds 15% or ramp exceeds 6 months, your bench is fragile. You're one resignation away from operational impact. Tribal knowledge walking out the door is a single point of failure most programs don't have a remediation plan for.

4. If alert volume doubled tomorrow, what's the first thing your team would stop doing? The honest answer is the part of your program that's already underwater. Whatever you'd cut first is what's currently holding on by a thread. That's where to focus the operating model conversation.

If three or more of these answers concern you, the productive conversation moves past hiring and into a different question: whether the architecture under your team can carry the program you actually want to run.

What changes when the model fixes

The teams making real progress aren't the ones hiring more analysts. They're the ones changing what work humans are required to do at all.

JB Poindexter & Co, an 8,500-employee diversified manufacturer, deployed Prophet AI in 2025. In the first 60 days, they through the platform with a mean time to investigate under 4 minutes.

That's 73 investigations per day at depth, against a Mandiant industry median dwell time measured in days. The deployment returned roughly 1,469 hours of analyst time to their team, equivalent to 6.3 analyst-years of investigation capacity at full annualization.

Their CISO, John Barrow, framed the outcome as "faster, more focused, and able to scale without adding immediate headcount."

The operating model shift in that sentence is what matters. Not "we hired more people." Not "we worked our existing people harder." The work no longer required the same number of people.

Cabinetworks ran through Prophet AI in 33 days. Six escalated to a human. The unexpected outcome was a 90% reduction in SIEM costs, primarily from no longer needing to ingest and store raw EDR and identity telemetry that had been pulled into the SIEM purely for analyst pivot queries.

When the AI handles those pivots directly against source systems, that ingest tier becomes optional. The line item that gets cut isn't the obvious one, and most teams don't model that secondary saving when they evaluate AI SOC tools. They should. For programs running enterprise SIEM contracts in the seven-figure range, the secondary savings often exceed the cost of the AI platform itself.

A second outcome worth noting: when the queue clears, teams stop having to ignore low and medium severity alerts. Most SOCs quietly stop investigating those classes under capacity pressure, even when their security leadership knows the coverage gap matters. A medium-severity alert isn't risky because it's medium.

It's risky because that's where real attackers hide while your team is buried in critical-severity noise. Bringing the medium and low tiers back into investigation scope is the coverage shift most teams want and very few can resource.

Every deployment requires two to four weeks of focused tuning before reaching steady state.

How CISOs are funding this

The piece a CISO is mentally writing while reading vendor content is the budget request. Where does this money come from?

Three patterns I've seen work, in order of CISO political difficulty.

Path one: Unapproved headcount budget. The cleanest funding path. The team has approved or pending headcount the program hasn't filled, and the AI platform replaces the need to hire that role. Fully loaded cost for a Tier 2 analyst typically runs $180K to $300K depending on market and seniority, which sets the floor for what the AI platform needs to displace to make the math work.

The JB Poindexter pattern fits here. The "scaling without adding immediate headcount" framing is procurement language for "this is what we're doing instead of approving the next hire."

Path two: SIEM cost reduction. If your team is using the SIEM as an investigation pivot workspace (raw EDR telemetry, identity logs, network data), and the AI platform takes over those pivots, the SIEM ingest and storage tier becomes optional.

The Cabinetworks pattern. SIEM ingest savings depend heavily on volume but commonly run 30 to 60 percent of total SIEM spend when investigation telemetry is the main driver.

For programs running mid-six-figure or seven-figure SIEM contracts, this funding path can fully cover the AI platform with savings left over. Get your SIEM renewal cycle date before you start the evaluation, because the timing matters.

Path three: Tool displacement. The hardest political fight. Replacing an existing SOAR, an existing case management workflow, or an existing managed service. The savings vary too widely to generalize, but the displacement creates internal opposition from whoever owns the displaced tool. Plan for it as a 6-month change management project, not a procurement decision.

Most programs end up funding through a combination of paths one and two. Path three is a year-two conversation, not a year-one one.

Where humans still need to lead

I'm pro AI SOC. I work for one. So when I tell you where it isn't the right tool, take it seriously. Three categories where I'd recommend keeping humans in the lead.

Insider threat investigations where the signal lives in human context, not logs. AI does fine on the DLP-shaped insider threat work where the signal is in telemetry: unusual file movement, exfil to personal cloud, after-hours pulls of sensitive repos. Where it struggles is the harder subset where the deciding signal isn't in any log.

The PIP that started Monday. The conversation a manager had two weeks ago. The contractor whose contract ends Friday. AI doesn't have that context. Your humans do.

The right design splits the work cleanly: AI handles the telemetry layer, your team handles the human-context layer. Asking one tool to do both is where these investigations break down.

Novel TTPs with no analog in training data. AI investigation is fundamentally pattern-matching over historical examples. By definition, that's weakest on attacks that don't look like anything you've seen. Your senior threat hunters earn their keep on the alerts that don't match anything in the catalog. Don't outsource that work.

Highly regulated environments where data residency rules dictate where alert telemetry can live. If your compliance posture won't let metadata leave a specific cloud or country, most AI SOC platforms (Prophet AI included) require real architecture work to fit. Some can't fit at all. Don't let any vendor wave that concern away with a slide.

If you're evaluating an AI SOC tool, ask the vendor exactly where their tool fails. If they don't have an answer ready, that's the answer.

Three questions buyers always ask

Three questions come up in almost every evaluation, and they deserve direct answers.

What happens when the AI gets it wrong? Prophet AI documents every step of every investigation. Every question asked, every query run, every piece of evidence pulled, the reasoning that led to the verdict. When a verdict is wrong, the chain of reasoning shows exactly where it went wrong, and your team can encode the correction back into Guidance so the same mistake doesn't repeat.

That's a different audit trail than the three-sentence case notes most analysts write under queue pressure today, and it matters more than vendor content typically acknowledges.

Regulators are starting to ask about AI-driven security decisions. Boards are asking about defensible documentation of what the SOC investigated and why. Post-incident reviews are easier to run when the evidence chain is complete by default. The audit trail isn't a feature. It's how you keep your seat at the table when the auditor or the board comes asking.

What happens to detection engineering? This is the question senior practitioners ask first, and it's the right question. You might worry that if AI handles investigation, your team loses the natural feedback loop where analysts catch and tune noisy detections. The honest answer: that work moves explicitly upstream.

Instead of relying on manual triage to spot noise, comprehensive investigation data as a massive feedback loop, shifting the focus from suppressing alerts to equipping the AI with better context..

To make that upstream work happen, detection engineering shifts from an emergent activity squeezed between alerts to a scheduled discipline owned by the senior analysts whose triage time the AI has freed up. Teams that fail to operationalize that shift see detection quality drift over time. Teams that operationalize it well see detection quality improve, because the engineering happens with intention and dedicated focus.

What does the buying committee look like? AI SOC platforms touch security operations, but the procurement conversation often pulls in IT (for integrations and identity), compliance (for data handling and audit posture), legal (for the data processing agreement and AI-specific contractual terms), and procurement (for vendor risk review).

Plan for that early. Programs that try to push AI SOC through as a security-team decision often hit a six-week delay when compliance discovers the data flow questions in week four. Programs that bring compliance and legal in at the start of the evaluation typically close in half the time.

The vendor-risk question worth asking

One question vendor content almost never addresses directly, and CISOs care about it more than vendors realize: what happens to your program if the AI SOC vendor gets acquired, pivots, or fails? Three-year procurement cycles outlast a lot of vendor strategies.

Three things worth confirming with any AI SOC vendor before signing.

First, data portability: can you export your investigation history, Guidance configurations, and detection logic in a format that survives a vendor change?

Second, runbook independence: are the human-readable Guidance rules you encoded specific to this vendor, or do they document SOC logic your team could rebuild elsewhere?

Third, contractual continuity: what happens to service obligations, data handling, and support during an acquisition or wind-down event?

The third tends to separate the serious vendors from the rest. Most can answer the first two. Few have a clean answer to the third without significant pre-work, which is itself a signal worth noting during evaluation.

Closing thought

Prophet Security's operationalizes expert analyst techniques at machine speed across all alert volumes, regardless of severity, to ensure a consistently clear triage queue and preemptively neutralize threats.

If your honest answers to the four diagnostic questions earlier in this piece concerned you, the next conversation isn't whether AI SOC is the answer. It's what your senior analysts would actually do with their Tuesday mornings if the triage queue weren't running them.

That's the operating model question. Whether you solve it with Prophet Security or someone else, the architecture is what needs to change. Hiring more analysts to triage at machine-generated volume is a strategy that worked in 2018. The math hasn't worked since 2022.

The teams that change the architecture will get a different conversation with their board next year. The teams that don't will get the same one they had last year, with a slightly higher number on the spend line and the same number on the time-to-detect line.

Pick the conversation you want to be having.

If your SOC is dealing with alert overload or long investigation times, we’d be happy to show you what Prophet AI looks like in practice. or reach out directly to learn more.

Rich Perkins is a Principal Sales Engineer at Prophet Security. Reach him at or connect on .

Sponsored and written by .*

NVIDIA has confirmed in a statement for BleepingComputer that GeForce NOW user information has been exposed in a data breach.

The gaming and hardware giant has clarified that the impact is limited to Armenia, and was caused by a compromise of the infrastructure operated by a regional partner.

The company added that its own network was not impacted by the incident.

“Our investigation found no impact on NVIDIA-operated services. The issue is limited to systems run by a third-party GeForce NOW Alliance partner based in Armenia. We are working closely with the partner to support their investigation and resolution. Impacted users will be notified by GFN.am,” the company said.

The statement comes in response to a post last week on a hacker forum from a threat actor using the ShinyHunters nickname, claiming to have breached the GeForce NOW service and stolen millions of user records.

However, the ShinyHunters actor who published the breach on the hacker forum is believed to be an imposter.

According to the threat actor, the stolen information includes full names, email addresses, usernames, dates of birth, membership status, and 2FA/TOTP status.

The threat actor also posted samples of the stolen data and offered the full database for $100,000 paid in Bitcoin or Monero.

The NVIDIA GeForce NOW cloud gaming service lets users stream to their systems games running on more powerful hardware using NVIDIA GPUs in a datacenter.

GFN.am is the , responsible for operating NVIDIA’s service in the country.

Alliance partner environments can operate independent authentication systems, local customer databases, regional billing platforms, and locally managed infrastructure.

A confirms a cybersecurity incident that took place between March 20 and 26 and exposed the following information:

• Full name (if using a Google account)

  • Email address

  • Phone number (if registered through a mobile operator)

  • Date of birth

  • Username

GFN.am has clarified that no account passwords were exposed in the incident, and any users who registered to the service after March 9 are not impacted.

According to NVIDIA’s , GFN.am is also responsible for managing GeForce NOW operations in Azerbaijan, Georgia, Kazakhstan, Moldova, Ukraine, and Uzbekistan, but no impact on those countries has been confirmed.

BleepingComputer found that the threat actor’s post has now been removed from the hacker forum.

It is unclear if the database has been sold to a buyer or if the seller or forum administrators deleted it.

Update [14:14]: Added information that the threat actor may be a ShinyHunters impersonator.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has given U.S. federal agencies four days to secure their networks against a high-severity vulnerability in Ivanti Endpoint Manager Mobile (EPMM) that has been exploited in zero-day attacks.

Tracked as CVE-2026-6973, this security flaw allows attackers with administrative privileges to execute arbitrary code remotely on systems running EPMM 12.8.0.0 and earlier.

In a , Ivanti told customers they can secure their appliances by installing Ivanti EPMM 12.6.1.1, 12.7.0.1, and 12.8.0.1, and advised them to review accounts with Admin rights and rotate those credentials where necessary.

"At the time of disclosure, we are aware of very limited exploitation of CVE-2026-6973, which requires admin authentication for successful exploitation. We are not aware of any customers being exploited by the other vulnerabilities disclosed today," .

"The issues only affect the on-prem EPMM product, and are not present in Ivanti Neurons for MDM, Ivanti's cloud-based unified endpoint management solution, Ivanti EPM (a similarly named, but different product), Ivanti Sentry, or any other Ivanti products."

Nonprofit security organization Shadowserver now tracks exposed online. However, there is no information on how many have already been patched against the CVE-2026-6973 vulnerability.

Ivanti EPMM appliances exposed online (Shadowserver)

​​​On Thursday, CISA the security flaw to its and mandated that federal agencies patch their EPMM systems by midnight Sunday, May 10.

"This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks to the federal enterprise," CISA warned.

In late January, Ivanti patched (CVE-2026-1281 and CVE-2026-1340) that were exploited in zero-day attacks affecting a "very limited number of customers." On April 8, CISA also gave U.S. government agencies four days to against attacks targeting the CVE-2026-1340 flaw.

"If customers followed Ivanti's recommendation in January to rotate credentials if you were exploited with CVE-2026-1281 and CVE-2026-1340, then your risk of exploitation from CVE-2026-6973 is significantly reduced," .

Ivanti provides IT asset management solutions to over 40,000 clients worldwide, supported by an extensive network of over 7,000 partners.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

The attack on the Trellix source code repository disclosed last week has been claimed by the RansomHouse threat group, which leaked a small set of images as proof of the intrusion.

Yesterday, the threat actor published on their data leak site screenshots indicating access to the cybersecurity company's appliance management system. However, BleepingComputer could not confirm the authenticity of the data.

Trellix is an international cybersecurity firm with global Fortune 100 customers. In 2025, the company had more than 53,000 customers in 185 countries and 3,500 employees.

The company confirmed the breach in a statement on May 1st and said that it was investigating the incident. "Trellix recently identified unauthorized access to a portion of our source code repository. Upon learning of this matter, we immediately began working with leading forensic experts to resolve it," .

"We have also notified law enforcement. Based on our investigation to date, we have found no evidence that our source code release or distribution process was affected, or that our source code has been exploited."

At the time, BleepingComputer’s request for details went unanswered, and the company did not disclose any information about the perpetrators.

Following a new request for comments after RansomHouse’s disclosure, Trellix told BleepingComputer that it was "aware of claims of responsibility for the attack and are looking into it."

According to the threat actor, the intrusion occurred on April 17 and resulted in data encryption.

Trellix listed on the RansomHouse extortion portal Source: BleepingComputer

RansomHouse is a cybercrime group that as a data-extortion operation, listing victims on a darkweb portal and leaking or selling data stolen from their corporate networks.

Over time, the threat actor added more advanced encryption utilities to their toolkit, such as ‘,’ which performs a dual-encryption pass with two keys on target files, and ‘,’ which automates the deployment of encryptors on VMware ESXi hypervisors.

A recent high-profile case involving RansomHouse was that of Japanese e-commerce giant , from which the threat group stole 740,000 customer records, among other sensitive information.

Trellix’s investigation is still underway, and the company previously promised to once they become available.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

Two U.S. nationals were sentenced to 18 months in prison each for operating so-called laptop farms that helped North Korean IT workers fraudulently obtain remote employment at nearly 70 American companies.

Matthew Isaac Knoot and Erick Ntekereze Prince are the seventh and eighth U.S.-based "laptop farmers" sent to prison since the start of the year as part of a federal initiative targeting North Korea's illicit revenue generation schemes.

"These sentences hold accountable U.S nationals who enabled North Korea's illicit efforts to infiltrate U.S. networks and profit on the back of U.S. companies," on Wednesday. "These defendants helped North Korean' IT workers' masquerade as legitimate employees, compromising U.S. corporate networks and helping generate revenue for a heavily sanctioned and rogue regime.

Knoot (who in August 2024) ran a laptop farm from his Nashville residences between July 2022 and August 2023.

During the scheme, he received company-issued laptops addressed to a stolen identity ("Andrew M."), then installed unauthorized remote desktop software that allowed North Korean IT workers to appear as a legitimate U.S.-based employee.

Victim companies paid more than $250,000 to IT workers associated with Knoot's operation, with the payments falsely reported to the Social Security Administration and the Internal Revenue Service under stolen identities.

Prince (who in November) enabled at least three North Korean IT workers to obtain remote employment at U.S. companies from approximately June 2020 through August 2024, operating through his company, Taggcar Inc. Victim companies paid the IT workers hired with the help of Prince more than $943,000 in salary, the majority of which was routed overseas.

Knoot also caused more than $500,000 in auditing and remediation costs at victim companies, while Prince's actions caused more than $1 million in remediation costs. In addition to their 18-month prison sentences, Knoot was ordered to pay $15,100 in restitution and forfeit an additional $15,100, and Prince was ordered to forfeit $89,000.

The FBI about North Korean IT workers since at least 2023 and noted that North Korea maintains a using identity theft to secure employment at each year.

In April, U.S. nationals Kejia Wang and Zhenxing Wang for helping North Korean remote information technology (IT) workers to pose as U.S. residents.

Last July, a 50-year-old Christina Marie Chapman from Arizona for running a laptop farm in her own home, as part of a scheme that helped North Korean IT workers get hired by 309 U.S. companies while using stolen identities.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

The Modern DLP Blind Spot

Preventing sensitive data loss has historically been treated as an endpoint or network problem. Deploy an agent, inspect files, monitor traffic, and you have coverage—or so you think.

Our recent analysis shows that , exposing a significant gap in how organizations monitor and control the flow of data moving throughout their digital ecosystem.

Security teams think they have significant DLP coverage, but they’re actually lacking visibility and control into where data is often moving today: in the browser.

Why DLP is Failing, Browser Work is Hidden

Enterprise workflows have shifted from software on the endpoint to browser-based applications. Today, employees commonly use Google Workspace, Microsoft 365, or Salesforce; developers utilize GitHub, Jira, and internal web apps; and many departments now embrace AI tools like ChatGPT and copilots.

Instead of downloading, modifying, and re-uploading files to sanctioned web apps, users are interacting with data directly in the browser by copying data from or between applications, uploading files to various tools, and inputting data into web forms and AI prompts.

Compounding the risks of these activities is the simple fact that employees often use personal accounts and unsanctioned instances without restriction.

In other words, the traditional DLP controls your team relies on aren’t instrumented where much of the modern activity is happening.

See how Keep Aware protects sensitive data directly in the browser—without slowing your team down. Get real-time visibility, smart alerts, and seamless control over data movement across AI tools and other apps.

Book a demo to see browser-native data loss prevention in action.

How Sensitive Data Actually Leaves the Browser

To understand why existing DLP implementations are falling short, it’s important to look at how data leakage actually occurs in modern environments. Within browser sessions, users can type, paste, and upload data to web pages and applications—both sanctioned and not.

Copy and Paste: Users routinely copy sensitive data—customer records, credentials, source code—from internal systems and paste it into personal email, SaaS apps, and AI tools. The clipboard has become a high-risk channel that most traditional DLP solutions cannot inspect or control with context

Form Inputs and AI Prompts: Sensitive data doesn’t always move as a file or pasted from clipboard contents. It’s often typed directly into web forms, SaaS applications, or even AI prompts.

Operating solely within the browser session, endpoint and network DLP controls never trigger.

A Paste event, as shown in Keep Aware’s Console, indicates that a user pasted code in a ChatGPT account tied to their organization.

File Uploads to SaaS and AI Tools: File uploads remain a major data loss vector, and one that appears like normal activity on the surface. Employees upload source code, financial data, and customer records. But as noted earlier, up to half of these uploads may be going to unsanctioned destinations, including personal accounts or unapproved tools.

Shadow Accounts and Instances: Even within approved domains and applications, risk and visibility gaps persist. A user may upload PHI records to an AI prompt using a personal account, store sensitive files to a personal Google Drive, or other SaaS tool, instead of a corporate one.

From a traditional DLP perspective, this activity often looks indistinguishable from normal usage on that domain.

An Upload event, as shown in Keep Aware’s Console, indicates that an employee uploaded a potentially sensitive document to their personal ChatGPT account.

Data loss in the browser often looks like normal user behavior, but in the wrong context.

A Real-World Example: Sensitive Data Exposure in the Browser

Consider a common workflow: a developer accesses the company’s private GitHub repository, copies a block of proprietary source code, then opens a personal ChatGPT session to troubleshoot an issue. When they paste that code into the AI prompt, sensitive data has effectively left the organization.

No file was downloaded nor uploaded. The company allows traffic to ChatGPT, so no network-based protection was triggered. No traditional DLP control flagged the paste action. This entire sequence of events appears as benign user and browser activity despite introducing real risk to the company’s sensitive data.

With browser-native DLP, this interaction becomes fully visible and enforceable. A browser-based DLP solution, such as , detects the sensitive data, understands it originated from a sanctioned app, and recognizes it’s being sent to an unsanctioned AI tool tied to a personal account.

A policy can then block the user’s action or warn the security team of the action, while capturing a full timeline of events—turning what would otherwise be invisible into a clear, actionable security signal.

Timeline of a developer copying and pasting proprietary code from a private repository into a personal ChatGPT account.

The Traditional DLP Gap in the Browser

Traditional DLP solutions were designed for a different risk model, one that focuses on preventing data leakage from endpoints, networks, and even cloud environments.

Endpoint DLP lacks visibility into the data being copied and pasted within the browser, the web application itself, and the type of user account used—all crucial contextual data points needed to effectively govern sensitive data.

Similarly, Network DLP lacks the same critical context—even when proxy solutions enable inspection of otherwise encrypted browser traffic—while remote and distributed workforces can add to the underlying visibility problem.

Cloud DLP is like a combination of endpoint and network DLP solutions, but provides visibility and control over a specific SaaS instance or cloud environment, one that is already sanctioned and governed by IT security.

Traditional DLP looks at files at rest and data on the move, but it wasn’t designed to inspect, let alone control, the user activities and session context within the most widely used application in today’s workforce.

Browser-Native DLP: Closing the Gap in Modern Data Protection

operates directly within users’ browsing sessions, uniquely positioned with the visibility that enables organizations to:

• Inspect data in real time (copy and paste activities, form and prompt inputs, file uploads)

  • Understand context (which application is in use, whether the account or instance is corporate or personal, what type of data is being handled)

  • Enforce inline controls (block or warn on risky actions, apply conditional policies based on context, allow safe workflows without disrupting productivity)

This approach doesn't replace your organization's existing DLP stack. It complements it, filling a glaring visibility gap that network-level and endpoint tools simply weren't built to address.

Keep Aware brings this capability directly into the browser itself. Rather than relying on file movement signals or network traffic, it operates at the point of user interaction, analyzing data in real time across typed inputs, copy/paste activities, and uploads, with the context of the application, instance, and account involved. Inline enforcement policies empower security teams to block sensitive actions, alert users before risky behavior, allow approved workflows with safeguards, reinforce Acceptable Use Policies at the moment of action, and provide forensic details through a robust evidence collection capability.

If you're evaluating where browser-native DLP fits in your security strategy, to see how Keep Aware works in a real enterprise environment.

Sponsored and written by .*

Most network incidents don’t escalate due to a lack of alerts—they escalate when response breaks down.

On Tuesday, June 02, 2026 at 12:00 PM ET, BleepingComputer will host a live webinar titled "**" with Edgar Ortiz, Solutions Engineering Leader at Tines.

The webinar explores why incident response fails in real-world environments and how organizations can close those gaps with intelligent workflows that combine automation and AI.

While security, monitoring, and infrastructure tools generate a constant stream of alerts, many teams still rely on manual triage and coordination under pressure. When alerts are not properly enriched, prioritized, and routed, response slows down and isolated issues can quickly escalate into broader service disruptions.

Tines provides an intelligence workflow platform that helps security and IT teams orchestrate incident response, enrich alerts with relevant context, and automate key actions across systems, enabling faster and more informed decision-making.

In this session, attendees will learn how to move from fragmented response processes to coordinated workflows that reduce response times and prevent escalation.

Where incident response breaks down

From initial alert to service impact, network incidents often follow predictable paths. However, breakdowns during triage, enrichment, and routing can delay response and increase the likelihood of escalation.

Without consistent workflows, teams are forced to manually gather context, prioritize alerts, and coordinate actions across systems, slowing down containment efforts when time matters most.

This webinar will explore how to eliminate these bottlenecks and improve how incidents are handled after detection.

The upcoming webinar will cover:

• How network incidents evolve from an initial alert to service impact

  • Where triage, enrichment, and routing break down in real-world workflows

  • How to automatically enrich alerts with network, identity, and threat context

  • Techniques to prioritize and route incidents without manual intervention

  • How to move from fragmented response to coordinated containment across systems

Don’t miss this opportunity to learn how to streamline incident response and reduce the risk of escalation.

➡ !

The MuddyWater Iranian hackers disguised their operations as a Chaos ransomware attack, relying on Microsoft Teams social engineering to gain access and establish persistence.

Although the attack involved credential theft, persistence, remote access, data exfiltration, extortion emails, and an entry on the Chaos leak portal, the attackers used infrastructure and techniques associated with the MuddyWater attacks.

Rapid7 researchers believe that the ransomware component was likely used to conceal the actual cyber-espionage operation and to complicate attribution.

“The strategy highlights the convergence between state-sponsored intrusion activity and criminal tradecraft, where a big “tell” lies in the techniques that were deployed - and those that weren’t. This strategy suggests the primary goal was not financial gain,” .

Despite the facade, Rapid7 has moderate confidence in attributing the incident to MuddyWater, a threat group also known as Static Kitten, Mango Sandstorm, and Seedworm.

The conclusion is based on infrastructure overlap, a specific code-signing certificate that the state-sponsored group used to sign Stagecomp and Darkcomp malware attributed to the threat actor, and various operational tradecraft.

MuddyWater is an Iranian state-sponsored cyber-espionage group, notorious for long-term that align with the country's Ministry of Intelligence and Security (MOIS).

The Chaos is a ransomware-as-a-service (RaaS) operation that and is known for big-game hunting attacks, double-extortion tactics, and social engineering campaigns mostly targeting .

Attack progression

The intrusion Rapid7 examined started through Microsoft Teams social engineering, where the attackers initiated chats with employees, established screen-sharing sessions, harvested credentials, manipulated multi-factor authentication (MFA) settings, and, in some cases, deployed AnyDesk for remote access.

Credential theft occurred either via phishing pages masquerading as Microsoft Quick Assist or by tricking victims into typing their passwords into local text files.

After compromising accounts, the attackers authenticated to internal systems, including a domain controller, and established persistence using RDP, DWAgent, and AnyDesk.

Next, they leveraged a malware loader (ms_upd.exe) to drop a custom backdoor (Game.exe), disguised as a Microsoft WebView2 application.

The malware features anti-analysis and anti-VM checks, and supports 12 commands, including PowerShell and CMD command execution, file upload and deletion, and persistent shell access.

Overview of the attack Source: Rapid7

Rapid7 notes that MuddyWater has used ransomware in the past to mask its cyber-espionage operations. In late 2025, the threat actor deployed Qilin ransomware in an attack against an Israeli organization.

The researchers suggest that the threat group might have pivoted to a different ransomware branding following the attribution of that late 2025 to MOIS operatives.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

The ShinyHunters extortion gang stole personal information belonging to over 119,000 people after hacking the Vimeo online video platform in April, according to data breach notification service Have I Been Pwned.

Vimeo is a video hosting and streaming platform publicly traded on the Nasdaq stock market, with over 300 million registered users and over 1,100 employees, and reported revenues of $417 million for FY2024.

The company that customer and user data had been accessed without authorization following a , a data anomaly detection company.

"Our initial findings suggest that the databases accessed primarily contain technical data, video titles and metadata, and, in some cases, customer email addresses," Vimeo said.

However, the company said the attack didn't cause any disruptions and that the threat actors didn't gain access to affected individuals' credentials or financial information. Vimeo also disabled all Anodot credentials after detecting the breach and removed the Anodot integration with its systems to cut off the attackers' access.

"The data accessed does not include Vimeo video content, valid user login credentials, or payment card information. Vimeo user and customer login credentials are secure. This incident did not cause any disruption to our systems or service," it added. "Upon learning of the incident, we promptly disabled all Anodot credentials, removed the Anodot integration with Vimeo systems, and engaged third-party security experts to assist with the investigation. We have also notified law enforcement."

After Vimeo's disclosure, the ShinyHunters cybercrime group leaked a 106GB archive of stolen documents on its dark web data leak site after failing to extort the company.

"Your Snowflake and Bigquery instances data was compromised thanks to Anodot.com," the extortion gang said. "The company failed to reach an agreement with us despite our incredible patience, all the chances and offers we made."

Vimeo entry on ShinyHunters leak site (BleepingComputer)

​While Vimeo has yet to disclose the total number of individuals whose information was stolen in the incident, data breach notification service Have I Been Pwned analyzed the stolen data and reported that the breach exposed the email addresses and (in some cases) names of 119,200 people.

Previously, the cybercrime group told BleepingComputer that it had stolen data from dozens of companies using Anodot authentication tokens. ShinyHunters also confirmed they attempted to steal data from Salesforce instances, but said they were blocked by AI-based detection.

ShinyHunters has also been linked to a that targets employees' and Business Process Outsourcing (BPO) agents' Microsoft Entra, Okta, and Google SSO accounts.

After breaching corporate SSO accounts, they steal data from connected SaaS applications, including Salesforce, SAP, Slack, Adobe, Atlassian, Zendesk, Dropbox, Microsoft 365, Google Workspace, and others.

Other breaches claimed by ShinyHunters in recent weeks include the , , , and, more recently, medical device maker , cruise line operator Carnival, fast fashion retailer Zara, convenience store chain 7-Eleven, and online training company Udemy.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

Written by Isaac Wuest, Principal Product Manager at HeroDevs.

When security teams think about end-of-life (EOL) open source software, the conversation usually starts and ends in the same place: no more patches.

That's true, but it's only half the story, and arguably the less dangerous half. There are two compounding problems most teams are unaware of.

Problem One: The CVE Ecosystem Doesn't Investigate What It Doesn't Support

When a vulnerability is discovered in an open source project, maintainers determine which versions are affected and file a CVE with a defined affected range. Every vulnerability scanner, SBOM tool, and CVE feed in the industry consumes that range.

If your version falls outside it, you get no alert. Not because you're safe, but because no one checked.

EOL versions fall outside that range almost by default. The reason is straightforward: it's a scale problem. In just five years, the global CVE count doubled while the number of unscored CVEs increased 37x, according to .

Maintainers are already overwhelmed investigating and patching the versions they actively support, and as both CVE volume and the total number of package releases continue to grow, the investigative bandwidth required to cover older release lines simply doesn't exist.

Maintainers must be realistic about how far back in their own release history they can reasonably go.

Sonatype's research explicitly named "EOL versions omitted from advisories" as a driver of false security confidence, contributing to the 167,286 false negatives, exploitable components that went entirely unflagged, they identified in 2025 alone.

HeroDevs' EOL DS tracks end-of-life status across 12M+ package versions on npm, PyPI, Maven, NuGet, and every other major registry.

Upload an SBOM or run the CLI to find every EOL dependency in your stack, including the transitive ones your scanners can't flag.

What This Looks Like in Practice

Two recent critical vulnerabilities in the Spring ecosystem make this concrete.

CVE-2026-22732 — Spring Security (Critical, March 2026, CVSS 9.1)

This vulnerability causes security response headers, including Cache-Control, X-Frame-Options, Strict-Transport-Security, and Content-Security-Policy, to be silently dropped in certain servlet application configurations. The official affected range covers Spring Security 5.7.x through 7.0.x.

Spring Security 6.2.x is not listed. It reached EOL in December 2025. Spring Boot 3.2 ships with Spring Security 6.2. Any organization running Boot 3.2, one minor version behind the listed range, receives no scanner signal.

HeroDevs has confirmed Spring Security 6.2.x is affected and has backported a fix for NES customers. The upstream CVE record does not reflect this.

How Often Does This Happen?

The Spring examples above are not outliers. They reflect a pattern HeroDevs encounters consistently across its Never-Ending-Support practice.

When a new CVE is disclosed on a supported package, HeroDevs finds it needs to patch an EOL version the official CVE record does not list as affected approximately 80% of the time. The blast radius of any given vulnerability is systematically wider than what the record shows.

Put plainly: for four out of every five CVEs disclosed on a supported version, there is a reasonable probability that an EOL version you are running is also affected, and no scanner in the world will tell you that.

Problem Two: The Industry Is Counting the Wrong EOL Software

The CVE investigation gap above applies to EOL software that the community actually knows is EOL. That turns out to be a very small fraction of the real problem.

The most widely cited source of EOL data is , which tracks roughly 350 actively maintained projects; major frameworks and runtimes where maintainers have explicitly published end-of-life dates.

Across those 350 projects, approximately 7,000 specific package versions are identified as EOL. That is the universe most scanners and security teams are working from.

Here is the actual scale of the problem.

In , produced in partnership with HeroDevs, the data tells a different story. Analyzing lifecycle status across 12 million package versions spanning npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist, and crates.io, HeroDevs found that 5.4 million of those versions are end-of-life.

However, the industry's most complete public source (endoflife.date) only accounts for ~7,000 of them.

The breakdown by ecosystem is striking. Approximately 25% of npm package versions are EOL. NuGet sits at around 18%, Cargo at 13%, PyPI at 11%, and Maven Central at 10%. These are versions actively appearing in enterprise SBOMs today, with no CVE investigation coverage and no fix path.

The Sonatype report found that 5–15% of components in enterprise dependency graphs are EOL, indicating EOL exposure even when teams believe they are only using supported top-level libraries. Transitive dependencies, the packages your packages depend on, carry the majority of this hidden exposure.

Most organizations are profoundly underreporting their EOL exposure, and it is not their fault. Their tooling was never built to detect abandonment at scale.

HeroDevs has confirmed more than 81,000 EOL package versions with known CVEs and no available fix path, meaning these are CVEs that were actively investigated and confirmed.

Given that roughly 80% of CVEs on supported versions also affect EOL versions that were never officially investigated, the true number is likely far larger. HeroDevs estimates the actual figure may be closer to >400,000 across all registries.

Why This Is Getting Worse

This dynamic is not new. What is new is the rate at which it is compounding.

The OSS ecosystem is scaling faster than the security infrastructure built to monitor it. npm alone recorded over 838,000 releases associated with critical CVSS 9.0+ scores in 2025. PyPI download volume grew over 50% year over year.

Every new package version that enters a registry is a future EOL version, and the EOL population grows continuously, while the investigative capacity to cover it does not.

The more significant forcing function, however, may be AI.

In April 2026, Anthropic announced Project Glasswing alongside Claude Mythos Preview, documenting its ability to identify and exploit zero-day vulnerabilities across all major operating systems and browsers — including vulnerabilities undetected for decades.

The initiative is explicitly defensive, directed toward finding and fixing critical vulnerabilities before attackers can exploit them.

For software with active support, this is genuinely good news. Vulnerabilities found at AI scale can be routed to engineers who can address them.

For EOL software, the calculus is different. An AI that finds vulnerabilities across the entire codebase landscape will surface findings in versions no maintainer is watching. Those findings will not be officially investigated against the EOL-affected ranges.

They will not trigger scanner alerts for EOL users. No upstream patch will ever address them. The same capability that accelerates defense for supported software widens the exposure gap for everything already left behind.

The early signals of this shift are already visible. The full impact hasn't arrived yet.

What To Do

Start with visibility. HeroDevs offers a free .

Upload dependency files or use the CLI to identify EOL exposure across your stack in minutes, covering both announced and abandoned packages across all major registries.

Don't treat scanner silence as safety. A clean scan against an EOL package means the package wasn't checked, not that it isn't vulnerable.

The Spring CVEs above are current proof — in both cases, EOL users were exposed without warning until HeroDevs investigated and reported.

EOL dates are not finish lines. They are the moment risk silently transfers from maintainer to operator. As AI-assisted vulnerability research scales, the number of undisclosed vulnerabilities in uninvestigated EOL packages will only grow.

Get started today with .

Sponsored and written by .*

Cyberattacks are evolving faster than most managed service providers (MSPs) can keep up with, with phishing now acting as the primary entry point for many compromises.

As attackers increasingly use AI to generate highly personalized phishing campaigns, traditional defenses are struggling to detect and block these threats before access is gained.

However, the bigger challenge often comes after the initial breach, when organizations are left dealing with data loss, downtime, and recovery.

On Thursday, May 14, 2026, at 2:00 PM Eastern Daylight Time, experts from exploring how modern attacks unfold and why MSPs must rethink both security and recovery strategies.

Security alone isn’t enough without recovery

While preventing attacks remains critical, the reality is that not every threat can be stopped in time. Many MSPs still treat security and backup as separate functions, creating gaps that attackers can exploit after initial access.

This session will examine how attacks progress from AI-driven phishing and business email compromise to ransomware and data-loss events, and how threat actors increasingly leverage trusted infrastructure and SaaS platforms to bypass defenses.

The webinar will also highlight why SaaS backups and a business continuity and disaster recovery (BCDR) strategy are essential components of cyber resilience, ensuring organizations can recover quickly and minimize impact when incidents occur.

During the session, attendees will learn:

- Why AI-driven phishing and brand impersonation are outpacing traditional email security

- How attackers leverage trusted infrastructure and SaaS platforms to bypass defenses

- Where most MSP security strategies fail after initial compromise

- Why SaaS backups and a BCDR plan are critical layers of cyber resilience

- How leading MSPs combine prevention, detection, and rapid recovery to protect clients and maintain uptime

Join this webinar to learn how to strengthen both your security posture and recovery capabilities, helping ensure that even if an attack succeeds, the outcome remains under your control.

➡

Progress Software warned customers to patch a critical authentication bypass vulnerability in its MOVEit Automation enterprise-grade managed file transfer (MFT) application.

MOVEit Automation automates complex data workflows without requiring manual scripting and serves as a central automation orchestrator to schedule and manage file transfers between different systems, including local servers, cloud storage, and external partners.

Tracked as , the security flaw affects MOVEit Automation versions before 2025.1.5, 2025.0.9, and 2024.1.8. Remote threat actors can exploit it without privileges on the targeted systems in low-complexity attacks that don't require user interaction.

"We have addressed the vulnerability and the Progress MOVEit Automation team strongly recommends performing an upgrade to the latest version," the company . "Upgrading to a patched release, using the full installer, is the only way to remediate this issue. There will be an outage to the system while the upgrade is running."

The same day, Progress also released security updates to address a high-severity privilege escalation vulnerability () stemming from an improper input validation weakness in the same software.

According to a Shodan search shared by , over 1,400 MOVEit Automation instances , and over a dozen are .

However, there is no information regarding how many of these systems have already been secured against CVE-2026-4670 attacks.

Map of MOVEit Automation instances exposed online (Shodan)

While the company has yet to flag these security issues as exploited in the wild, other MoveIT MFT vulnerabilities have been targeted in attacks in recent years.

For instance, the Clop ransomware gang exploited a zero-day in the MOVEit Transfer secure file transfer platform in an in 2023 that affected more than 2,100 organizations and over 62 million individuals, according to .

MFT software is an attractive target for ransomware actors, as seen in previous Clop data-theft campaigns targeting security flaws in , , , , and .

Progress Software says its MOVEit MFT solutions are used by more than 3,000 enterprise organizations and over 100,000 users worldwide.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

Instructure, the company behind the widely used Canvas learning platform, has disclosed that it recently suffered a cybersecurity incident and is now investigating its impact.

The U.S.-based education technology company is best known for developing Canvas, a widely used learning management system that helps schools, universities, and organizations manage coursework, assignments, and online learning.

"Instructure recently experienced a cybersecurity incident perpetrated by a criminal threat actor. We are actively investigating this incident with the help of outside forensics experts," reads a statement from Steve Proud, Chief Security Officer.

"We are working quickly to understand the extent of the incident and actively taking steps to minimize its impact. Maintaining your trust is our highest priority, and we are committed to transparency throughout this process."

Instructure says that it will provide new information regarding its investigation as it becomes available.

Since May 1, some services, including Canvas Data 2 and Canvas Beta, have been under maintenance, with customers warned they may experience issues with tools that rely on API keys.

The company has not stated whether this maintenance is related to the security incident.

BleepingComputer contacted Instructure earlier today with questions about the incident, but has not received a response.

BleepingComputer previously published and retracted an earlier report about this incident after determining it was based on incorrect information from a prior disclosure.

Targeting education technology firms

Threat actors have increasingly targeted education technology firms due to the large amounts of personal information they hold on students and teachers.

In January 2025, educational software provider in which a threat actor claimed to have .

In September 2025, resulting from a social engineering attack that allowed attackers to access data in its Salesforce instance. At the time, a threat actor known as ShinyHunters claimed responsibility for the incident and .

Threat actors have also targeted , with claims of data theft from the company’s Salesforce environment.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

Microsoft has confirmed that Windows 11 is getting a new modern Run dialog with dark mode support and faster performance in a new preview build 26300.8346.

The Run dialog has been around since the Windows 95 era, and it is one of those small Windows features that many power users still rely on every day.

You just need to press Win + R, type a command, open a file path, launch a tool, or quickly jump to a location without opening File Explorer first.

With the new version, Microsoft is trying to modernize Run without changing what makes it useful.

Unlike the legacy Run, modern Run matches Fluent Design, supports dark mode out of the box, and is actually faster than the legacy Run.

That is interesting because modern counterparts usually have a reputation for slower performance.

Source: BleepingComputer

Microsoft noted that designing a modern Run dialog for Windows 11 was challenging, as the company had to maintain the same performance and retain the minimal user interface, similar to the original Run that shipped with Windows 95.

"When we set out on creating the new experience, we knew the existing dialog was fast. We also knew we needed to be sure we deeply understood how you all used it. Modernize, be opinionated, and evolve it," Microsoft in a blog post.

"To help evolve, we added a measure briefly to the dialog to see what was being used and to measure time-to-show. This confirmed a few key things that helped the design process."

Microsoft says performance was one of the most important factors when designing the modern Run dialog. That's because quite a lot of people use the existing Run dialog to paste text from the clipboard, then copy it again to remove text formatting.

This experience mostly works because of how fast the existing Run is. The legacy Run dialog takes approximately 103ms to appear after you press the Win + R keyboard shortcut.

Interestingly, the modern Run is actually faster. It has a median time-to-show of just 94ms.

"This was a huge team effort - we’ve collaborated tightly with partners across the platform to get these UI surfaces loading snappy. Improvements we’ve made to the platform don’t just make Run fast, but they help make the whole OS more efficient," the company said.

Microsoft says it expects these numbers to improve as well as there is still room for improvement,

Microsoft drops 'Browse' feature in new Run

Microsoft looked at how people use the existing Run dialog before deciding what should stay and what could be removed. One example is the Browse button, which lets you browse a specific directory to open a program.

According to Microsoft, the Browse button usage is less than 0.0038%. This number is based on a sample of 35 million users who open Windows Run.

As a result, Microsoft has dropped the Browse button from the modern Run. The company argues that it researched how Run was being used and how fast it was, which helped form a baseline to build the modern Run.

Modern Run also supports ~\, which allows you to quickly access your home directory. It also shows icons in the list, which should make entries easier to identify without making the dialog feel too heavy.

How to enable or disable modern Run

While modern Run looks great and works well in our test, some of you may not like the idea, which is why the feature is entirely optional and tied to Advanced Settings in Windows.

According to Microsoft, modern Run does not get turned on automatically. Instead, you need to open Settings > Advanced Settings and manually enable modern Run, which replaces the legacy Run.

Enable or disable modern Run dialog Source: BleepingComputer

There are also plans to add more features to modern Run, and Microsoft says it is collecting feedback before rolling it out more broadly.

Other changes rolling out with today's preview update

In addition to the Run dialog upgrade, Microsoft is improving Windows Share UI for AAD users.

Until now, if you wanted to add an app to the share dialog, you had to open the MS Store, install the app first, and then find it in the Share list. Now, you can install apps directly from the Share UI.

Last but not least, Magnifier now gives you more control over how you zoom, including preset zoom levels of 5%, 10%, 25%, 50%, 100%, 150%, 200%, and 400%.

These changes will roll out to everyone in the coming months, but for now, you'll need to download Windows 11 Build 26300.8346 from .

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

Microsoft has updated a Windows 11 in-box app removal policy introduced in October to include a dynamic list that lets IT admins choose which preinstalled Store apps to uninstall.

The updated policy enables admins to remove any preinstalled MSIX/APPX app by referencing its Package Family Name (PFN) using Group Policy Object (GPO) or a custom OMA-URI for mobile device management (MDM).

"IT admins, you can now simplify Microsoft Store app management with dynamic removal on more devices across your enterprise. Use policy to remove any preinstalled MSIX/APPX app by referencing its Package Family Name (PFN)," on Thursday.

To get this new feature, admins must ensure that their devices have at least the April 2026 Windows non-security update deployed. Windows Insiders can get it after installing the March 13, 2026, builds in the and channels.

To make it work using Group Policy, admins have to:

Microsoft has also extended support for the RemoveDefaultMicrosoftStorePackages policy to systems running Enterprise and Education editions of Windows 11 24H2. Microsoft , but it was only made available on devices running Windows 11 25H2 or later.

"The updated app removal policy is now extended to Windows 11, version 24H2 Enterprise and Education editions. Originally, you could only use this feature on devices running Windows 11, version 25H2 or newer," . "If your organization has standardized on the 2024 release, you can benefit from policy-driven app management without a full OS version upgrade."

The complete list of supported apps and detailed guidance on applying the policy to a single device via the Local Group Policy Editor or to multiple Active Directory-joined devices .

While the Intune entry for this policy does not include the dynamic list option, Microsoft has said it will become available in the coming months.

"When this feature becomes generally available in Intune, search for 'Remove Default Microsoft Store packages' in the settings picker to locate it," it noted.

Earlier this month, Microsoft also announced that IT admins from enterprise devices using the new policy setting after installing the April 2026 Patch Tuesday cumulative updates.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.

Microsoft has fixed a known issue causing newly introduced Windows security warnings to display incorrectly when opening Remote Desktop (.rdp) files.

This known issue affects all supported Windows versions, including Windows 11 ( & ), Windows 10 (), and Windows Server (), on devices with multiple monitors and different display scaling settings.

Microsoft addressed the bug in the optional preview cumulative update for Windows 11, , along with 34 other changes.

"This update addresses an issue that affects the Remote Desktop Connection security warning dialog. The dialog could render incorrectly in multi-monitor scenario when the monitors had different scaling set," . "This might occur after installing the April 2026 (KB5083769) security update."

As Microsoft explained on Wednesday, the security warnings appearing when opening RDP files may not display correctly. On affected Windows systems, the buttons in the alert windows are misaligned or partially hidden, and the text is hard to read, making it difficult, and in some cases impossible, to interact with the security dialog.

These warnings were introduced on Windows systems with the to disable risky shared resources by default as a defense against phishing attacks that abuse Remote Desktop connection (.rdp) files.

Remote Desktop Connection security warning (Microsoft)

​RDP files are commonly used to connect to remote systems in enterprise environments because they can be preconfigured to automatically redirect local resources to a remote host. However, threat actors have also increasingly abused them in phishing campaigns, including the Russian APT29 cyber-espionage group, which has to steal documents and credentials from victims' devices remotely.

After installing the April security updates, a one-time educational prompt will appear when opening an RDP file for the first time, warning about the associated risks.

Afterward, a security dialog is displayed before any connection is made when opening RDP files, showing whether the file is signed by a verified publisher, the remote system's address, and all local resource redirections (including drives, clipboard, or devices), with every option disabled by default.

If RDP files are not digitally signed, Windows displays a "Caution: Unknown remote connection" warning, with the publisher labeled as unknown. However, if they are digitally signed, Windows will warn users to verify their legitimacy before connecting.

According to user reports, the KB5083769 security update from multiple vendors on Windows 11 24H2 / 25H2 systems due to a VSS (Volume Shadow Copy Service) timeout.

Last month, Microsoft also to fix multiple Windows Server issues that caused and after installing the April 2026 security updates.

AI chained four zero-days into one exploit that bypassed both renderer and OS sandboxes. A wave of new exploits is coming.

At the Autonomous Validation Summit (May 12 & 14), see how autonomous, context-rich validation finds what's exploitable, proves controls hold, and closes the remediation loop.