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.
• Use threat intelligence feeds specifically focused on open-source components to check the packages used in software development.
• Make sure security awareness training covers everyone — including developers. Leverage specialized solutions like Kaspersky Automated Security Awareness Platform.
• Make sure developers are aware of the latest attack patterns — you can keep them in the loop by following the Development tag right here on this

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.

Companies work systematically to reduce their attack surface. They segment networks, manage vulnerabilities, roll out EDR/XDR, and try to automate their response efforts. As paradoxical as it may seem, they often overlook one massive piece of the puzzle: the security of the very tools managing that entire defense system.

This can occur due to a mental blind spot. It’s easy to assume that, because an organization installed all security solutions needed, it’s safe. In reality, any added software (even security tools) actually expands attack surface. This means those tools need protection, too — starting with hardening them through the right settings.

Why a breached security console is a nightmare scenario

Security tools are only as strong as the system running them. If an attacker manages to break into an organization’s infrastructure and seize control of the security management console, they basically have full rein there. It’s the ultimate skeleton key — giving them direct access to centralized policy management, endpoint monitoring, API integrations, and everything in between.

In this scenario, the attacker doesn’t need to waste time finding clever ways to bypass defenses — all they need do is modify the configuration. With console access, a hacker can skip the hard parts of a breach:

• They don’t have to scout the network; the console gives them a bird’s-eye view of the entire infrastructure and security architecture instantly.
• No need to hide their malicious activity — they can simply tweak security policies, kill specific tools, or silence some alerts.
• Instead of inventing ways to spread the payload to endpoints discreetly, they can leverage the console’s built-in tools for mass software and update installation.

This is exactly why control layer compromise is so dangerous. A proactive cybersecurity mindset isn’t about how many tools are implemented; it’s about how resilient corporate security architecture actually is. If the control layer is the weak link, no amount of hi-tech software can mitigate that risk.

How to protect the security console

On paper, most security management systems already have all the mechanisms needed to beef up protection. The problem? These hardening measures — even basic stuff like two-factor authentication — are often available but not mandatory. Security recommendations get published, but they don’t always get implemented in a consistent manner. Sometimes, they’re just flat-out ignored. Even worse, critical security settings that are turned on by default can often be disabled with a single click —propagating that change to every user instantly. And let’s be honest: people often disable these features in the name of convenience.

In the real world, this means that corporate security ends up relying on an admin’s personal discipline. But discipline can’t serve as an architectural defense mechanism.

The modern approach to protecting the control layer is shifting toward a secure-by-default model. In this setup, critical protections are baked into the base configuration, and the ability to turn them off globally is restricted. Essentially, security stops being an optional feature.

It’s all about removing the guesswork from the security of defensive tools, and shrinking the attack surface at the management level.

How we implement this approach in Kaspersky Security Center Linux

Our products are consistently moving toward a model where critical security mechanisms are part of the base architecture rather than an optional feature. We recently released a new version (16.1) of Kaspersky Security Center Linux, where this architectural shift is built into its core principles — primarily by tightening console access control. Now, two-factor authentication is enabled by default, and the ability to disable it globally has been removed. Before upgrading, administrators must ensure 2FA is enabled for all users, including those working through the Web Console or using OpenAPI automation.

This establishes fundamental protection for privileged access at the console level. It reduces the risk of compromised administrative accounts, protects automation channels, lowers the likelihood of API abuse, and eliminates the vulnerabilities that come from making security optional. In this way, the potential attack surface is reduced specifically at the management control layer.

However, as mentioned before, the problem with most consoles and management systems isn’t a lack of security features, but a lack of systematic control over how they’re used. For example, we often see administrators with excessive privileges or insecure administration server connection settings. We’ve already provided a hardening guide for Kaspersky Security Center that covers these issues in detail, but unfortunately not everyone takes the time to read through deep technical manuals.

That’s why, to make sure no one misses the key points, we’ve put together a structured checklist for hardening Kaspersky Security Center Linux, ver. 16.1. This checklist:

• Allows to verify that authentication and access privileges are configured correctly
• Helps identify roles and users with excessive privileges
• Provides guidance on restricting network access to the console
• Emphasizes the protection of APIs
• Strengthens encryption requirements
• Ensures that auditing and logging are set up properly
• Reduces the risk of configuration gaps

Essentially, this is a tool for a systematic audit of the control layer. It ensures the console doesn’t become an entry point or a tool for attackers to move laterally through infrastructure. The fewer critical settings are left at the user’s discretion — the lower the risk of error or compromise.

Enhanced authentication and structured hardening of the administration console aren’t just minor tweaks; they represent a more thorough approach to security management. We plan to continue developing this protection layer — reducing the attack surface not just at the endpoint level, but within the management system itself. You can learn more about Kaspersky Security Center on the console page, and the hardening checklist is available on our technical support site.