Lately, hackers have been turning up the heat on software developers. On the surface, this might seem like a puzzling move — why go after someone who’s literally paid to understand tech when there are plenty of less-savvy targets in the office? As it turns out, compromising a developer’s machine offers a much bigger payoff for an attacker.
Why developers are such high-value targets
For starters, compromising a coder’s workstation can give attackers a direct line to source code, credentials, authentication tokens, or even the entire development infrastructure. If the company builds software for others, a hijacked dev environment allows attackers to launch a massive supply chain attack, using the company’s products to infect its customer base. If the developer works on internal services, their machine becomes a perfect beachhead for lateral movement, allowing hackers to spread deeper into the corporate network.
Even when attackers are purely chasing cryptocurrency (and let’s face it, tech pros are much more likely to hold crypto than the average person), the malware used in these hits doesn’t just swap out wallet addresses; it vacuums up every scrap of valuable data it can find — especially those login credentials and session tokens. Even if the original attackers don’t care about corporate access, they can easily flip those credentials to initial access brokers or more specialized threat actors on the dark web.
Why developers are sitting ducks
In practice, developers aren’t nearly as good at understanding cyberthreats and spotting social engineering as they think they are. This misconception is a big reason why they often fall prey to cybercriminals. Professional expertise can often create a false sense of digital invincibility. This often leads technical professionals to cut corners on security protocols, bypass restrictions set by the security team, or even disable security software on their corporate machines when it gets in the way of their workflow. That mindset, combined with a job that requires them to constantly download and run third-party code, makes them sitting ducks for cyberattackers.
Attack vectors targeting developers
Once an attacker sets their sights on a software engineer, their go-to move is usually finding a way to slip malicious code onto the machine. But that’s just the tip of the iceberg — hackers are also masters at rebranding classic, battle-tested tactics.
Compromising open-source packages
One of the most common ways to hit a developer is by poisoning open-source software. We’ve seen a flood of these attacks over the past year. A prime example hit in March 2026, when attackers managed to inject malicious code into LiteLLM, a popular Python library hosted in the PyPI repository. Because this library acts as a versatile gateway for connecting various AI agents, it’s baked into a massive number of projects. These trojanized versions of LiteLLM delivered scripts designed to hunt for credentials across the victim’s system. Once stolen, that data serves as a skeleton key for attackers to infiltrate any company that was unlucky enough to download the infected packages.
Malware hidden in technical assignments
Every so often, attackers post enticing job openings for developers, complete with take-home test assignments that are laced with malicious code. For instance, in late February 2026, malicious actors pushed out web application projects built on Next.js via several malicious repositories, framing them as coding tests. Once a developer cloned the repo and fired up the project locally, a script would trigger automatically to download and install a backdoor. The attackers gained full remote access to the developer’s machine.
Fake development tools
Recently, our experts described an attack where hackers used paid search-engine ads to push malware disguised as popular AI tools. One of the primary baits was Claude Code, an AI coding assistant. This campaign specifically targeted developers looking for a way to use AI-assistants under the radar, without getting the green light from their company’s infosec team. The ads directed users to a malicious site that perfectly mimicked the official Claude Code documentation. It even included “installation instructions”, which prompted the user to copy and run a command. In reality, running that command installed an infostealer that harvested credentials and shuttled them off to a remote server.
Social engineering tactics
That said, attackers often stick to the basics when trying to plant malware. A recent investigation into a compromised npm package — Axios — revealed that hackers had gained access to a maintainer’s system using a shockingly simple “outdated software” ruse. The attackers reached out to the Axios repository maintainer while posing as the founder of a well-known company. After some back-and-forth, they invited him to a video interview. When the developer tried to join the meeting on what looked like Microsoft Teams, he hit a fake notification claiming his software was out of date and needed an immediate update. That “update” was actually a Remote Access Trojan, giving the attackers access to his machine.
Niche spam
Sometimes, even a blast of fake notifications does the trick, especially when it’s tailored to the audience. For example, just recently, attackers were caught posting fake alerts in the Discussions tabs of various GitHub projects, claiming there was a critical vulnerability in Visual Studio Code that required an immediate update. Because developers subscribed to those discussions received these alerts directly via email, the notifications looked like legitimate security warnings. Of course, the link in the message didn’t lead to an official patch; it pointed to a “fixed” version of VS Code that was actually laced with malware.
How to safeguard an organization
To minimize the risk of a breach, companies should lean into the following best practices:
Make security a native part of your workflow. Use specialized solutions to vet your images, packages, dependencies, and components.
National Vulnerability Database (NVD) Shifts to Selective Enrichment as CVE Volume Surges
In this post, we examine what NVD’s shift to selective enrichment means for vulnerability workflows and how security teams can maintain visibility and prioritization at scale.
The National Vulnerability Database (NVD) is changing how it processes and enriches vulnerability data in response to sustained growth in CVE submissions.
Under a new model announced by the National Institute of Standards and Technology, NVD will no longer enrich every CVE. Instead, enrichment efforts will focus on a defined subset, including vulnerabilities in the CISA KEV catalog, software used by the federal government, and software designated as critical.
All other CVEs will remain in the database without additional context unless specifically requested.
Rising disclosure volumes are placing pressure on public vulnerability infrastructure, and it has direct implications for how security teams consume and act on vulnerability data.
What Changed in NVD’s Operating Model
For years, NVD aimed to provide consistent enrichment across all CVEs, including severity scoring, affected product data, and supporting context for prioritization.
That approach has not been sustainable since late 2023.
In 2025, Flashpoint tracked 44,509 disclosed vulnerabilities, 14,593 of which had publicly available exploits (and 1,944 more with proof-of-concepts).
CVE submissions increased by 263% between 2020 and 2025, with 2026 already tracking higher year-over-year. Even with increased throughput, NVD has not been able to keep pace.
Under the updated model:
CVEs meeting prioritization criteria will be enriched on an accelerated timeline
CVEs outside those criteria will be labeled and left without enrichment
Re-analysis of modified CVEs will occur selectively
Separate NVD severity scoring will no longer be applied by default
This introduces a significant structural change in how vulnerability data is published and maintained.
The Impact on Vulnerability Workflows
Many security programs rely on NVD enrichment to operationalize CVE data. That enrichment provides the context needed to evaluate risk and determine remediation priorities.
With enrichment applied selectively, teams will encounter a growing number of CVEs that include:
Limited or no severity scoring
Incomplete product and version data
Minimal context on exploitability or impact
No CPE strings that allow for programmatic consumption of data
At the same time, disclosure volume continues to rise, and exploitation timelines remain compressed. This creates a gap between what is disclosed and what can be acted on efficiently.
Security teams will need to account for:
Larger backlogs of CVEs without actionable context
Increased manual effort to evaluate relevance and risk
Greater variability in data quality across sources
These changes affect vulnerability management, threat intelligence, and security operations workflows simultaneously.
Prioritization Criteria Will Not Capture the Full Risk Landscape
NVD’s updated model focuses enrichment on a defined set of criteria, including known exploited vulnerabilities and software relevant to federal systems.
These categories represent important segments of risk, but they do not encompass the full set of vulnerabilities that organizations encounter in practice.
Modern environments include:
Open-source dependencies
SaaS platforms and APIs
Cloud infrastructure and services
Third-party and partner integrations
Many vulnerabilities affecting these environments fall outside formal prioritization frameworks or lack immediate classification within public datasets. As a result, security teams will continue to face exposure from vulnerabilities that are:
Actively exploited but not yet included in prioritized lists
Missing complete metadata or enrichment
Relevant to their environment but not captured by federal-centric criteria
Vulnerability Intelligence Requires Broader Coverage and Deeper Context
As public enrichment becomes more selective, organizations will rely more heavily on alternative sources to maintain visibility and context.
Continuous tracking of exploitation activity and adversary usage
Context on exploit maturity, and remediation
Consistent enrichment that can be integrated into operational workflows
This level of detail supports faster and more accurate decision-making in environments where both volume and speed are increasing.
Flashpoint’s vulnerability intelligence model is built to address these requirements, with a dataset that includes over 7,000 known exploited vulnerabilities and ongoing analyst-driven enrichment across global sources.
What Security Teams Should Do Next
This shift in NVD operations does not change the need to track CVEs. It changes how that data can be used. Security teams should evaluate how their current workflows depend on:
NVD enrichment for prioritization
CVSS scoring as a primary decision input
Completeness of public vulnerability data
From there, teams can take steps to strengthen resilience:
Incorporate sources of vulnerability intelligence that cover CVE and more
Align prioritization to exploitation activity and environmental relevance
Validate coverage across software, cloud, and third-party dependencies
Ensure that enrichment gaps do not delay remediation decisions
A Structural Shift in Vulnerability Data
For many teams, NVD has been a default source of vulnerability context. This change makes clear that its role is narrowing at a time when disclosure volume and prioritization demands are increasing.
At the same time, the role of vulnerability intelligence is expanding.
Security teams need access to data that supports prioritization, not just identification. They need consistent enrichment, faster turnaround, broader coverage, and context tied to real-world activity. As disclosure volumes continue to grow, those requirements become more central to how organizations manage risk.
Flashpoint’s Vulnerability Intelligence provides this level of coverage and context, with analyst-driven enrichment, global visibility across CVE and non-CVE vulnerabilities, and a dataset that includes over 7,000 known exploited vulnerabilities.
Request a demo to see how Flashpoint helps security teams prioritize and act on vulnerability risk with greater precision and confidence.
DarkSword and Coruna are two new tools for invisible attacks on iOS devices. These attacks require no user interaction and are already being actively used by bad actors in the wild. Before these threats emerged, most iPhone users didn’t have to lose sleep over their data security. Protection was really only a major concern for a narrow group — politicians, activists, diplomats, high-level business execs, and others who handle extremely sensitive data — who might be targeted by foreign intelligence agencies. We’ve covered sophisticated spyware used against such a group before — noting how hard to come by those tools were.
However, DarkSword and Coruna — discovered by researchers earlier this year — are total game-changers. This malware is being used for mass infections of everyday users. In this post, we dive into why this shift happened, why these tools are so dangerous, and how you can stay protected.
What we know about DarkSword, and how it can target your iPhone
In mid-March 2026, three separate research teams coordinated the release of their findings on a new spyware strain called DarkSword. This tool is capable of silently hacking devices running iOS 18 without the user ever knowing something is wrong.
First, we should clear up some confusion: iOS 18 isn’t as vintage as it might sound. Even though the latest version is iOS 26, Apple recently overhauled its versioning system, which threw everyone for a loop. They decided to jump ahead eight versions — from 18 straight to 26 — so the OS number matches the current year. Despite the jump, Apple estimates that about a quarter of all active devices still run iOS 18 or older.
With that cleared up, let’s get back to DarkSword. Research shows that this malware infects victims when they visit perfectly legitimate websites that have been injected with malicious code. The spyware installs itself without any user interaction at all: you just have to land on a compromised page. This is what’s known as a zero-click infection technique. Researchers report that several thousand devices have already been hit this way.
To compromise a device, DarkSword uses a six-vulnerability exploit chain to escape the sandbox, escalate privileges, and execute code. Once it’s in, the malware harvests data from the infected device, including:
Passwords
Photos
Chats and data from iMessage, WhatsApp, and Telegram
Browser history
Information from Apple’s Calendar, Notes, and Health apps
On top of all that, DarkSword lets attackers scoop up crypto-wallet data, making it essentially dual-purpose malware that functions as both a spy tool and a way to drain your crypto.
The only bit of good news is that the spyware doesn’t survive a reboot. DarkSword is fileless malware, meaning it lives in the device’s RAM, and never actually embeds itself into the file system.
Coruna: how older iOS versions are being targeted
Just two weeks before the DarkSword findings went public, researchers flagged another iOS threat dubbed Coruna. This malware is capable of compromising devices running older software — specifically iOS 13 through 17.2.1. Coruna uses the exact same playbook as DarkSword: victims visit a legitimate site injected with malicious code which then drops the malware onto the device. The whole process is completely invisible and requires zero user interaction.
A deep dive into Coruna’s code revealed it exploits a total of 23 different iOS vulnerabilities, several of which are tucked away in Apple’s WebKit. It’s worth reminding that, generally speaking (outside the EU), all iOS browsers are required to use the WebKit engine. This means these vulnerabilities don’t just affect Safari users — they’re a threat to anyone using a third-party browser on their iPhone as well.
The latest version of Coruna, much like DarkSword, includes modifications designed to drain crypto wallets. It also harvests photos and, in certain instances, email data. From what we can tell, stealing cryptocurrency seems to be the primary motive behind Coruna’s widespread deployment.
Who created Coruna and DarkSword — and how did they end up in the wild?
Code analysis of both tools suggests that Coruna and DarkSword were likely built by different developers. However, in both cases, we’re looking at software originally created by state-affiliated companies, possibly from the U.S. The high quality of the code points to this; these aren’t just Frankenstein kits cobbled together from random parts, but uniformly engineered exploits. Somewhere along the line, these tools leaked into the hands of cybercrime gangs.
One theory suggests an employee at the company that developed Coruna sold it to hackers. Since then, the malware has been used to drain crypto wallets belonging to users in China; experts estimate that at least 42 000 devices were infected there alone.
As for DarkSword, cybercriminals have already used it to compromise users in Saudi Arabia, Turkey, and Malaysia. The problem is exacerbated by the fact that the attackers who first deployed DarkSword left the full source code on infected websites, meaning it could easily be picked up by other criminal groups.
The code also includes detailed comments in English explaining exactly what each component does, which supports the theory of its Western origins. These step-by-step instructions make it easy for other hackers to adapt the tool for their own purposes.
How to protect yourself from Coruna and DarkSword
Serious malware that allows for the mass infection of iPhones while requiring zero interaction from the user has now landed in the hands of an essentially unlimited pool of cybercriminals. To pick up Coruna or DarkSword, you simply have to visit the wrong site at the wrong time. So this is one of those cases where every user needs to take iOS security seriously — not just those in high-risk groups.
The best thing you can do to protect yourself from Coruna and DarkSword is to update your devices to the latest version of iOS or iPadOS 26, as soon as you can. If you can’t update to the newest software — for instance, if your device is older and doesn’t support iOS 26 — you should still install the latest version available to you. Specifically, look for versions 15.8.7, 16.7.15, or 18.7.7. In a rare move, Apple patched a wide range of older operating systems.
To protect your Apple devices from similar malware that will likely pop up in the future, we recommend the following:
Install updates promptly on all your Apple devices. The company regularly releases OS versions that patch known vulnerabilities — don’t skip them.
Enable Background Security Improvements. This feature allows your device to receive critical security fixes separately from full iOS updates, reducing the window for hackers to exploit vulnerabilities. To enable it, go to Settings → Privacy & Security → Background Security Improvements and turn on the Automatically Install
Consider using Lockdown Mode. This is a heightened security setting that limits some device features but simultaneously blocks or significantly complicates attacks. To enable this, go to Settings → Privacy & Security → Lockdown Mode → Turn On Lockdown Mode.
Reboot your device once a day (or more). This stops fileless malware in its tracks, since these threats aren’t embedded in the system and disappear after a restart.
Use encrypted storage for sensitive data. Keep things like crypto wallet keys, photos of IDs, and confidential info in a secure vault. Kaspersky Password Manager is a great fit for this; it manages your passwords, two-factor authentication tokens, and passkeys across all your devices while also keeping your notes, photos, and docs synced and encrypted.
The idea that Apple devices are bulletproof is a myth. They’re vulnerable to zero-click attacks, Trojans, and ClickFix infection techniques — and we’ve even seen malicious apps slip into the App Store more than once. Read more here:
Flashpoint Surpasses Cataloging 7,000 Known Exploited Vulnerabilities as Disclosure Volume Accelerates
In this post we explore Flashpoint’s latest milestone of surpassing cataloging 7,000 known exploited vulnerabilities and what this means for security teams.
Flashpoint Vulnerability Intelligence has surpassed cataloging 7,000 known exploited vulnerabilities, surpassing another major milestone as vulnerability disclosures accelerate across the global attack surface.
In 2025, Flashpoint tracked 44,509 disclosed vulnerabilities, a pace that continues to accelerate into 2026. Of those, 14,593 had publicly available exploits (1,944 more with proof-of-concepts), giving threat actors immediate pathways to weaponization.
This pace is shaping how exploitation unfolds, with high-impact vulnerabilities being operationalized within hours or days, particularly when they affect widely deployed technologies or core infrastructure.
Security teams are operating within this compressed environment every day. They are reviewing more findings across open-source software, commercial applications, cloud environments, and third-party dependencies, while working within tighter timelines to assess impact and take action.
Flashpoint’s latest milestone of surpassing 7,000 known exploited vulnerabilities (KEVs) cataloged reflects that reality. It highlights how vulnerability management programs are evolving toward prioritization as a core capability, with a focus on vulnerabilities tied to active exploitation and real-world risk.
What The 7,000+ KEV Milestone Means for You
Security teams are operating in a high-volume environment. Vulnerabilities are disclosed continuously across open-source software, commercial applications, cloud environments, and third-party dependencies. At the same time, advancements in automation and code analysis are increasing the rate at which new findings are surfaced.
Each of these findings enters an already crowded workflow. Teams are expected to determine relevance, urgency, and impact quickly, often with limited context. This is where risk-based decision making becomes essential.
Flashpoint tracks hundreds of thousands of vulnerabilities across thousands of sources. Within that dataset, a much smaller percentage shows confirmed exploitation activity. That concentration of risk informs how effective programs allocate time and resources.
Crossing the 7,000+ KEV milestone goes beyond scale to provide greater precision, deeper context, and stronger confidence in how teams prioritize and act on the most critical vulnerabilities.
Validated threats: Each KEV entry reflects observed exploitation in the wild by threat actors, including APT groups, cybercriminal operations, ransomware presence, and automated botnets.
Exploit-aware prioritization: In reality, only a small percentage of tracked vulnerabilities drive real-world incidents. FP KEV provides visibility into that subset so teams can focus remediation efforts where they have immediate impact.
Human-curated intelligence: Every entry is reviewed, validated, and enriched by analysts, with context on exploit maturity, adversary usage, and remediation pathways when available.
This level of clarity allows teams to move faster without sacrificing accuracy. It supports vulnerability management programs that are built around real-world attacker behavior and aligned to current risk.
How Public Vulnerability Data Fits Into the Picture
Public vulnerability catalogs remain useful reference points for tracking disclosures and confirmed exploitation. The CISA Known Exploited Vulnerabilities catalog, for example, gives security teams a curated view into a limited set of vulnerabilities that have been exploited in the wild that impact U.S. government stakeholders.
For many organizations, though, that level of visibility is not enough.
Public catalogs capture only part of the picture. They tend to reflect a narrower slice of exploitation activity, with less detail on how vulnerabilities are being used, which actors are leveraging them, and what defenders should do next. They also rely heavily on CVE-based tracking, leaving gaps around non-CVE exposures and other vulnerabilities that still carry operational risk.
Flashpoint’s FP KEV and Vulnerability Intelligence provide a broader and more actionable view. The advantage is visible in both scale and depth. Of the 7,000 known exploited vulnerabilities in FP KEV, over 800 are missing from CVE. That expanded coverage is paired with the context security teams need to prioritize effectively, including exploit maturity, adversary mapping, affected product detail, and remediation guidance.
Dimension
Public KEV Catalogs
Flashpoint FP KEV
Scope
Varies by provider, with coverage dependent on available sources and methodology
Global, cross-industry coverage
Coverage
CVE-based tracking
CVE and non-CVE vulnerabilities
Context
Limited enrichment
Exploit maturity, adversary mapping, remediation
Update Model
Periodic updates
Continuously updated with analyst input
This is what separates a reference list from an operational dataset. Teams need vulnerability intelligence that supports triage, remediation, reporting, and broader risk reduction efforts. Wider visibility and deeper context make that possible.
The Critical Role of Human-Curated Intelligence
Vulnerability data originates from a wide range of sources with varying levels of completeness and accuracy.
Flashpoint’s intelligence model includes analyst validation to ensure consistency and depth across the dataset.
This process includes:
Reviewing disclosures across public and private sources
Validating exploit availability and usage
Enriching entries with technical and operational context
Analyst input supports:
Accurate classification of vulnerabilities
Clear understanding of exploitation pathways
Timely updates as activity evolves
Supporting Decision-Making Across Teams
Vulnerability intelligence feeds multiple functions across an organization. Teams use this data to align technical actions with current threat activity.
Common use cases include:
Vulnerability management: Align patching priorities with active exploitation trends.
Threat intelligence: Map vulnerabilities to threat actor campaigns and observed behaviors.
Security operations: Tune detection based on known exploit techniques.
Executive reporting: Communicate risk posture using data tied to real-world activity.
Each of these functions relies on consistent, enriched intelligence to maintain alignment.
Proactively Address Vulnerability Risk
Vulnerability discovery continues to expand across software ecosystems, infrastructure, and identity layers.
Security teams require a clear understanding of which issues are relevant to their environment at any given time.
Flashpoint provides primary source intelligence that supports this need through:
Continuous monitoring of vulnerability disclosures and exploitation
Analyst-driven validation and enrichment
Integration-ready data for operational workflows
This approach enables teams to maintain focus, allocate resources effectively, and respond to risk based on current threat activity. Request a demo and learn more today.
It’s one of those coincidences: independent university research teams stumble onto something new and prep their papers for publication — only to realize they’ve solved the exact same puzzle using slightly different methods. That’s exactly what happened with GDDRHammer and GeForge. These two studies describe Rowhammer-style attacks that are so similar the researchers decided to publish them as a joint effort. Then, while we were putting this post together, a third study surfaced — GPUBreach — detailing yet another comparable attack. So today we’re looking at all three.
All three theoretical attacks target graphics accelerators, though this term is not entirely accurate anymore since these devices are so good at parallel processing, they’ve moved far beyond just rendering frames in a game and are now the backbone of AI systems. It’s this industrial use case that is most at risk. Picture a cloud provider renting out GPU resources to all comers. These new attacks demonstrate how, in theory, a single malicious customer could go beyond seizing control of an accelerator to compromise the entire server, access sensitive data, and potentially hack the provider’s entire infrastructure. Let’s break down why this kind of attack is even possible.
Rowhammer in a nutshell
We covered Rowhammer in-depth in previous posts, but here’s the quick version. The original attack was first proposed back in 2014, and it exploits the actual physical properties of RAM chips. Individual memory cells are simple components arranged in tight rows. In theory, reading or writing to one cell shouldn’t affect its neighbors. However, because these chips are packed so densely — with millions or even billions of cells per chip — writing to one spot can sometimes modify the cells next to it.
The 2014 study showed that this isn’t just a recipe for random data corruption; it can be weaponized. By repeatedly accessing (or “hammering”, hence the name) a specific area of memory, an attacker can intentionally flip bits in adjacent cells. If an attacker manages to flip the right bits, he can bypass critical security measures to snag sensitive data or run unauthorized code with full privileges.
Since that first discovery, we’ve seen a constant arms race between new Rowhammer defenses and clever ways to bypass them. We’ve also seen the attack evolve to target newer standards like DDR4 and DDR5. That’s a key takeaway here: for every new type of memory that hits the market, researchers essentially have to reinvent the attack from scratch.
Attacking GDDR6 video memory
The first Rowhammer attack on GPUs was presented back in 2025, but the results were relatively modest. At the time, researchers were able to force bit-flips in GDDR6 memory cells, and show how that data corruption could degrade the performance of an AI system.
These latest papers, however, warn of much more damaging attacks on video memory. Using slightly different techniques, GDDRHammer and GeForge manipulate the page tables — basically the master structures that track where data lives in the GPU’s memory. This enables an attacker to read or write to any part of the video memory, and even reach into the main system RAM managed by the CPU. Modifications to page tables are possible because the researchers have found a way to hammer memory cells much more efficiently. They pulled this off despite the hardware using Target Row Refresh, a core defense designed specifically to stop Rowhammer. TRR detects repeated access to specific cells, and forces a data refresh in the neighboring rows to hamper the attack. However, the researchers discovered a specific pattern of access that can bypass TRR.
How realistic are these GPU attacks?
As is usually the case with this type of research, pulling off these attacks in the real world comes with a lot of contingencies. First off, different GPUs behave differently. For instance, the GeForge attack was significantly more effective on the consumer-grade GeForce RTX 3060. On the industrial-strength Nvidia RTX A6000, the attack’s efficiency dropped by more than five times — even though both cards use the exact same GDDR6 memory standard. Going back to our hypothetical scenario of a malicious cloud customer: for an attack to work, they’d first need to identify exactly which accelerator they’ve been assigned, then profile their exploit specifically for that hardware. In short, this would have to be an incredibly sophisticated and expensive targeted attack.
It’s also worth noting that GDDR6 isn’t the latest and greatest anymore. Consumer devices are moving to GDDR7, while professional-grade hardware often uses high-speed HBM memory. These systems come with ECC (Error Correction Code), a built-in mechanism that checks data integrity. ECC can actually be enabled on cards like the Nvidia A6000; while it might take a small bite out of performance, it effectively makes both of these attacks impossible.
Another tool available to owners of AI-focused servers is enabling the IOMMU (input–output memory management unit) — a system that isolates the GPU’s memory from the CPU’s memory. This will prevent an attack from escalating from the graphics accelerator to the main processor and compromising the entire server. This is where the third study, GPUBreach, comes into play. Its main differentiator from GDDRHammer and GeForge is that it can actually bypass even IOMMU protection! It pulls this off by exploiting some fairly traditional bugs found in NVIDIA drivers.
So, despite the existing hurdles, these three studies prove that Rowhammer attacks remain a potent threat. This is especially true in our current AI boom, which relies on massive, expensive, and potentially vulnerable infrastructure packed with dozens or even hundreds of thousands of computing devices. The Rowhammer timeline goes to show that technical barriers almost never hold for long. In standard RAM, researchers have managed to bypass not only basic fixes like Target Row Refresh, but also more advanced — and theoretically bulletproof — solutions like ECC memory. While the extreme complexity of these exploits means they’ll likely never become a mass-market threat, for anyone running expensive computing systems, they’re definitely a risk factor that can’t be ignored.
At the NDSS Symposium 2026 in San Diego in February, a group of respected researchers presented a study unveiling the AirSnitch attack, which bypasses the Wi-Fi client isolation feature — also commonly known as guest network or device isolation. This attack allows connecting to a single wireless network via an access point, and then gaining access to other connected devices, including those using entirely different service set identifiers (SSIDs) on that same hardware. Targeted devices could easily be running on wireless subnets protected by WPA2 or WPA3 protocols. The attack doesn’t actually break encryption; instead, it exploits the way access points handle group keys and packet routing.
In practical terms, this means that a guest network provides very little in the way of real security. If your guest and employee networks are running on the same physical device, AirSnitch allows a connected attacker to inject malicious traffic into neighboring SSIDs. In some cases, they can even pull off a full-blown man-in-the-middle (MitM) attack.
Wi-Fi security and the role of isolation
Wi-Fi security is constantly evolving; every time a practical attack is made against the latest generation of protection, the industry shifts toward more complex algorithms and procedures. This cycle started with the FMS attacks used to crack WEP encryption keys, and continues to this day: recent examples include the KRACK attacks on WPA2, and the FragAttacks, which impacted every security protocol version from WEP all the way through WPA3.
Attacking modern Wi-Fi networks effectively (and quietly) is no small feat. Most professionals agree that using WPA2/WPA3 with complex keys and separating networks based on their purpose is usually enough for protection. However, only specialists really know that client isolation was never actually standardized within the IEEE 802.11 protocols. Different manufacturers implement isolation in completely different ways — using Layer 2 or Layer 3 of network architecture; in other words, handling it at either the router or the Wi-Fi controller level — meaning the behavior of isolated subnets varies wildly depending on your specific access point or router model.
While marketing claims that client isolation is perfect for keeping restaurant or hotel guests from attacking one another — or ensuring corporate visitors can’t access anything but the internet — in reality, isolation often relies on people not trying to hack it. This is exactly what the AirSnitch research highlights.
Types of AirSnitch attacks
The name AirSnitch doesn’t just refer to a single vulnerability, but a whole family of architectural flaws found in Wi-Fi access points. It’s also the name of an open-source tool used to test routers for these specific weaknesses. However, security professionals need to keep in mind that there’s only a very thin line between testing and attacking.
The model for all these attacks is the same: a malicious client is connected to an access point (AP) where isolation is active. Other users — the targets — are connected to the same SSID or even different SSIDs on that same AP. This is a very realistic scenario; for example, a guest network might be open and unencrypted, or an attacker could simply get the guest Wi-Fi password by posing as a legitimate visitor.
For certain AirSnitch attacks, the attacker needs to know the victim’s MAC or IP address beforehand. Ultimately, how effective each attack is depends on the specific hardware manufacturer (more on that below).
GTK attack
After the WPA2/WPA3 handshake, the access point and the clients agree on a Group Transient Key (GTK) to handle broadcast traffic. In this scenario, the attacker wraps packets destined for a specific victim inside a broadcast traffic envelope. They then send these directly to the victim while spoofing the access point’s MAC address. This attack only allows for traffic injection, meaning the attacker won’t receive a response. However, even that is enough to deliver malicious ICMPv6 routing advertisements, or DNS and ARP messages to the client — effectively bypassing isolation. This is the most universal version of the attack working on any WPA2/WPA3 network that uses a shared GTK. That said, some enterprise-grade access points support GTK randomization for each individual client, which renders this specific method ineffective.
Broadcast packet redirection
This version of the attack doesn’t even require the attacker to authenticate at the access point first. The attacker sends packets to the AP with a broadcast destination address (FF:FF:FF:FF:FF:FF) and the ToDS flag set to 1. As a result, many access points treat this packet as legitimate broadcast traffic; they encrypt it using the GTK, and blast it out to every client on the subnet, including the victim. Just like in the previous method, traffic specifically meant for a single victim can be pre-packaged inside.
Router redirection
This attack exploits an architectural gap between Layer 2 and Layer 3 security found in some manufacturers’ hardware. The attacker sends a packet to the access point, setting the victim’s IP address as the destination at the network layer (L3). However, at the wireless layer (L2), the destination is set to the access point’s own MAC address, so the isolation filter doesn’t trip. The routing subsystem (L3) then dutifully routes the packet back out to the victim, bypassing the L2 isolation entirely. Like the previous methods, this is another transmit-only attack where the attacker can’t see the reply.
Port stealing to intercept packets
The attacker connects to the network using a spoofed version of the victim’s MAC address, and floods the network with ARP responses claiming, “this MAC address is on my port and SSID”. The target network’s router updates its MAC tables, and starts sending the victim’s traffic to this new port instead. Consequently, traffic intended for the victim ends up with the attacker — even if the victim is connected to a completely different SSID.
In a scenario where the attacker connects via an open, unencrypted network, this means traffic meant for a client on a WPA2/WPA3-secured network is actually broadcast over the open air, where not only the attacker but anyone nearby can sniff it.
Port stealing to send packets
In this version, the attacker connects directly to the victim’s Wi-Fi adapter, and bombards it with ARP requests spoofing the access point’s MAC address. As a result, the victim’s computer starts sending its outgoing traffic to the attacker instead of the network. By running both stealing attacks simultaneously, an attacker can, in several scenarios, execute a full MitM attack.
Practical consequences of AirSnitch attacks
By combining several of the techniques described above, a hacker can pull off some pretty serious moves:
Complete bidirectional traffic interception for a MitM attack. This means they can snatch and modify data moving between the victim and the access point without the victim ever knowing.
Hopping between SSIDs. An attacker sitting on a guest network can reach hosts on a locked-down corporate network if both are running off the same physical access point.
Attacks on RADIUS. Since many companies use RADIUS authentication for their corporate Wi-Fi, an attacker can spoof the access point’s MAC address to intercept initial RADIUS authentication packets. From there, they can brute-force the shared secret. Once they have that, they can spin up a rogue RADIUS server and access point to hijack data from any device that connects to it.
Exposing unencrypted data from “secure” subnets: Traffic that’s supposed to be sent to a client under the protection of WPA2/WPA3 can be retransmitted onto an open guest network, where it’s essentially broadcast for anyone to hear.
To pull off these attacks effectively, a hacker needs a device capable of simultaneous data transmission and reception with both the victim’s adapter and the access point. In a real-world scenario, this usually means a laptop with two Wi-Fi adapters running specifically configured Linux drivers. It’s worth noting that the attack isn’t exactly silent: it requires a flood of ARP packets, it can cause brief Wi-Fi glitches when it starts, and network speeds might tank to around 10Mbps. Despite these red flags, it’s still very much a practical threat in many environments.
Vulnerable devices
As part of the study, several enterprise and home access points and routers were put to the test. The list included products from Cisco, Netgear, Ubiquiti, Tenda, D-Link, TP-Link, LANCOM, and ASUS, as well as routers running popular community firmware like DD-WRT and OpenWrt. Every single device tested was vulnerable to at least some of the attacks described here. Even more concerning, the D-Link DIR-3040 and LANCOM LX-6500 were susceptible to every single variation of AirSnitch.
Interestingly, some routers were equipped with protective mechanisms that blocked the attacks, even though the underlying architectural flaws were still present. For example, the Tenda RX2 Pro automatically disconnects any client whose MAC address appears on two BSSIDs simultaneously, which effectively shuts down port stealing.
The researchers emphasize that any network administrator or IT security team serious about defense should test their own specific configurations. That’s the only way to pinpoint exactly which threats are relevant to your organization’s setup.
How to protect your corporate network from AirSnitch
The threat is most immediate for organizations running guest and corporate Wi-Fi networks on the same access points without additional VLAN segmentation. There are also significant risks for companies using RADIUS with outdated settings or weak shared secrets for wireless authentication.
The bottom line is that we need to stop viewing client isolation on an access point as a real security measure, and start seeing it as just a convenience feature. Real security needs to be handled differently:
Segment the network using VLANs. Each SSID should have its own VLAN, with strict 802.1Q packet tagging maintained all the way from the access point to the firewall or router.
Implement stricter packet inspection at the routing level — depending on the hardware capabilities. Features like Dynamic ARP Inspection, DHCP snooping, and limiting the number of MAC addresses per port help defend against IP/MAC spoofing.
Enable individual GTK keys for each client, if your equipment supports it.
Use more resilient RADIUS and 802.1X settings, including modern cipher suites and robust shared secrets.
Log and analyze EAP/RADIUS authentication anomalies in your SIEM. This helps track many attack attempts beyond just AirSnitch. Other red flag events to watch for include the same MAC address appearing on different SSIDs, spikes in ARP requests, or clients rapidly jumping between BSSIDs or VLANs.
Apply security at higher levels of the network topology. Many of these attacks lose their punch if the organization has universally implemented TLS and HSTS for all business application traffic, requires an active VPN for all Wi-Fi connections, or has fully embraced a Zero Trust architecture.
On March 4, 2026, Google and iVerify published reports about a highly sophisticated exploit kit targeting Apple iPhone devices. According to Google, the exploit kit was first discovered in targeted attacks conducted by a customer of an unnamed surveillance vendor. It was later used by other attackers in watering-hole attacks in Ukraine and in financially motivated attacks in China. Additionally, researchers discovered an instance with the debug version of the exploit kit, which revealed the internal names of the exploits and the framework name used by its developers — Coruna. Analysis of the kit showed that it relies on the exploitation of many previously patched vulnerabilities and also includes exploits for CVE-2023-32434 and CVE-2023-38606. These two vulnerabilities particularly caught our attention because they had been first discovered as zero-days used in Operation Triangulation.
Operation Triangulation is a complex mobile APT campaign targeting iOS devices. We discovered it while monitoring the network traffic of our own corporate Wi-Fi network. We noticed suspicious activity that originated from several iOS-based phones. Following the investigation, we learned that this campaign employed a sophisticated spyware implant and multiple zero-day exploits. The investigation lasted for over six months, during which we disclosed our findings in connection to the attack. Kaspersky GReAT experts also presented these findings at the 37th Chaos Communication Congress (37C3).
Although all the details of both CVE-2023-32434 and CVE-2023-38606 have long been publicly available, and other researchers have developed their own exploits without ever seeing the Triangulation code, we decided to closely investigate the exploits used in Coruna. Some of the exploit kit distribution links provided by Google remained active at the time the report was published, which allowed us to collect, decrypt, and analyze all components of Coruna.
During our analysis, we discovered that the kernel exploit for CVE-2023-32434 and CVE-2023-38606 vulnerabilities used in Coruna, in fact, is an updated version of the same exploit that had been used in Operation Triangulation. The images below illustrate a high-level overview of the two attack chains. The exploit in question is highlighted with a red rectangle.
Attack chain of Operation Triangulation (simplified)
Attack chain of Coruna (simplified)
Moreover, we discovered that Coruna includes four additional kernel exploits that we had not seen used in Operation Triangulation, two of which were developed after the discovery of Operation Triangulation. All of these exploits are built on the same kernel exploitation framework and share common code. Code similarities from kernel exploits can also be found in other components of Coruna. These findings led us to conclude that this exploit kit was not patchworked but rather designed with a unified approach. We assume that it’s an updated version of the same exploitation framework that was used — at least to some extent — in Operation Triangulation.
Technical details
While we continue to investigate all exploits and vulnerabilities used by Coruna, this post provides a high-level overview of the exploit kit and attack chain.
Safari
Exploitation begins with a stager that fingerprints the browser and selects and executes appropriate remote code execution (RCE) and pointer authentication code (PAC) exploits depending on the browser version. It also contains a URL to an encrypted file with information about all available packages containing exploits and other components. The stager also includes a 256-bit key used to decrypt it. The URL and decryption key are passed to a payload embedded in PAC exploits.
Payload
The payload is responsible for initiating the exploitation of the kernel. After initialization, the payload first downloads a file with information about other available components. To extract it, the payload performs several steps processing multiple file formats.
First, the downloaded file is decrypted using the ChaCha20 stream cipher. Decryption yields a container with the magic number 0xBEDF00D, which stores LZMA-compressed data.
The file format used by the exploit kit to store compressed data
Offset
Field
0x00
Magic number (0xBEDF00D)
0x04
Decompressed data size
0x08
LZMA-compressed data
The decompressed data presents another container with the magic number 0xF00DBEEF. This file format is used in the exploit kit to store and retrieve files by their IDs.
The file format used by the exploit kit to store files
Offset
Field
0x00
Magic number (0xF00DBEEF)
0x04
Number of entries
0x08
Entry[0].File ID
0x0C
Entry[0].Status
0x10
Entry[0].File offset
0x14
Entry[0].File size
We provide a description of all possible File ID values below. At this stage, when the payload gathers information about all available file packages, this container holds only one file, and its File ID is 0x70000.
Finally, we get to the file with information about all available file packages. It starts with the magic value 0x12345678. The exploit kit uses this file format to obtain URLs and decryption keys for additional components that need to be downloaded.
The file format used by the exploit kit to store information about file packages
Offset
Field
0x00
Magic number (0x12345678)
0x04
Flags
0x08
Directory path
0x108
Number of entries
0x10C
Entry[0].Package ID
0x110
Entry[0].ChaCha20 key
0x130
Entry[0].File name
The components required for exploiting a targeted device are selected using the Package ID. Its high byte specifies the package type and required hardware. We’ve seen the following package types:
0xF2 – exploit for ARM64,
0xF3 – exploit for ARM64E,
0xA2 – Mach-O loader for ARM64,
0xA3 – Mach-O loader for ARM64E,
2 – implant for ARM64,
0xE2 – implant for ARM64E.
The payload code also supports additional package types, such as 0xF1, an exploit for older ARM devices that do not support 64-bit architecture. Interestingly, however, the files for such exploits are missing.
Other bytes of the Package ID define the supported firmware version and CPU generation.
Some of the observed Package IDs (those with unique content)
Package ID
Description
0xF3300000
Kernel exploit (iOS < 14.0 beta 7) and other components
0xF3400000
Kernel exploit (iOS < 14.7) and other components
0xF3700000
Kernel exploit (iOS < 16.5 beta 4) and other components
0xF3800000
Kernel exploit (iOS < 16.6 beta 5) and other components
0xF3900000
Kernel exploit (iOS < 17.2) and other components
0xA3030000
Mach-O loader (iOS 16.X) (A13 – A16)
0xA3050000
Mach-O loader (iOS 16.0 – 16.4)
The files inside these packages are also stored in encrypted and compressed 0xF00DBEEF containers, but this time compression is optional and is determined by the second bit in the Flags field. Different packages contain different sets of files. A description of all possible File IDs is given in the table below.
Observed File IDs
File ID
Description
0x10000
Implant
0x50000
Mach-O loader (default)
0x70000
List of additional components
0x70005
Launcher config
0x80000
Launcher in 0xF2/0xF3 packages, or Mach-O loader in 0xA2/0xA3
0x90000
Kernel exploit
0x90001
Kernel exploit (for Mach-O loader)
0xA0000
Logs cleaner
0xA0001
Mach-O loader component
0xA0002
Mach-O loader component
0xF0000
RPC stager
After downloading the necessary components, the payload begins executing kernel exploits, Mach-O loaders, and the malware launcher. The payload selects an appropriate Mach-O loader based on the firmware version, CPU, and presence of the iokit-open-service permission.
Kernel exploits
We analyzed all five kernel exploits from the kit and discovered that one of them is an updated version of the same exploit we discovered in Operation Triangulation. There are many small changes, but the most noticeable are as follows:
The code takes into account more values from XNU version strings, allowing for more accurate version checking.
Added a check for iOS 17.2. We assume that this was the latest version of iOS at the time of development (released in December 2023).
Added checks for newer Apple processors: A17, M3, M3 Pro, M3 Max (released in fall 2023).
Added a check for iOS version 16.5 beta 4. This version patched the exploit after our report to Apple.
Why does the exploit need to check for iOS 17.2 and newer CPUs if the targeted vulnerabilities were fixed in iOS 16.5 beta 4? The answer can be found by examining other exploits: they are all based on the same source code. The only difference is in the vulnerabilities they exploit, so these checks were added to support the newer exploits and appeared in the older version after recompilation.
Launcher
The launcher is responsible for orchestrating the post-exploitation activities. It also uses the kernel exploit and the interface it provides. However, since the exploit creates special kernel objects during its execution that provide the ability to read and write to kernel memory, the launcher simply reuses these objects without the need to trigger vulnerabilities and go through the entire exploitation path again. The launcher cleans up exploitation artifacts, retrieves the process name for injection from a config with the 0xDEADD00F magic number, injects a stager into the target process, uses it to execute itself, and launches the implant.
Conclusions
This case demonstrates once again the dangers associated with such malicious tools that lie in their potential wide usage. Originally developed for cyber-espionage purposes, this framework is now being used by cybercriminals of a broader kind, placing millions of users with unpatched devices at risk. Given its modular design and ease of reuse, we expect that other threat actors will begin incorporating it into their attacks. We strongly recommend that users install the latest security updates as soon as possible, if they have not already done so.
Cybersecurity researchers have taken a close look at the inner workings of the Predator spyware, developed by the Cyprus-based company Intellexa. Rather than focusing on how the spyware initially infects a device, this latest research zooms in on how the malware behaves once a device has already been compromised.
The most fascinating discovery involves the mechanisms the Trojan uses to hide iOS camera and microphone indicators. By doing so, it can covertly spy on the infected user. In today’s post, we break down what Predator spyware actually is, how the iOS indicator system is designed to work, and how this malware manages to disable these indicators.
What Predator is, how it works, and what… Alien has to do with it
We previously took a deep dive into the most notorious commercial spyware out there in a dedicated feature — where we discussed the star of today’s post, Predator, among the others. You can check out that earlier post for a detailed review of this spyware, but for now, here’s a quick refresher on the essentials.
Predator was originally developed by a North Macedonian company named Cytrox. It was later acquired by the aforementioned Intellexa, a Cyprus-registered firm owned by a former Israeli intelligence officer — a truly international spy games collaboration.
Strictly speaking, Predator is the second half of a spyware duo designed to monitor iOS and Android users. The first component is named Alien; it’s responsible for compromising a device and installing Predator. As you might’ve guessed, these pieces of malware are named after the famous Alien vs. Predator franchise.
An attack using Intellexa’s software typically begins with a message containing a malicious link. When the victim clicks it, they’re directed to a site that leverages a chain of browser and OS vulnerabilities to infect the device. To keep things looking normal and avoid raising suspicion, the user is then redirected to a legitimate website.
Besides Alien, Intellexa offers several other delivery vehicles for landing Predator on a target’s device. These include the Mars and Jupiter systems, which are installed on the service provider’s side to infect devices through a man-in-the-middle attack.
Predator spyware for iOS comes packed with a wide array of surveillance tools. Most notably, it can record and transmit data from the device’s camera and microphone. Naturally, to keep the user from catching on to this suspicious activity, the system’s built-in recording indicators — the green and orange dots at the top of the screen — must be disabled. While it’s been known for some time that Predator could somehow hide these alerts, it’s only thanks to this research that we know how exactly it pulls it off.
How the iOS camera and microphone indicator system works
To understand how Predator disables these indicators, we first need to look at how iOS handles them. Since the release of iOS 14 in 2020, Apple devices have alerted users whenever the microphone or camera is active by displaying an orange or green dot at the top of the screen. If both are running simultaneously, only the green dot is shown.
In iOS 14 and later, an orange dot appears at the top of the screen when the microphone is in use. Source
Just like other iOS user interface elements, recording indicators are managed by a process called SpringBoard, which is responsible for the device’s system-wide UI. When an app starts using the camera or microphone, the system registers the change in that specific module’s state. This activity data is then gathered by an internal system component, which passes the information to SpringBoard for processing. Once SpringBoard receives word that the camera or microphone is active, it toggles the green or orange dot on or off based on that data.
If the camera is in use (or both the camera and microphone are), a green dot appears. Source
From an app’s perspective, the process works like this: first, the app requests permission to access the camera or microphone through the standard iOS permission mechanism. When the app actually needs to use one or both of these modules, it calls the iOS system API. If the user has granted permission, iOS activates the requested module and automatically updates the status indicator. These indicators are strictly controlled by the operating system; third-party apps have no direct access to them.
How Predator interferes with the iOS camera and microphone indicators
Cybersecurity researchers analyzed a captured version of Predator and uncovered traces of multiple techniques used by the spyware’s creators to bypass built-in iOS mechanisms and disable recording indicators.
In the first approach — which appears to have been used during early development — the malware attempted to interfere with the indicators at the display stage right after SpringBoard received word that the camera or microphone was active. However, this method was likely deemed too complex and unreliable by the developers. As a result, this specific function remains in the Trojan as dead code — it’s never actually executed.
Ultimately, Predator settled on a simpler, more effective method that operates at the very level where the system receives data about the camera or microphone being turned on. To do this, Predator intercepts the communication between SpringBoard and the specific component responsible for collecting activity data from these modules.
By exploiting the specific characteristics of Objective-C — the programming language used to write the SpringBoard application — the malware completely blocks the signals indicating that the camera or microphone has been activated. As a result, SpringBoard never receives the signal that the module’s status has changed, so it never triggers the recording indicators.
How to lower your risk of spyware infection
Predator-grade spyware is quite expensive, and typically reserved for high-stakes industrial or state-sponsored espionage. On one hand, this means defending against such a high-tier threat is difficult — and achieving 100% protection is likely impossible. On the other hand, for these same reasons, the average user is statistically unlikely to be targeted.
However, if you’ve reason to believe you’re at risk from Predator or Pegasus-class spyware, here are a few steps you can take to make an attacker’s job much harder:
Don’t click suspicious links from unknown senders.
Regularly update your operating system, browsers, and messaging apps.
Reboot your device occasionally. A simple restart can often help “lose the tail”, forcing attackers to reinfect the device from scratch.
Navigating 2026’s Converged Threats: Insights from Flashpoint’s Global Threat Intelligence Report
In this post, we preview the critical findings of the 2026 Global Threat Intelligence Report, highlighting how the collapse of traditional security silos and the rise of autonomous, machine-speed attacks are forcing a total reimagining of modern defense.
The cybersecurity landscape has reached a point of total convergence, where the silos that once separated malware, identity, and infrastructure have collapsed into a single, high-velocity threat engine. Simultaneously, the threat landscape is shifting from human-led attacks to machine-speed operations as a result of agentic AI, which acts as a force multiplier for the modern adversary.
Flashpoint’s 2026 Global Threat Intelligence Report
Our report uncovers several staggering metrics that illustrate the industrialization of modern cybercrime:
AI-related illicit activity skyrocketed by 1,500% in a single month at the end of 2025.
3.3 billion compromised credentials and cloud tokens have turned identity into the primary exploit vector.
From January 2025 to December 2025, ransomware incidents rose by 53%, as attackers pivot from technical encryption to “pure-play” identity extortion.
Vulnerability disclosures surged by 12% from January 2025 to December 2025, with the window between discovery and mass exploitation effectively vanishing.
These findings are derived from Flashpoint’s Primary Source Collection (PSC), a specialized operating model that collects intelligence directly from original sources, driven by an organization’s unique Priority Intelligence Requirements (PIR). The 2026 Global Threat Intelligence Report leverages this ground-truth data to provide a strategic framework for the year ahead. Download to gain:
A Clear Understanding of the New Convergence Between Identity and AI Discover how threat actors are preparing to transition from generative tools to sophisticated agentic frameworks. Learn how 3.3 billion compromised credentials are being weaponized via automated orchestration to bypass legacy defenses and exploit the connective tissue of modern corporate APIs.
Intelligence on the “Franchise Model” of Global Extortion Gain deep insight into the professionalized operations of today’s most prolific threat actors. From the industrial efficiency of RaaS groups like RansomHub and Clop to the market dominance of the next generation of infostealer malware, we break down the economics driving today’s cybercrime ecosystem.
A Blueprint for Proactive Defense and Risk Mitigation Leverage the latest trends, in-depth analysis, and data-driven insights driven by Primary Source Collection to bolster your security posture by identifying and proactively defending against rising attack vectors.
“As attackers automate exploitation of identity, vulnerabilities, and ransomware, defenders who rely on fragmented visibility will fall behind. To keep pace, organizations must ground their decisions in primary-source intelligence that is drawn from adversarial environments, so that decision-makers can get ahead of this accelerating threat cycle.”
Josh Lefkowitz, CEO & Co-Founder at Flashpoint
The Top Threats at a Glance
Our latest report identifies four driving themes shaping the 2026 threat landscape:
2026 Is the Era of Agentic-Based Cyberattacks
Flashpoint identified a 1,500% rise in AI-related illicit discussions between November and December 2025, signaling a rapid transition from criminal curiosity to the active development of malicious frameworks. Built on data pulled from criminal environments and shaped by fraud use cases, these systems scrape data, adjust messaging for specific targets, rotate infrastructure, and learn from failed attempts without the need for constant human involvement.
“2026 is the era of agentic-based cyberattacks. We’ve seen a 1,500% increase in AI-related illicit discussions in a single month, signaling increased interest in developing malicious frameworks. The discussions evolve into vibe-coded, AI-supported phishing lures, malware, and cybercrime venues. When iteration becomes cheap through automation, attackers can afford to fail repeatedly until they find a successful foothold.”
Ian Gray, Vice President of Cyber Threat Intelligence Operations at Flashpoint
Identity Is the New Exploit
Flashpoint observed over 11.1 million machines infected with infostealers in 2025, fueling a massive inventory of 3.3 billion stolen credentials and cloud tokens. The fundamental mechanics of cybercrime have shifted from breaking in to logging in, as attackers leverage stolen session cookies to behave like legitimate users.
The Patching Window Is Rapidly Closing
Vulnerability disclosures surged by 12% in 2025, with 1 in 3 (33%) vulnerabilities having publicly available exploit code. The strategic gap between discovery and weaponization is increasingly vanishing, as evidenced by mass exploitation of zero-day vulnerabilities in as little as 24 hours after discovery.
Ransomware Is Hacking the Person, Not the Code
As technical defenses against encryption harden, ransomware groups are pivoting to the path of least resistance: human trust. This approach has led to a 53% increase in ransomware, with RaaS groups being responsible for over 87% of all ransomware attacks.
Build Resilience in a Converged Landscape
The findings in the 2026 Global Threat Intelligence Report make one thing clear: incremental improvements to legacy security models are no longer sufficient. As adversaries transition to machine-speed operations, the strategic advantage shifts to organizations that can maintain visibility into the adversarial environments where these attacks are born.
Protecting organizations and communities requires an intelligence-first approach. Download Flashpoint’s 2026 Global Threat Intelligence Report to gain clarity and the data-driven insights needed to safeguard critical assets.
In February 2026, the cybersecurity firm Oversecured published a report that makes you want to factory reset your phone and move into a remote cabin in the woods. Researchers audited 10 popular Android mental health apps — ranging from mood trackers and AI therapists to tools for managing depression and anxiety — and uncovered… 1575 vulnerabilities! Fifty-four of those flaws were classified as critical. Given the download stats on Google Play, as many as 15 million people could be affected. The real kicker? Six out of the ten apps tested explicitly promised users that their data was “fully encrypted and securely protected”.
We’re breaking down this scandalous “brain drain”: what exactly could leak, how it’s happening, and why “anonymity” in these services is usually just a marketing myth.
What was found in the apps
Oversecured is a mobile app security firm that uses a specialized scanner to analyze APK files for known vulnerability patterns across dozens of categories. In January 2026, researchers ran ten mental health monitoring apps from Google Play through the scanner — and the results were, shall we say, “spectacular”.
App Type
Installs
Security vulnerabilities
High-severity
Medium-severity
Low-severity
Total
Mood & habit tracker
10M+
1
147
189
337
AI therapy chatbot
1M+
23
63
169
255
AI emotional health platform
1M+
13
124
78
215
Health & symptom tracker
500k+
7
31
173
211
Depression management tool
100k+
0
66
91
157
CBT-based anxiety app
500k+
3
45
62
110
Online therapy & support community
1M+
7
20
71
98
Anxiety & phobia self-help
50k+
0
15
54
69
Military stress management
50k+
0
12
50
62
AI CBT chatbot
500k+
0
15
46
61
Total
14.7М+
54
538
983
1575
Vulnerabilities found in the 10 tested mental health apps. Source
The anatomy of the flaws
The discovered vulnerabilities are diverse, but they all boil down to one thing: giving attackers access to data that should be under lock and key.
For starters, one of the vulnerabilities allows an attacker to access any internal activity of the app — even that never intended for external eyes. This opens the door to hijacking authentication tokens and user session data. Once an attacker has those, they essentially could gain access to a user’s therapy records.
Another issue is insecure local data storage with read permissions granted to any other app on the device. In other words, that random flashlight app or calculator on your smartphone could potentially read your cognitive behavioral therapy (CBT) logs, personal notes, and mood assessments.
The researchers also found unencrypted configuration data baked right into the APK installation files. This included backend API endpoints and hardcoded URLs for Firebase databases.
Furthermore, several apps were caught using the cryptographically weak java.util.Random class to generate session tokens and encryption keys.
Finally, most of the tested apps lacked root/jailbreak detection. On a rooted device, any third-party app with root privileges could gain total access to every bit of locally stored medical data.
Shockingly, of the 10 apps analyzed, only four received updates in February 2026. The rest haven’t seen a patch since November 2025, and one hasn’t been touched since September 2024. Going 18 months without a security patch is a lifetime in this industry — especially for an app housing mood journals, therapy transcripts, and medication schedules.
Here’s a quick reminder of just how dangerous the misuse of this type of data gets. In 2024, the tech world was rocked by a sophisticated attack on XZ Utils, a critical component found in virtually every operating system based on the Linux kernel. The attacker successfully pressured the maintainer into handing over code commit permissions by exploiting the developer’s public admission of burnout and a lack of motivation to carry on with the project. Had the attack been completed, the damage would have been mind-boggling given that roughly 80% of the world’s servers run on Linux.
What could leak?
What do these apps collect and store? It’s the kind of stuff you’d likely only share with a trusted clinician: therapy session transcripts, mood logs, medication schedules, self-harm indicators, CBT notes, and various clinical assessment scales.
As far back as 2021, complete medical records were selling on the dark web for US$1000 each. For comparison, a stolen credit card number goes for anywhere between US$5 and US$30. Medical records contain a full identity package: name, address, insurance details, and diagnostic history. Unlike a credit card, you can’t exactly “reissue” your medical history. Furthermore, medical fraud is notoriously difficult to spot. While a bank might flag a suspicious transaction in hours, a fraudulent insurance claim for a phantom treatment can go unnoticed for years.
We’ve seen this movie before
The Oversecured study isn’t just an isolated horror story.
Back in 2020, Julius Kivimäki hacked the database of the Finnish psychotherapy clinic Vastaamo, making off with the records of 33 000 patients. When the clinic refused to cough up a €400 000 ransom, Kivimäki began sending direct threats to patients: “Pay €200 in Bitcoin within 24 hours, or else your records go public”. Ultimately, he leaked the entire database onto the dark web anyway. At least two people died by suicide, and the clinic was forced into bankruptcy. Kivimäki was eventually sentenced to six years and three months in prison, marking a record-breaking trial in Finland for the sheer number of victims involved.
In 2023, the U.S. Federal Trade Commission (FTC) slapped the online therapy giant BetterHelp with a US$7.8 million fine. Despite stating on their sign-up page that your data was strictly confidential, the company was caught funneling user info — including mental health questionnaire responses, emails, and IP addresses — to Facebook, Snapchat, Criteo, and Pinterest for targeted advertising. After the dust settled, 800 000 affected users received a grand total of… US$10 each in compensation.
By 2024, the FTC set its sights on the telehealth firm Cerebral, tagging them with a US$7 million fine. Through tracking pixels, Cerebral leaked the data of 3.2 million users to LinkedIn, Snapchat, and TikTok. The haul included names, medical histories, prescriptions, appointment dates, and insurance info. And the cherry on top? The company sent promotional postcards (sans envelopes) to 6000 patients, which effectively broadcasted that the recipients were undergoing psychiatric treatment.
In September 2024, security researcher Jeremiah Fowler stumbled upon an exposed database belonging to Confidant Health, a provider specializing in addiction recovery and mental health services. The database contained audio and video recordings of therapy sessions, transcripts, psychiatric notes, drug test results, and even copies of driver’s licenses. In total, 5.3 terabytes of data, 126 000 files, or 1.7 million records were sitting there without a password.
Why anonymity is an illusion
Developers love to drop the line: “We never share your personal data with anyone.” Technically, that might be true — instead, they share “anonymized profiles”. The catch? De-anonymizing that data isn’t exactly rocket science anymore. Recent research highlights that using LLMs to strip away anonymity has become a routine reality.
Even the “anonymization” process itself is often a mess. A study by Duke University revealed that data brokers are openly hawking the mental health data of Americans. Out of 37 brokers surveyed, 11 agreed to sell data linked to specific diagnoses (like depression, anxiety, and bipolar disorder), demographic parameters, and in some cases, even names and home addresses. Prices started as low as US$275 for 5000 aggregated records.
According to the Mozilla Foundation, by 2023, 59% of popular mental health apps failed to meet even the most basic privacy standards, and 40% had actually become less secure than the previous year. These apps allowed account creation via third-party services (like Google, Apple, and Facebook), featured suspiciously brief privacy policies that glossed over data collection details, and employed a clever little loophole: some privacy policies applied strictly to the company’s website, but not the app itself. In short, your clicks on the site were “protected”, but your actions within the app were fair game.
How to protect yourself
Cutting these apps out of your life entirely is, of course, the most foolproof option — but it’s not the most realistic one. Besides, there’s no guarantee you can actually nuke the data already collected — even if you delete your account. We previously covered the grueling process of scrubbing your info from data broker databases; it’s possible, but prepare for a headache. So, how can you stay safe?
Check permissions before you hit “Install”. In Google Play, navigate to App description → About this app → Permissions. A mood tracker has no business asking for access to your camera, microphone, contacts, or precise GPS location. If it does, it’s not looking out for your well-being — it’s harvesting data.
Actually read the privacy policy. We get it — nobody reads these multi-page manifestos. But when a service is vacuuming up your most intimate thoughts, it’s worth a skim. Look for the red flags: does the company share data with third parties? Can you manually delete your records? Does the policy explicitly cover the app itself, or just the website? You can always feed the policy text into an AI and ask it to flag any privacy deal-breakers.
Check the last updated date. An app that hasn’t seen an update in over six months is likely a playground for unpatched vulnerabilities. Remember: six out of the 10 apps Oversecured tested hadn’t been touched in months.
Disable everything non-essential in your phone’s privacy settings. Whenever prompted, always select “ask not to track”. When an app pleads with you to enable a specific type of tracking — claiming it’s for “internal optimization” — it’s almost always a marketing ploy rather than a functional necessity. After all, if the app truly won’t work without a certain permission, you can always go back and toggle it on later.
Don’t use “Sign in with…” services. Authenticating via Facebook, Apple, Google, or Microsoft creates additional identifiers and gives companies a golden opportunity to link your data across different platforms.
Treat everything you type like a public social media post. If you wouldn’t want a random stranger on the internet reading it, you probably shouldn’t be typing it into an app with over 150 vulnerabilities that hasn’t seen a patch since the year before last.
What else you should know about privacy settings and controlling your personal data online:
Can a computer be infected with malware simply by processing a photo — particularly if that computer is a Mac, which many still believe (wrongly) to be inherently resistant to malware? As it turns out, the answer is yes — if you’re using a vulnerable version of ExifTool or one of the many apps built based on it. ExifTool is a ubiquitous open-source solution for reading, writing, and editing image metadata. It’s the go-to tool for photographers and digital archivists, and is widely used in data analytics, digital forensics, and investigative journalism.
Our GReAT experts discovered a critical vulnerability — tracked as CVE-2026-3102 — which is triggered during the processing of malicious image files containing embedded shell commands within their metadata. When a vulnerable version of ExifTool on macOS processes such a file, the command is executed. This allows a threat actor to perform unauthorized actions in the system, such as downloading and executing a payload from a remote server. In this post, we break down how this exploit works, provide actionable defense recommendations, and explain how to verify if your system is vulnerable.
What is ExifTool?
ExifTool is a free, open-source application addressing a niche but critical requirement: it extracts metadata from files, and enables the processing of both that data and the files themselves. Metadata is the information embedded within most modern file formats that describes or supplements the main content of a file. For instance, in a music track, metadata includes the artist’s name, song title, genre, release year, album cover art, and so on. For photographs, metadata typically consists of the date and time of a shot, GPS coordinates, ISO and shutter speed settings, and the camera make and model. Even office documents store metadata, such as the author’s name, total editing time, and the original creation date.
ExifTool is the industry leader in terms of the sheer volume of supported file formats, as well as the depth, accuracy, and versatility of its processing capabilities. Common use cases include:
Adjusting dates if they’re incorrectly recorded in the source files
Moving metadata between different file formats (from JPG to PNG and so on)
Pulling preview thumbnails from professional RAW formats (such as 3FR, ARW, or CR3)
Retrieving data from niche formats, including FLIR thermal imagery, LYTRO light-field photos, and DICOM medical imaging
Renaming photo/video (etc.) files based on the time of actual shooting, and synchronizing the file creation time and date accordingly
Embedding GPS coordinates into a file by syncing it with a separately stored GPS track log, or adding the name of the nearest populated area
The list goes on and on. ExifTool is available both as a standalone command-line application and an open-source library, meaning its code often runs under the hood of powerful, multi-purpose tools; examples include photo organization systems like Exif Photoworker and MetaScope, or image processing automation tools like ImageIngester. In large digital libraries, publishing houses, and image analytics firms, ExifTool is frequently used in automated mode, triggered by internal enterprise applications and custom scripts.
How CVE-2026-3102 works
To exploit this vulnerability, an attacker must craft an image file in a certain way. While the image itself can be anything, the exploit lies in the metadata — specifically the DateTimeOriginal field (date and time of creation), which must be recorded in an invalid format. In addition to the date and time, this field must contain malicious shell commands. Due to the specific way ExifTool handles data on macOS, these commands will execute only if two conditions are met:
The application or library is running on macOS
The -n (or –printConv) flag is enabled. This mode outputs machine-readable data without additional processing, as is. For example, in -n mode, camera orientation data is output simply, inexplicably, as “six”, whereas with additional processing, it becomes the more human-readable “Rotated 90 CW”. This “human-readability” prevents the vulnerability from being exploited
A rare but by no means fantastical scenario for a targeted attack would look like this: a forensics laboratory, a media editorial office, or a large organization that processes legal or medical documentation receives a digital document of interest. This can be a sensational photo or a legal claim — the bait depends on the victim’s line of work. All files entering the company undergo sorting and cataloging via a digital asset management (DAM) system. In large companies, this may be automated; individuals and small firms run the required software manually. In either case, the ExifTool library must be used under the hood of this software. When processing the date of the malicious photo, the computer where the processing occurs is infected with a Trojan or an infostealer, which is subsequently capable of stealing all valuable data stored on the attacked device. Meanwhile, the victim could easily notice nothing at all, as the attack leverages the image metadata while the picture itself may be harmless, entirely appropriate, and useful.
How to protect against the ExifTool vulnerability
GReAT researchers reported the vulnerability to the author of ExifTool, who promptly released version 13.50, which is not susceptible to CVE-2026-3102. Versions 13.49 and earlier must be updated to remediate the flaw.
It’s critical to ensure that all photo processing workflows are using the updated version. You should verify that all asset management platforms, photo organization apps, and any bulk image processing scripts running on Macs are calling ExifTool version 13.50 or later, and don’t contain an embedded older copy of the ExifTool library.
Naturally, ExifTool — like any software — may contain additional vulnerabilities of this class. To harden your defenses, we also recommend the following:
Isolate the processing of untrusted files. Process images from questionable sources on a dedicated machine or within a virtual environment, strictly limiting its access to other computers, data storage, and network resources.
Continuously track vulnerabilities along the software supply chain. Organizations that rely on open-source components in their workflows can use Open Source Software Threats Data Feed for tracking.
Finally, if you work with freelancers or self-employed contractors (or simply allow BYOD), only allow them to access your network if they have a comprehensive macOS security solution installed.
Still think macOS is safe? Then read about these Mac threats:
The cybersecurity community is still grappling with a sobering realization: one of the most ubiquitous tools in the developer’s toolkit, Notepad++, was hiding a critical vulnerability for over six months. Being so deeply embedded in daily workflows, many organizations did not realize they were vulnerable until a recent security update pulled back the curtain on a sophisticated Chinese state-sponsored campaign, dubbed “Lotus Blossom.”
Investigations have confirmed that the issue wasn’t just a coding error, it was a compromise at the hosting provider level. This means that for much of 2025, even organizations that followed best practices were still potentially open to backdoors from Chinese advanced persistent threat (APT) groups. Here is what you need to know to secure your environment.
Understanding the Notepad++ Vulnerability (CVE-2025-15556)
The vulnerability, tracked as CVE-2025-15556 (VulnDB ID: 430205), exploits a critical flaw in the Notepad++ updater component, WinGUP. In versions prior to the February 2026 patch, the updater failed to verify the file integrity signatures of downloaded installers.
By exploiting this lack of verification, threat actors are able to:
Intercept legitimate update requests originating from WinGUp servers
Redirect traffic to malicious servers via Man-in-the-Middle (MitM) attacks or DNS cache poisoning
Deliver trojanized executables (disguised as update.exe) that appeared to be legitimate software patches
Leveraging this vulnerability, attackers have gained a persistent presence in high-value sectors. According to reports from Kaspersky, the impact has spanned government and telecommunications, critical infrastructure, and financial services.
How CVE-2025-15556 Works
The state-sponsored Lotus Blossom campaign was executed in three attack chains, between July and October 2025. Each phase evolved to evade detection by changing file sizes, IP addresses, and delivery methods.
Phase
Timeline (2025)
Execution Method
Payload
Chain #1
July – August
1MB NSIS installer (update.exe)
Multi-stage attack launching a Cobalt Strike beacon via ProShow.exe.
Chain #2
September
140KB NSIS installer (update.exe)
Rotated C2 URLs to maintain stealth while dropping a Cobalt Strike beacon.
Chain #3
October
Backdoor Deployment
Dropped BluetoothService.exe, log.DLL, and shellcode to establish the Chrysalis backdoor.
Mapping CVE-2025-15556 to MITRE ATT&CK
Flashpoint has mapped Lotus Blossom TTPs (tactics, tools, and procedures) to the MITRE ATT&CK framework. Flashpoint analysts have identified the following techniques:
M1057: Data Loss Prevention M1031: Network Intrusion Prevention
Protecting Against CVE-2025-15556
Proactive defense requires not only reactive patching of CVE-2025-15556, but also active threat hunting using the TTPs identified by Flashpoint analysts. Flashpoint recommends the following actions:
Immediate Update: Ensure all instances of Notepad ++ are updated to v8.9.1 or higher immediately. This version enforces the signature verification that was missing in previous releases.
Audit System Paths: Scan for malicious file paths used for persistence.
Network Defense: Monitor and block traffic to malicious domains.
Endpoint Hardening: Implement Behavior Prevention on Endpoints (M1040) and Audit (M1047) to detect unauthorized registry run keys or new system services.
Outpace Threat Actors Using Flashpoint
Software trust is only as strong as the infrastructure behind it. As organizations respond to these recent updates, having best-in-class vulnerability intelligence and direct visibility into threat actor TTPs is the best defense.
The fourth quarter of 2025 went down as one of the most intense periods on record for high-profile, critical vulnerability disclosures, hitting popular libraries and mainstream applications. Several of these vulnerabilities were picked up by attackers and exploited in the wild almost immediately.
In this report, we dive into the statistics on published vulnerabilities and exploits, as well as the known vulnerabilities leveraged with popular C2 frameworks throughout Q4 2025.
Statistics on registered vulnerabilities
This section contains statistics on registered vulnerabilities. The data is taken from cve.org.
Let’s take a look at the number of registered CVEs for each month over the last five years, up to and including the end of 2025. As predicted in our last report, Q4 saw a higher number of registered vulnerabilities than the same period in 2024, and the year-end totals also cleared the bar set the previous year.
Total published vulnerabilities by month from 2021 through 2025 (download)
Now, let’s look at the number of new critical vulnerabilities (CVSS > 8.9) for that same period.
Total number of published critical vulnerabilities by month from 2021 to 2025< (download)
The graph shows that the volume of critical vulnerabilities remains quite substantial; however, in the second half of the year, we saw those numbers dip back down to levels seen in 2023. This was due to vulnerability churn: a handful of published security issues were revoked. The widespread adoption of secure development practices and the move toward safer languages also pushed those numbers down, though even that couldn’t stop the overall flood of vulnerabilities.
Exploitation statistics
This section contains statistics on the use of exploits in Q4 2025. The data is based on open sources and our telemetry.
Windows and Linux vulnerability exploitation
In Q4 2025, the most prevalent exploits targeted the exact same vulnerabilities that dominated the threat landscape throughout the rest of the year. These were exploits targeting Microsoft Office products with unpatched security flaws.
Kaspersky solutions detected the most exploits on the Windows platform for the following vulnerabilities:
CVE-2018-0802: a remote code execution vulnerability in Equation Editor.
CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor.
CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to assume control of the system.
The list has remained unchanged for years.
We also see that attackers continue to adapt exploits for directory traversal vulnerabilities (CWE-35) when unpacking archives in WinRAR. They are being heavily leveraged to gain initial access via malicious archives on the Windows operating system:
CVE-2023-38831: a vulnerability stemming from the improper handling of objects within an archive.
CVE-2025-6218 (formerly ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. This can lead to arbitrary code execution. We covered this vulnerability in detail in our Q2 2025 report.
CVE-2025-8088: a vulnerability we analyzed in our previous report, analogous to CVE-2025-6218. The attackers used NTFS streams to circumvent controls on the directory into which files were being unpacked.
As in the previous quarter, we see a rise in the use of archiver exploits, with fresh vulnerabilities increasingly appearing in attacks.
Below are the exploit detection trends for Windows users over the last two years.
Dynamics of the number of Windows users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)
The vulnerabilities listed here can be used to gain initial access to a vulnerable system. This highlights the critical importance of timely security updates for all affected software.
On Linux-based devices, the most frequently detected exploits targeted the following vulnerabilities:
CVE-2022-0847, also known as Dirty Pipe: a vulnerability that allows privilege escalation and enables attackers to take control of running applications.
CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation.
CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem.
CVE-2023-32233: another vulnerability in the Netfilter subsystem that creates a use-after-free condition, allowing for privilege escalation due to the improper handling of network requests.
Dynamics of the number of Linux users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)
We are seeing a massive surge in Linux-based exploit attempts: in Q4, the number of affected users doubled compared to Q3. Our statistics show that the final quarter of the year accounted for more than half of all Linux exploit attacks recorded for the entire year. This surge is primarily driven by the rapidly growing number of Linux-based consumer devices. This trend naturally attracts the attention of threat actors, making the installation of security patches critically important.
Most common published exploits
The distribution of published exploits by software type in Q4 2025 largely mirrors the patterns observed in the previous quarter. The majority of exploits we investigate through our monitoring of public research, news, and PoCs continue to target vulnerabilities within operating systems.
Distribution of published exploits by platform, Q1 2025 (download)
Distribution of published exploits by platform, Q2 2025 (download)
Distribution of published exploits by platform, Q3 2025 (download)
Distribution of published exploits by platform, Q4 2025 (download)
In Q4 2025, no public exploits for Microsoft Office products emerged; the bulk of the vulnerabilities were issues discovered in system components. When calculating our statistics, we placed these in the OS category.
Vulnerability exploitation in APT attacks
We analyzed which vulnerabilities were utilized in APT attacks during Q4 2025. The following rankings draw on our telemetry, research, and open-source data.
TOP 10 vulnerabilities exploited in APT attacks, Q4 2025 (download)
In Q4 2025, APT attacks most frequently exploited fresh vulnerabilities published within the last six months. We believe that these CVEs will remain favorites among attackers for a long time, as fixing them may require significant structural changes to the vulnerable applications or the user’s system. Often, replacing or updating the affected components requires a significant amount of resources. Consequently, the probability of an attack through such vulnerabilities may persist. Some of these new vulnerabilities are likely to become frequent tools for lateral movement within user infrastructure, as the corresponding security flaws have been discovered in network services that are accessible without authentication. This heavy exploitation of very recently registered vulnerabilities highlights the ability of threat actors to rapidly implement new techniques and adapt old ones for their attacks. Therefore, we strongly recommend applying the security patches provided by vendors.
C2 frameworks
In this section, we will look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.
The chart below shows the frequency of known C2 framework usage in attacks against users during Q4 2025, according to open sources.
TOP 10 C2 frameworks used by APTs to compromise user systems in Q4 2025 (download)
Despite the significant footprints it can leave when used in its default configuration, Sliver continues to hold the top spot among the most common C2 frameworks in our Q4 2025 analysis. Mythic and Havoc were second and third, respectively. After reviewing open sources and analyzing malicious C2 agent samples that contained exploits, we found that the following vulnerabilities were used in APT attacks involving the C2 frameworks mentioned above:
CVE-2025-55182: a React2Shell vulnerability in React Server Components that allows an unauthenticated user to send commands directly to the server and execute them from RAM.
CVE-2023-36884: a vulnerability in the Windows Search component that allows the execution of commands on a system, bypassing security mechanisms built into Microsoft Office applications.
CVE-2025-53770: a critical insecure deserialization vulnerability in Microsoft SharePoint that allows an unauthenticated user to execute commands on the server.
CVE-2020-1472, also known as Zerologon, allows for compromising a vulnerable domain controller and executing commands as a privileged user.
CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, enabling remote access to a vulnerable OS and high-privilege command execution.
CVE-2025-8088 and CVE-2025-6218 are similar directory-traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user.
The set of vulnerabilities described above suggests that attackers have been using them for initial access and early-stage maneuvers in vulnerable systems to create a springboard for deploying a C2 agent. The list of vulnerabilities includes both zero-days and well-known, established security issues.
Notable vulnerabilities
This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q4 2025 and have a publicly available description.
React2Shell (CVE-2025-55182): a vulnerability in React Server Components
We typically describe vulnerabilities affecting a specific application. CVE-2025-55182 stood out as an exception, as it was discovered in React, a library primarily used for building web applications. This means that exploiting the vulnerability could potentially disrupt a vast number of applications that rely on the library. The vulnerability itself lies in the interaction mechanism between the client and server components, which is built on sending serialized objects. If an attacker sends serialized data containing malicious functionality, they can execute JavaScript commands directly on the server, bypassing all client-side request validation. Technical details about this vulnerability and an example of how Kaspersky solutions detect it can be found in our article.
CVE-2025-54100: command injection during the execution of curl (Invoke-WebRequest)
This vulnerability represents a data-handling flaw that occurs when retrieving information from a remote server: when executing the curl or Invoke-WebRequest command, Windows launches Internet Explorer in the background. This can lead to a cross-site scripting (XSS) attack.
CVE-2025-11001: a vulnerability in 7-Zip
This vulnerability reinforces the trend of exploiting security flaws found in file archivers. The core of CVE-2025-11001 lies in the incorrect handling of symbolic links. An attacker can craft an archive so that when it is extracted into an arbitrary directory, its contents end up in the location pointed to by a symbolic link. The likelihood of exploiting this vulnerability is significantly reduced because utilizing such functionality requires the user opening the archive to possess system administrator privileges.
This vulnerability was associated with a wave of misleading news reports claiming it was being used in real-world attacks against end users. This misconception stemmed from an error in the security bulletin.
RediShell (CVE-2025-49844): a vulnerability in Redis
The year 2025 saw a surge in high-profile vulnerabilities, several of which were significant enough to earn a unique nickname. This was the case with CVE-2025-49844, also known as RediShell, which was unveiled during a hacking competition. This vulnerability is a use-after-free issue related to how the load command functions within Lua interpreter scripts. To execute the attack, an attacker needs to prepare a malicious script and load it into the interpreter.
As with any named vulnerability, RediShell was immediately weaponized by threat actors and spammers, albeit in a somewhat unconventional manner. Because technical details were initially scarce following its disclosure, the internet was flooded with fake PoC exploits and scanners claiming to test for the vulnerability. In the best-case scenario, these tools were non-functional; in the worst, they infected the system. Notably, these fraudulent projects were frequently generated using LLMs. They followed a standardized template and often cross-referenced source code from other identical fake repositories.
CVE-2025-24990: a vulnerability in the ltmdm64.sys driver
Driver vulnerabilities are often discovered in legitimate third-party applications that have been part of the official OS distribution for a long time. Thus, CVE-2025-24990 has existed within code shipped by Microsoft throughout nearly the entire history of Windows. The vulnerable driver has been shipped since at least Windows 7 as a third-party driver for Agere Modem. According to Microsoft, this driver is no longer supported and, following the discovery of the flaw, was removed from the OS distribution entirely.
The vulnerability itself is straightforward: insecure handling of IOCTL codes leading to a null pointer dereference. Successful exploitation can lead to arbitrary command execution or a system crash resulting in a blue screen of death (BSOD) on modern systems.
CVE-2025-59287: a vulnerability in Windows Server Update Services (WSUS)
CVE-2025-59287 represents a textbook case of insecure deserialization. Exploitation is possible without any form of authentication; due to its ease of use, this vulnerability rapidly gained traction among threat actors. Technical details and detection methodologies for our product suite have been covered in our previous advisories.
Conclusion and advice
In Q4 2025, the rate of vulnerability registration has shown no signs of slowing down. Consequently, consistent monitoring and the timely application of security patches have become more critical than ever. To ensure resilient defense, it is vital to regularly assess and remediate known vulnerabilities while implementing technology designed to mitigate the impact of potential exploits.
Continuous monitoring of infrastructure, including the network perimeter, allows for the timely identification of threats and prevents them from escalating. Effective security also demands tracking the current threat landscape and applying preventative measures to minimize risks associated with system flaws. Kaspersky Next serves as a reliable partner in this process, providing real-time identification and detailed mapping of vulnerabilities within the environment.
Securing the workplace remains a top priority. Protecting corporate devices requires the adoption of solutions capable of blocking malware and preventing it from spreading. Beyond basic measures, organizations should implement adaptive systems that allow for the rapid deployment of security updates and the automation of patch management workflows.
N-Day Vulnerability Trends: The Shrinking Window of Exposure and the Rise of “Turn-Key” Exploitation
In this post we explore the data-driven shrinkage of the Time to Exploit (TTE) window from 745 days to just 44, and examine why N-day vulnerabilities have become the “turn-key” weapon of choice for modern threat actors.
The race between defenders and threat actors has entered a new, more volatile phase: the rapidly accelerating exploitation of N-day vulnerabilities. Different from zero-days, N-day vulnerabilities are known security flaws that have been publicly disclosed but remain unpatched or unmitigated on an organization’s systems.
Historically, enterprises operated under the assumption of a “patching grace period,” the designated window of time allowed for a vendor to test and deploy a fix before a system is considered non-compliant or at high risk. However, this window is effectively collapsing, with Flashpoint finding that N-days now represent over 80% of all Known Exploited Vulnerabilities (KEVs) tracked over the past four years.
The Collapse of the Time to Exploit (TTE) Window
The most sobering trend for security operations (SecOps) and exposure management teams is the dramatic reduction in Time to Exploit (TTE). In 2020, the average TTE, the time between a vulnerability’s disclosure and its first observed exploitation, was 745 days. By 2025, Flashpoint found that this window has now plummeted to an average of just 44 days.
2025
2024
2023
2022
2021
2020
Average TTE
44
115
296
405
518
745
This contraction represents a strategic shift in adversary tempo. Attackers are no longer waiting for complex, bespoke exploits; they are moving at breakneck speeds to weaponize public disclosures.
N-Days Provide a “Turn-Key” Exploit Advantage
Adversaries have gained a significant advantage through the rapid weaponization of researcher-published Proof-of-Concept (PoC) code. When a fully functional exploit is released alongside a vulnerability disclosure, it becomes a “turn-key” solution for attackers. By combining these ready-made exploits with internet-wide scanning tools like Shodan or FOFA, even unsophisticated threat actors can conduct mass exploitation across large segments of the internet in hours.
A prime example of this path of least resistance approach was observed in the leaked internal chat logs of the BlackBasta ransomware group. Analysis revealed that of the 65 CVEs discussed by the group, 54 were already known KEVs. Rather than spending resources on original zero-day research, threat actors are simply leveraging known, yet unpatched and exploitable vulnerabilities for their campaigns.
Defensive Software is a Primary Target for N-Days
The very software designed to protect enterprise firewalls, VPN gateways, and edge networking devices is consistently the most targeted category for both N-day and zero-day exploitation.
Because cybersecurity devices must be internet-facing to function, they provide a constant, unauthenticated attack surface. In 2025 alone, Flashpoint observed 37 N-days and 52 zero-days specifically targeting security and perimeter software. The requirement for these systems to remain open to external traffic means they will continue to be disproportionately targeted by advanced persistent threat (APT) groups and cybercriminals alike.
Attributing N-Day Attacks
While tracking the “how” of an attack is critical, tracking who is responsible remains a fragmented challenge for the industry. Attribution is often hampered by naming fatigue, where different vendors assign their own designated unique monikers to the same actor. For instance, the widely known threat actor group Lazarus has over 40 distinct designations across the industry, including “Diamond Sleet,” “NICKEL ACADEMY,” and “Guardians of Peace”.
Despite these naming complexities, global activity patterns remain clear. China remains the most active nation-state actor in the vulnerability exploitation space, consistently outpacing Russia, Iran, and North Korea in both the volume and scope of their campaigns.
Obstacles for Enterprise Security: Asset Blindness and the CVE Dependency Trap
Why are organizations struggling to keep pace? The primary factor isn’t a lack of effort, but a lack of visibility.
1. The Asset Inventory Gap
The single greatest breakthrough an enterprise can achieve is not a new AI tool, but a complete asset inventory. Most large organizations are lucky to have an accurate inventory of even 25% of their total assets. Without knowing what you own, vulnerability scans can take days or weeks to return results that the adversary is already using to probe your network.
2. The CVE Blindspot
Most traditional security tools are CVE-dependent. However, thousands of vulnerabilities are disclosed every year that never receive an official CVE ID. These “missing” vulnerabilities represent a massive blindspot for standard scanners. Intelligence-led exposure management requires looking beyond the CVE ecosystem into proprietary databases like Flashpoint’s VulnDB, which tracks over 105,000 vulnerabilities that public sources miss.
Move Towards Intelligence-Led Exposure Management Using Flashpoint
To survive in an era where weaponization can happen in under 24 hours, organizations must shift from reactive patching to a threat-informed and proactive security approach. This means:
Prioritizing by Exploitability and Threat Actor Activity: Focus on vulnerabilities that are remotely exploitable and have known public exploits, rather than just high CVSS scores.
Adopting an Asset-Inventory Approach: Moving away from slow, periodic scans in favor of continuous asset mapping that allows for immediate triage.
Operationalizing Intelligence: Embedding real-time threat data directly into SOC and IR workflows to reduce the “mean time to action”.
The goal of exposure management is to look at your organization through the adversary’s lens. By understanding which N-days threat actors are actually discussing and weaponizing in the wild, defenders can finally start to close the window of exposure before a potential compromise can occur.
Flashpoint’s vulnerability threat intelligence can help your organization go from reactive to proactive. Request a demo today and gain access to quality vulnerability intelligence that enables intelligence-led exposure management.
Over the past two months researchers have reported three vulnerabilities that can be exploited to bypass authentication in Fortinet products using the FortiCloud SSO mechanism. The first two – CVE-2025-59718 and CVE-2025-59719 – were found by the company’s experts during a code audit (although CVE-2025-59718 has already made it into CISA’s Known Exploited Vulnerabilities Catalog), while the third – CVE-2026-24858 – was identified directly during an investigation of unauthorized activity on devices. These vulnerabilities allow attackers with a FortiCloud account to log into various companies’ FortiOS, FortiManager, FortiAnalyzer, FortiProxy, and FortiWeb accounts if the SSO feature is enabled on the given device.
To protect companies that use both our Kaspersky Unified Monitoring and Analysis Platform and Fortinet devices, we’ve created a set of correlation rules that help detect this malicious activity. The rules are already available for customers to download from Kaspersky SIEM repository; the package name is: [OOTB] FortiCloud SSO abuse package – ENG.
Contents of the FortiCloud SSO abuse package
The package includes three groups of rules. They’re used to monitor the following:
Indicators of compromise: source IP addresses, usernames, creation of a new account with specific names;
critical administrator actions, such as logging in from a new IP address, creating a new account, logging in via SSO, logging in from a public IP address, exporting device configuration;
suspicious activity: configuration export or account creation immediately after a suspicious login.
Rules marked “(info)” may potentially generate false positives, as events critical for monitoring authentication bypass attempts may be entirely legitimate. To reduce false positives, add IP addresses or accounts associated with legitimate administrative activity to the exceptions.
As new attack reports emerge, we plan to supplement the rules marked with “IOC” with new information.
Additional recommendations
We also recommend using rules from the FortiCloud SSO abuse package for retrospective analysis or threat hunting. Recommended analysis period: starting from December 2025.
For the detection rules to work correctly, you need to ensure that events from Fortinet devices are received in full and normalized correctly. We also recommend configuring data in the “Extra” field when normalizing events, as this field contains additional information that may need investigating.
We detail our discovery of CVE-2025-0921. This privileged file system flaw in SCADA system Iconics Suite could lead to a denial-of-service (DoS) attack.
Millions of IT systems — some of them industrial and IoT — may start behaving unpredictably on January 19. Potential failures include: glitches in processing card payments; false alarms from security systems; incorrect operation of medical equipment; failures in automated lighting, heating, and water supply systems; and many more or less serious types of errors. The catch is — it will happen on January 19, 2038. Not that that’s a reason to relax — the time left to prepare may already be insufficient. The cause of this mass of problems will be an overflow in the integers storing date and time. While the root cause of the error is simple and clear, fixing it will require extensive and systematic efforts on every level — from governments and international bodies and down to organizations and private individuals.
The unwritten standard of the Unix epoch
The Unix epoch is the timekeeping system adopted by Unix operating systems, which became popular across the entire IT industry. It counts the seconds from 00:00:00 UTC on January 1, 1970, which is considered the zero point. Any given moment in time is represented as the number of seconds that have passed since that date. For dates before 1970, negative values are used. This approach was chosen by Unix developers for its simplicity — instead of storing the year, month, day, and time separately, only a single number is needed. This facilitates operations like sorting or calculating the interval between dates. Today, the Unix epoch is used far beyond Unix systems: in databases, programming languages, network protocols, and in smartphones running iOS and Android.
The Y2K38 time bomb
Initially, when Unix was developed, a decision was made to store time as a 32-bit signed integer. This allowed for representing a date range from roughly 1901 to 2038. The problem is that on January 19, 2038, at 03:14:07 UTC, this number will reach its maximum value (2,147,483,647 seconds) and overflow, becoming negative, and causing computers to “teleport” from January 2038 back to December 13, 1901. In some cases, however, shorter “time travel” might happen — to point zero, which is the year 1970.
This event, known as the “year 2038 problem”, “Epochalypse”, or “Y2K38”, could lead to failures in systems that still use 32-bit time representation — from POS terminals, embedded systems, and routers, to automobiles and industrial equipment. Modern systems solve this problem by using 64 bits to store time. This extends the date range to hundreds of billions of years into the future. However, millions of devices with 32-bit dates are still in operation, and will require updating or replacement before “day Y” arrives.
In this context, 32 and 64 bits refer specifically to the date storage format. Just because an operating system or processor is 32-bit or 64-bit, it doesn’t automatically mean it stores the date in its “native” bit format. Furthermore, many applications store dates in completely different ways, and might be immune to the Y2K38 problem, regardless of their bitness.
In cases where there’s no need to handle dates before 1970, the date is stored as an unsigned 32-bit integer. This type of number can represent dates from 1970 to 2106, so the problem will arrive in the more distant future.
Differences from the year 2000 problem
The infamous year 2000 problem (Y2K) from the late 20th century was similar in that systems storing the year as two digits could mistake the new date for the year 1900. Both experts and the media feared a digital apocalypse, but in the end there were just numerous isolated manifestations that didn’t lead to global catastrophic failures.
The key difference between Y2K38 and Y2K is the scale of digitization in our lives. The number of systems that will need updating is way higher than the number of computers in the 20th century, and the count of daily tasks and processes managed by computers is beyond calculation. Meanwhile, the Y2K38 problem has already been, or will soon be, fixed in regular computers and operating systems with simple software updates. However, the microcomputers that manage air conditioners, elevators, pumps, door locks, and factory assembly lines could very well chug along for the next decade with outdated, Y2K38-vulnerable software versions.
Potential problems of the Epochalypse
The date’s rolling over to 1901 or 1970 will impact different systems in different ways. In some cases, like a lighting system programmed to turn on every day at 7pm, it might go completely unnoticed. In other systems that rely on complete and accurate timestamps, a full failure could occur — for example, in the year 2000, payment terminals and public transport turnstiles stopped working. Comical cases are also possible, like issuing a birth certificate with a date in 1901. Far worse would be the failure of critical systems, such as a complete shutdown of a heating system, or the failure of a bone marrow analysis system in a hospital.
Cryptography holds a special place in the Epochalypse. Another crucial difference between 2038 and 2000 is the ubiquitous use of encryption and digital signatures to protect all communications. Security certificates generally fail verification if the device’s date is incorrect. This means a vulnerable device would be cut off from most communications — even if its core business applications don’t have any code that incorrectly handles the date.
Unfortunately, the full spectrum of consequences can only be determined through controlled testing of all systems, with separate analysis of a potential cascade of failures.
The malicious exploitation of Y2K38
IT and InfoSec teams should treat Y2K38 not as a simple software bug, but as a vulnerability that can lead to various failures, including denial of service. In some cases, it can even be exploited by malicious actors. To do this, they need the ability to manipulate the time on the targeted system. This is possible in at least two scenarios:
Interfering with NTP protocol data by feeding the attacked system a fake time server
Spoofing the GPS signal — if the system relies on satellite time
Exploitation of this error is most likely in OT and IoT systems, where vulnerabilities are traditionally slow to be patched, and the consequences of a failure can be far more substantial.
An example of an easily exploitable vulnerability related to time counting is CVE-2025-55068 (CVSSv3 8.2, CVSSv4 base 8.8) in Dover ProGauge MagLink LX4 automatic fuel-tank gauge consoles. Time manipulation can cause a denial of service at the gas station, and block access to the device’s web management panel. This defect earned its own CISA advisory.
The current status of Y2K38 mitigation
The foundation for solving the Y2K38 problem has been successfully laid in major operating systems. The Linux kernel added support for 64-bit time even on 32-bit architectures starting with version 5.6 in 2020, and 64-bit Linux was always protected from this issue. The BSD family, macOS, and iOS use 64-bit time on all modern devices. All versions of Windows released in the 21st century aren’t susceptible to Y2K38.
The situation at the data storage and application level is far more complex. Modern file systems like ZFS, F2FS, NTFS, and ReFS were designed with 64-bit timestamps, while older systems like ext2 and ext3 remain vulnerable. Ext4 and XFS require specific flags to be enabled (extended inode for ext4, and bigtime for XFS), and might need offline conversion of existing filesystems. In the NFSv2 and NFSv3 protocols, the outdated time storage format persists. It’s a similar patchwork landscape in databases: the TIMESTAMP type in MySQL is fundamentally limited to the year 2038, and requires migration to DATETIME, while the standard timestamp types in PostgreSQL are safe. For applications written in C, pathways have been created to use 64-bit time on 32-bit architectures, but all projects require recompilation. Languages like Java, Python, and Go typically use types that avoid the overflow, but the safety of compiled projects depends on whether they interact with vulnerable libraries written in C.
A massive number of 32-bit systems, embedded devices, and applications remain vulnerable until they’re rebuilt and tested, and then have updates installed by all their users.
Various organizations and enthusiasts are trying to systematize information on this, but their efforts are fragmented. Consequently, there’s no “common Y2K38 vulnerability database” out there (1, 2, 3, 4, 5).
Approaches to fixing Y2K38
The methodologies created for prioritizing and fixing vulnerabilities are directly applicable to the year 2038 problem. The key challenge will be that no tool today can create an exhaustive list of vulnerable software and hardware. Therefore, it’s essential to update inventory of corporate IT assets, ensure that inventory is enriched with detailed information on firmware and installed software, and then systematically investigate the vulnerability question.
The list can be prioritized based on the criticality of business systems and the data on the technology stack each system is built on. The next steps are: studying the vendor’s support portal, making direct inquiries to hardware and software manufacturers about their Y2K38 status, and, as a last resort, verification through testing.
When testing corporate systems, it’s critical to take special precautions:
Never test production systems.
Create a data backup immediately before the test.
Isolate the system being tested from communications so it can’t confuse other systems in the organization.
If changing the date uses NTP or GPS, ensure the 2038 test signals cannot reach other systems.
After testing, set the systems back to the correct time, and thoroughly document all observed system behaviors.
If a system is found to be vulnerable to Y2K38, a fixing timeline should be requested from the vendor. If a fix is impossible, plan a migration; fortunately, the time we have left still allows for updating even fairly complex and expensive systems.
The most important thing in tackling Y2K38 is not to think of it as a distant future problem whose solution can easily wait another five to eight years. It’s highly likely that we already have insufficient time to completely eradicate the defect. However, within an organization and its technology fleet, careful planning and a systematic approach to solving the problem will allow to actually make it in time.
Login
Table Of Contents
, which tracks over 
