2026-07-12 AI创业新闻

Compromised jscrambler 8.14.0 npm Release Drops Rust Infostealer During Install

The jscrambler npm package was compromised, and simply installing its 8.14.0 release runs an infostealer on your machine. Published on July 11, 2026, the malicious version carries a preinstall hook that drops and executes a native binary, one build each for Windows, macOS, and Linux. Socket flagged the release six minutes after it was published . If you or one of your build systems pulled it in that window, the payload has already run with whatever access your install process had.

None of this is in the prior release, 8.13.0. The package diff shows two new files under dist/: setup.js, a small loader, and intro.js. Despite the name, intro.js is not JavaScript but a roughly 7.8MB container packing three gzip-compressed native binaries, one each for Linux, Windows, and macOS. On install, setup.js picks the binary for the host operating system, writes it under a random name in the system temp directory, marks it executable, and launches it detached with its output hidden.

The added files are in the published package, but nowhere in jscrambler’s public source. StepSecurity and SafeDep both pulled and analyzed the release, and both report no matching commit, tag, or pull request for 8.14.0 in the GitHub repository. Its latest tag is still 8.13.0. The version was pushed straight to npm under a legitimate maintainer account, bypassing the project’s normal release flow.

That points to a compromised npm account or build pipeline. Which of the two has not been established. The payload is a Rust infostealer, built for all three platforms, that sweeps a developer machine for secrets and ships them to a drop server over TLS, according to Socket’s updated analysis and a statement to The Hacker News. The target list is broad and aimed at developers: cloud credentials from AWS, Azure, and Google Cloud, including the metadata endpoints CI runners use; cryptocurrency wallets and seed phrases from MetaMask, Phantom, and Exodus; the Bitwarden password manager vault; browser-stored passwords and cookies; and Discord, Slack, Telegram, and Steam sessions.

It also goes after something newer: the config files for AI coding tools, including Claude Desktop, Cursor, Windsurf, VS Code, and Zed, where API keys and Model Context Protocol server credentials tend to sit. The binaries do more than steal. On Linux, the payload links the kernel’s BPF library and can load an eBPF program straight into the kernel from memory. That is a foothold in the kernel, not the userspace file access that the rest of the stealer relies on.

StepSecurity and SafeDep both flagged the capability, though what the eBPF does is still being pulled apart. The Windows and macOS builds add anti-debugging checks, and the stealer wires in persistence to survive a reboot: a hidden Windows scheduled task set to relaunch every minute, and a macOS LaunchAgent that reloads on login. Its command-and-control details stay encrypted in the binary and never surfaced in static analysis. StepSecurity’s runtime monitoring caught the dropped binary reaching out to two hard-coded IP addresses and to Tor infrastructure, the first network indicators published for the campaign.

jscrambler is a build-time tool, installed as a development dependency or run from CI. Those environments hold what the stealer collects: cloud keys, deploy tokens, and source code that a build or CI process can reach. Source: Step Security The package sees about 15,800 downloads a week, and how many pulled the compromised version is not yet known. That is a far smaller footprint than the packages hit in the big npm compromises of the past year, which pull billions of downloads a week between them.

For a stealer aimed at build machines, though, reach was never the point. The access is. The Shai-Hulud worm ran from an install hook to steal tokens and spread through hundreds of packages that September. The widely used chalk and debug packages were taken over through a phished maintainer account and used to reroute crypto payments.

In March, a hijacked account pushed a cross-platform trojan into Axios , an HTTP library with more than 83 million weekly downloads. What makes the timing here sharp is that npm had just moved against this exact route: npm 12 shipped on July 8, three days before this release, with dependency install scripts off by default . On npm 12, a preinstall hook like this one does not run unless someone approves it. Older clients still run them automatically.

Version 8.15.0 has since replaced it at the top of npm’s version list , published from the same maintainer account and showing none of the malware alerts 8.14.0 tripped: no install script, no bundled binary. But 8.14.0 was not pulled. It is still on npm, so any lockfile or command pinned to it keeps installing the stealer. Only the main CLI package was hit; the jscrambler plugins for webpack, gulp, Metro, and grunt stayed on their clean June releases, with no install hooks.

What to do now Get off 8.14.0. Move to 8.15.0, or pin to 8.13.0 for a release from before the incident, and clear jscrambler@8.14.0 from lockfiles and caches. Work out whether you installed 8.14.0. Check lockfiles and package-manager logs for jscrambler@8.14.0, and CI records for any run of dist/setup.js, from July 11 on.

The loader drops its payload under a random name in the temp directory, so there is no fixed binary name to grep for; line up install timestamps against Node child processes and temp-directory execution instead. On Windows, check Task Scheduler for hidden tasks; on macOS, inspect ~/Library/LaunchAgents for unfamiliar plists. If 8.14.0 ran on a machine, treat every secret it could reach as stolen, not just exposed. Rotate cloud keys, npm and GitHub tokens, and AI-tool and MCP API keys; revoke Discord, Slack, browser, and Bitwarden sessions; and move any crypto out of wallets on that host.

Block the two command-and-control IPs listed below. The cleanup was fast, but a stealer does its work in the seconds after install. A build pinned to 8.14.0, on an older client that runs install scripts, still runs the payload. And on any machine that already ran it, the secrets were gone before 8.15.0 ever reached the top of the list.

Indicators of compromise Malicious package: jscrambler@8.14.0. SHA-256 hashes for the added files and their decompressed payloads: dist/setup.js: a742de963f14a92d24ebcbc7b44ac867e23a20d31d1b0094a13a4f83287f4e60 dist/intro.js: a41a523ef9517aab37ed6eea0ec881821bdcb7aefcb5c5f603adc7907f868c86 Linux payload: fbbcf4d8f98168f78f5c0c47a9ae56d59ec8ac84a7c9ca6b797fedfb8d62d2bd Windows payload: b7ca95d1b23c8e67416a25cedf741de0917c2096bbc9d24649eea7853d054903 macOS payload: c8fd47d36bdf7c825378593ab82ed8c24d1dc52e26b507812393e24e1d5201fd Network endpoints StepSecurity observed at runtime. The two IPs are the direct attacker endpoints; the binary also reaches Tor infrastructure, likely for connectivity or routing: C2 IP: 37.27.122[.]124 C2 IP: 57.128.246[.]79 Tor infrastructure: check.torproject[.]org, archive.torproject[.]org On-host artifacts: a randomly named hidden file in the system temp directory, of the form .{random} or .{random}.exe on Windows, plus a hidden Windows scheduled task or a macOS LaunchAgent for persistence. Found this article interesting?

Hackers Weaponize Balochistan Police Portal in Multi-Group Espionage Campaigns

Cybersecurity researchers have disclosed details of sustained cyber espionage activity against several Pakistani law enforcement organizations undertaken by suspected China- and India-aligned threat actors between February 2024 and April 2026. “At Balochistan Police, the compromised assets included servers hosting web applications that manage police and citizen data, such as criminal and biometric records,” Aleksandar Milenkoski, principal threat researcher at SentinelOne SentinelLABS, said in a report published this week. The activity targeted network appliances and servers hosting web applications that manage biometric records, hotel and tenant registrations linked to national identity records, criminal case files, and personnel records. The China-nexus threat actor is also said to have compromised one of these web applications to deploy a custom implant masquerading as a portal update.

The application in question, named Complaint Management System (CMS), serves police staff and citizens, thereby putting both categories of users within the attacker’s orbit. SentinelOne said it detected compromised infrastructure associated with several other Pakistani law enforcement organizations, including the Khyber Pakhtunkhwa Police, the Islamabad Police, and the Punjab Safe Cities Authority (PSCA). Four different threat clusters have been flagged, each deploying a unique malware family: PlugX, ShadowPad, Cobalt Strike, and Remcos RAT. The use of Remcos RAT has been linked to an India-nexus threat actor, while the PlugX, ShadowPad, and Cobalt Strike clusters are built on shared or commodity tooling and may each involve more than one operator.

That having said, the deployment of both PlugX and ShadowPad , the latter of which is considered a successor to PlugX, is traditionally associated with Chinese nation-state hacking groups. “The victimology we observed for PlugX (between 27 February and 28 September 2024) and ShadowPad (between 3 August and 1 December 2024) reinforces this assessment,” the cybersecurity company said. “Beyond Pakistani law enforcement, victimology for PlugX and ShadowPad includes government, foreign affairs, defense, nongovernmental, and research entities across South, Southeast, Central, and East Asia, the Arabian Peninsula, and Southeast Europe, consistent with China-aligned collection.” The Remcos-related intrusion set is assessed to share infrastructure and tactical overlaps with a hacking group known as Mysterious Elephant (aka APT-C-08, APT-K-47, and TAG-179), which, in turn, has commonalities with India-nexus adversaries such as SideWinder, Confucius, and Bitter. Attack chains have been found to employ lures related to Pakistani law enforcement, displaying a decoy document that purports to contain an operational plan for the repatriation of illegal foreigners, including Afghan Citizen Card (ACC) holders.

The Cobalt Strike activity cluster’s ties to China-nexus threat actors is based on the fact that traffic to the attacker-controlled command-and-control (C2) server (“142.171.183[.]8”) extends beyond Pakistani law enforcement to government, academic, telecommunications, and non-governmental entities across South, East, and Southeast Asia, the Middle East, and South America – a victimology profile consistent with China-aligned hackers. Among those targeted are Tibetan Buddhist organizations in Taiwan, which have long been targeted by China for cyber espionage . Further examination of the activity aimed at Balochistan Police has uncovered the compromise of the following assets that took place between June 2, 2024, and April 9, 2026 - Two network appliances Web servers hosting several Balochistan Police web applications associated with the Smart Police Station digitalization initiative A Fortinet FortiMail appliance that had served as the agency’s primary inbound email gateway One of the infected applications is the Complaint Management System (“cms.balochistanpolice.gov[.]pk”), which is used for registering, tracking, and resolving citizen complaints. Two distinct variants of an implant called “cms_plugin.exe” have been uploaded to the site in connection with the operation - A Rust stager that’s designed to download an additional payload from “193.42.25[.]65” and execute it.

The exact nature of the next stage is unknown, but the samples display a message “Update Complete! Please refresh the page” upon execution, mimicking a CMS portal update. A .NET executable that masquerades as “ 360Safe.exe ,” a legitimate binary used by Qihoo 360 Total Security, to reflectively load an assembly implementing an AsyncRAT client. The activity is notable because it has drawn both a “partner and an adversary of Pakistan” to the same victim for intelligence gathering, likely fueled by geopolitical motives.

“When multiple cyberespionage actors operate against law enforcement institutions of a single state, the convergence itself is a signal of target value,” Milenkoski explained. “What draws them is a particular kind of institution: one that holds the government’s internal security picture, what it knows about the threats inside its borders, and how it acts against them.” “The compromise of the Complaint Management System web application adds a second dimension to the activity against Balochistan Police, extending the threat actor’s reach beyond the initially compromised environment. By hosting implants in a portal used by both citizens and law enforcement personnel, the threat actor turned a tool built to make policing in Pakistan more accessible and accountable to the public into a malware delivery mechanism.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Critical Zimbra Flaw Could Let Crafted Emails Run Malicious Code in User Sessions

Zimbra is urging customers to apply updates to address a critical security vulnerability impacting the Classic Web Client that could result in arbitrary code execution. The vulnerability has been described as a case of stored cross-site scripting (XSS) that could allow specially crafted emails to execute malicious scripts in a user’s session. It has yet to be assigned a CVE identifier. “The update fixes a security issue in the Classic Web Client where a specially crafted email could run malicious code when the email is opened,” Zimbra said .

“If exploited, it could allow access to mailbox information, session data, or account settings.” XSS vulnerabilities occur when an application includes untrusted data in a web page without proper validation or escaping. This allows attackers to inject and execute malicious JavaScript in victims’ browsers, which can result in session hijacking, credential theft, and account compromise. Stored XSS, or persistent XSS, is a type of XSS flaw where the injected script is permanently stored on the target servers in a database in the form of a seemingly harmless comment or a forum post, causing any site visitor to be compromised as soon as the page containing the JavaScript is loaded on their web browser. Although Zimbra makes no mention of the vulnerability being exploited in the wild, XSS flaws in Zimbra have been an attack magnet for years, with bad actors attempting to weaponize such vulnerabilities as far back as December 2021.

Last October, a stored XSS flaw in the Classic Web Client ( CVE-2025-27915 , CVSS Score: 5.4) was alleged to have been exploited as a zero-day in attacks targeting the Brazilian military, although Zimbra told The Hacker News at the time that it found no evidence to back it up. Other XSS flaws that have been exploited by threat actors include CVE-2023-37580 and CVE-2024-27443 . Given its high potential for abuse, users are recommended to update to Zimbra Collaboration Suite version 10.1.19 for optimal protection. Found this article interesting?

Take the AI Sprawl CISO Survey. Get fast track to BlackHat swag

URGENT - Progress Tells ShareFile Customers to Shut Down Storage Zone Controllers Over Security Threat

Progress Software has told ShareFile customers to shut down the Windows servers running their Storage Zone Controllers, confirming to The Hacker News that it is responding to a “credible external security threat.” The company has temporarily disabled access to the affected accounts, a step it says it took “out of an abundance of caution” while it works with internal and external security experts. It says it has no indication of unauthorized access to any ShareFile accounts or data, and that it notified customers after learning of the threat. What Progress has not said is what the threat is or who is behind it. The order became public when a customer posted the company’s email to Reddit’s r/sysadmin on July 10.

Progress confirmed the disruption on its status page, listing Storage Zone Controller customers as “not operational” and the incident as under investigation as of a 12:12 p.m. EDT update. Only the Storage Zone Controller is affected, not standard cloud-only ShareFile accounts. The controller is a server that a company runs itself, so files can stay on its own storage while it still uses ShareFile’s cloud to share and manage them.

The controller usually sits at the network’s edge, reachable from the internet. That exposure makes it both useful and a target. Ordering customers to take it fully offline, rather than just patch it, is a notable step. That choice is itself a tell.

If a fix for this threat existed, Progress would be telling customers to apply it; the shutdown order suggests there is none yet. That usually means a newly found flaw the company is racing to close, though the same step would also fit a threat a patch cannot address, such as stolen keys or a problem on Progress’s own side. Its statement that no accounts or data were accessed is careful wording, too, and does not rule out trouble on the controllers themselves. What to do now Follow the shutdown order first.

Keep the affected controllers offline until Progress says what the threat is and when it is safe to restart. Separately, confirm your version is current: 5.12.4 or later on the 5.x line, or a 6.x release. That closes the flaws fixed earlier this year, but Progress has not said it clears the current threat, so do not treat it as permission to restart. If a controller is reachable from the internet, handle it as a possible incident.

Preserve the logs and start your incident-response process, then check for unfamiliar .aspx files in the web folders and storage paths you did not set. A clean-looking server is not proof that it is clean. ShareFile has faced this before. In 2023, while the product still belonged to Citrix, attackers exploited an unauthenticated flaw in the same Storage Zones Controller (CVE-2023-24489).

CISA flagged it as actively exploited , and Citrix cut unpatched controllers off from the ShareFile cloud, the same access block Progress has now imposed. Progress, which acquired ShareFile in 2024, had already weathered a mass file-transfer attack of its own: MOVEit, whose 2023 zero-day was exploited by the Clop group and hit more than 2,700 organizations. The Storage Zones Controller also had two critical flaws that watchTowr disclosed in April and Progress patched in March, though the company has not connected the current threat to them, and neither has been reported as exploited. The central question is still unanswered: Progress has pulled these systems offline and is working with outside experts, but has not said what the threat is or when customers can safely bring them back online.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Injective Labs GitHub Compromise Pushes Wallet-Key-Stealing npm Packages

Unknown threat actors compromised the Injective Labs SDK project’s GitHub repository and leveraged it to publish a malicious package on the npm registry to steal cryptocurrency wallet private keys and mnemonic seed phrases. The compromised version, @injectivelabs/sdk-ts@1.20.21 , came embedded with fake telemetry functionality that exfiltrated data from cryptocurrency wallets. The version was released on July 8, 2026, but has since been deprecated on the registry. That said, the release artifacts belonging to the compromised version are still available for download from GitHub as of writing.

“The malicious functionality was introduced to the project’s official GitHub repository through commits submitted by a GitHub account belonging to a developer with an established history of contributions to the repository,” Socket said . The software supply chain security firm said the threat actor behind the attack also published version 1.20.21 across 17 additional @injectivelabs scoped packages that depended on and pinned the malicious SDK version, thereby putting transitive users who may not have installed the library directly. This includes - @injectivelabs/utils @injectivelabs/networks @injectivelabs/ts-types @injectivelabs/exceptions @injectivelabs/wallet-base @injectivelabs/wallet-core @injectivelabs/wallet-cosmos @injectivelabs/wallet-private-key @injectivelabs/wallet-evm @injectivelabs/wallet-trezor @injectivelabs/wallet-cosmostation @injectivelabs/wallet-ledger @injectivelabs/wallet-wallet-connect @injectivelabs/wallet-magic @injectivelabs/wallet-strategy @injectivelabs/wallet-turnkey @injectivelabs/wallet-cosmos-strategy The malware present within the package is fairly simple and straightforward, which gets triggered when the library functionality is used by an unsuspecting developer. By avoiding lifecycle scripts and not launching it during the installation phase, it helps the malware fly under the radar.

Specifically, the poisoned version has been found to modify legitimate functions used in workflows to generate private keys by invoking a “trackKeyDerivation()” function under the guise of collecting anonymized usage metrics for SDK optimization. “Tracks which key derivation methods are used (hex vs mnemonic) and derives timing patterns to help the SDK team identify performance bottlenecks and understand adoption of different key formats across the ecosystem,” reads the description of the supposed telemetry function. “All metrics are fire-and-forget and never block or affect key derivation.” According to Socket, parameters passed to the function include a hard-coded marker describing the method used to generate the private key and the actual sensitive information needed for generating the private key. The captured material is enough for the threat actor to regenerate the private key at their end.

“The malware adds crypto wallet stealing logic to a crypto wallet package, every time a legitimate user creates or uses the logic that reads mnemonic phrases – which are basically the master key for any crypto wallet, the malware reads them and sends them to the remote server,” OX Security said . In an attempt to reduce the number of outbound requests, the exfiltration mechanism is designed to append multiple key derivations over a two-second window into a single queue and then send them in the form of an HTTPS POST request to an external server (“testnet.archival.chain.grpc-web.injective[.]network”) in a single beacon. StepSecurity noted the malicious release was facilitated through the repository’s own trusted-publisher (OIDC) pipeline, adding that the malicious commits were authored and pushed under the identity of an existing, trusted maintainer (“thomasRalee”). Users who have installed the malicious version are recommended to update to the newly published, clean version of the package (1.20.23), treat any private key or mnemonic phrase passed through the package as compromised and rotate them, and check for transitive dependencies.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Six New U-Boot Flaws Could Let Malicious Images Crash Devices or Run Code at Boot

Researchers at firmware security firm Binarly have found six new flaws in U-Boot, the small program that starts up hardware as varied as home routers, smart cameras, and the management chips inside data-center servers. Four of the bugs can crash a device. The other two could let an attacker who slips a malicious image in front of the bootloader run their own code, before the device has confirmed that the software is genuine. That last part is the point.

A bootloader runs before the operating system, so a flaw here can undermine everything that loads after it. All six bugs are reached while U-Boot is still reading an untrusted image, before it has checked the signature. What Binarly found U-Boot can bundle a kernel, device tree, ramdisk, and other boot components into one package, a FIT (Flattened Image Tree), and it checks that package’s digital signature before handing over control. Binarly went looking for weak spots in that check and found six.

Most of the vulnerable code has been in U-Boot since v2013.07, Binarly says , across more than 50 stable releases, and it also lives in the many vendor firmwares built on top of U-Boot. The bugs are tracked as Binarly advisories BRLY-2026-037 through BRLY-2026-042 . No CVE identifiers have been assigned yet. They fall into two groups: two that could run code, and four that only crash.

The two are BRLY-2026-037 and BRLY-2026-038, and both trace to one unchecked value. U-Boot calls fdt_get_name, a lookup in the device-tree parsing library it borrows, and on a malformed image, that lookup returns a null pointer and a negative length. U-Boot uses both without checking either. One bug follows the null pointer into a memory copy that, on devices where address zero is mapped, becomes a stack buffer overflow.

The other feeds the negative length into pointer arithmetic that walks backward until it overwrites a saved return address. In the right memory layout, either one can hand control to code the attacker-supplied. The other four only crash the bootloader. BRLY-2026-039 and BRLY-2026-041 read past the end of the image by trusting a size or offset that the attacker controls.

BRLY-2026-040 dereferences a null pointer that an older image format hands back unchecked. BRLY-2026-042 exhausts the stack, set off by a deeply nested image that drives an early validation step to call itself until it runs out. Binarly published a proof-of-concept image and reproduction steps for each flaw and demonstrated them against standard U-Boot builds. No exploitation in real attacks has been reported.

Of the six, the two memory-corruption bugs are the ones to prioritize: a crash can knock a device offline, but code execution at boot could subvert its entire chain of trust. How bad it gets In the worst case, recovering a device that will not boot means physical access and reflashing its memory chip with a clean image. Code execution is worse. Code that runs this early sits below the operating system, where ordinary security tools may not see it.

The catch for an attacker is delivery: these bugs only bite once a malicious image reaches the boot path, which usually takes physical access or a privileged foothold. That foothold is not always local. In earlier work on Supermicro’s server management controllers, the same Binarly researcher showed that an attacker with remote access to the management interface could abuse the device’s own update process to flash a malicious image, without touching the hardware. What to do There is no stable release with the fix yet, so vendors and maintainers of U-Boot-based products should not wait: pull the upstream fixes now, following the commit links in each Binarly advisory, and track them by advisory ID, since no CVEs exist.

U-Boot merged the six patches in June, but the July release (v2026.07) had already frozen in April, so it shipped without them; the next release, v2026.10, is not due until October. Everyone else runs a device someone else built on U-Boot. For them, the fix has to arrive as a firmware update from the product vendor. That is what to watch for.

This exact check has failed before. The same signature logic was hit months earlier by CVE-2026-33243 , which U-Boot patched in April; the related barebox bootloader, which uses the same image tooling, was hit too. In that bug, a property meant only to list what the signature covers was not itself signed, so a tampered image could swap in parts that were never verified. The helper behind the two worst bugs here, fdt_get_name, comes from libfdt, the flattened-device-tree library U-Boot shares with the Linux kernel, barebox, and others.

The same unchecked-return mistake can surface anywhere that code is used. LogoFAIL , which THN covered in 2023, was a set of image-parsing bugs in PC firmware that let attacker code run during boot, before Secure Boot could check anything, across nearly every major PC brand. The signature gets all the attention; the bugs keep landing in the plumbing that runs before it. And as BootHole showed in 2020, when one bootloader flaw broke Secure Boot across the ecosystem, writing the patch is the easy part.

The slow part is getting it onto the millions of devices running someone else’s copy of U-Boot. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Laser Attack Resets Tangem Wallet Passwords on Cards That Can’t Be Patched

Researchers at Ledger’s Donjon security team have shown that a precisely timed laser pulse, aimed at the chip inside a Tangem crypto wallet card, can reset the card’s password to anything the attacker picks. No old password. No backup card. Once it is reset, whoever did it controls the wallet and can move the coins out.

This is not an emergency for most owners. The attack needs the physical card in hand and a lab that Donjon puts at around $250,000. It also means cutting the card open, which leaves damage no one can miss. It cannot be done over the internet, and there is no fix coming: Tangem cards cannot take software updates, so every card already sold carries the flaw.

The one group that should act now is anyone whose card is lost or stolen and holds serious value. How the card is meant to protect you A Tangem wallet looks like a plain bank card. Tap it to your phone, and a companion app talks to a Samsung S3D232A chip inside. That chip is a secure element, built to resist tampering and certified to a high grade called EAL6+.

It holds the secret key that controls your crypto and never lets it out. Two things are meant to stand between a thief and your money: holding the card and knowing the password. The weak point is the password reset feature. Tangem sells its cards in linked sets, and if you forget your password, you can set a new one by holding two of your cards together.

Deep inside that process, the card runs a single check: is this card in recovery mode? If yes, it accepts a new password without asking for the old one. A laser pulse fired at the chip at the exact moment it runs that check does not quietly rewrite a stored value. It briefly disturbs the chip’s own circuitry, so the check misfires and the card behaves as if it were in recovery mode when it is not.

With the check defeated, the card’s ordinary SetPin command accepts a brand-new password: no old password, no second card, no recovery step. Turning the recovery feature off does not help, because the same check still runs on every card. Hard to do, and unfixable None of this is easy. It took a laser rig, sensitive measuring gear, deep hardware skill, and a long stretch of up-front work to map the chip and find the exact spot and timing.

The card has to be cut open and its chip exposed, which leaves obvious damage. There is no doing this quietly and slipping the card back into a pocket. Donjon reports that once the settings were locked in, the attack worked on every card it tried, at about two hours each. The team reported the flaw to Tangem on February 10, 2026.

The bigger problem is permanence. Tangem builds its cards with no way to update the firmware, and presents that as a security feature: nothing can be changed, so nothing can be tampered with from a distance. Here, that same design cuts the other way, leaving a flaw in the code that can never be corrected. As the researchers put it, ”there’s no patch, but the attack is physical and invasive”, so it cannot be done remotely.

What Tangem says Tangem pushed back. In a public response , the company called this a lab-only physical method that works against secure element chips in general, not something unique to its cards. It also noted that Donjon belongs to Ledger , one of its biggest rivals. Its sharpest point is about money: a Tangem card carries nothing that says who owns it or how much it holds, so an attacker who spends $250,000 and wrecks cards to tune the attack has no way to tell whether a stolen card is worth $50 or $50 million.

Tangem also says no one has lost funds to a laser attack on any hardware wallet so far, and that for everyday users, “the practical risk is virtually non-existent.” Both sides are partly right. Donjon researchers are right that the flaw is real, sits in every card, and can never be patched. Tangem is right that for almost everyone, the cost, the ruined cards, and the guesswork over what a card holds make it pointless. The place they actually meet is narrow: a lost, stolen, or seized card that an attacker already has reason to think is worth the trouble.

Not the first wallet chip broken this way This is not Donjon’s only laser attack on a hardware wallet this year. In early June, Trezor and its chip partner Tropic Square disclosed a related result: Donjon used the same technique, laser fault injection, on the TROPIC01 chip in the new Trezor Safe 7. This time, it slipped past the chip’s firmware signature check to run its own code. Trezor said funds stayed safe because the Safe 7 stacks three separate security layers, and the layer guarding the PIN held firm.

Unlike Tangem, Trezor, and Tropic Square, which could respond: they shipped a stopgap for current chips and are hardening the next version of the silicon. Cheaper attacks on wallets go back further, but they hit softer targets. Years ago, this same team pulled the recovery seed straight off a stolen Trezor One or Trezor T with a rig costing about $100, because those wallets guarded their secrets with an ordinary microcontroller and no secure element. Tangem’s hardened chip is the difference: it is why the same sort of physical attack now needs a quarter-million-dollar lab.

It raises the bar; this research shows it does not remove the danger. And a grade like EAL6+ only vouches for the chip and its built-in defenses, not the code a wallet maker layers on top, which is where this flaw lives. It is also Donjon’s third finding on Tangem. An Android app bypass could be patched, because it was in the software Tangem controls.

But this laser attack and a password brute-force method found earlier both sit in the card’s firmware, which can never be changed. What to do For almost everyone, the answer is nothing new: keep the card where a thief cannot get to it. This attack cannot reach a card you still hold. If a Tangem card is lost or stolen and you are guarding serious value, move the funds now, using another card in your set (or a seed phrase, if you set one up), and stop relying on the password to protect a card you no longer control.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Researcher Details WhatsApp-to-Host Attack Chain Using Three OpenClaw Flaws

Details have emerged about three now-patched security flaws in the OpenClaw personal artificial intelligence (AI) assistant that, if successfully exploited, could enable credential theft, privilege escalation, and arbitrary code execution on the host. A brief description of the high-severity vulnerabilities is as follows - GHSA-hjr6-g723-hmfm (CVSS score: 8.8) - An operating system command injection and an incomplete list of disallowed inputs vulnerability impacting the host execution environment filtering mechanism that could allow for executing or persist actions beyond the caller’s intended authorization. GHSA-9969-8g9h-rxwm (CVSS score: 8.8) - An operating system command injection and an incomplete list of disallowed inputs vulnerability impacting the host execution environment filtering mechanism that could allow for executing or persist actions beyond the caller’s intended authorization. GHSA-575v-8hfq-m3mc (CVSS score: 8.4) - A path traversal and link following vulnerability that could allow sandbox bind mounts to bypass parent-directory denylist checks and perform actions that should have been secured with stronger authorization or policy checks.

All three shortcomings have been addressed in OpenClaw version 2026.6.6. In a series of advisories released last week, OpenClaw maintainers said “practical impact depends on the operator’s configuration and whether lower-trust input can reach that path.” However, security researcher Chinmohan Nayak, who is credited with discovering and reporting the issues, said in a report shared with The Hacker News that they can be used to trigger host code execution from an external message sent via WhatsApp. Unlike the Claw Chain vulnerabilities disclosed by Cyera back in May, the newly identified bugs do not require an attacker to establish a prior foothold in order to extract sensitive data, drop a persistent backdoor, obtain arbitrary remote code execution, and facilitate an escape to the host. “getBlockedReasonForSourcePath() checks if the source path is under a blocked path,” the researcher explained about GHSA-575v-8hfq-m3mc.

“But [it] never checks the reverse — whether a blocked path is under the source (parent directory bypass).” Specifically, the bind mount denylist blocks directories like “~/.ssh,” “~/.aws,” and “~/.gnupg,” but allows mounting the parent directory “/home” or “/var,” effectively undermining the individual blocks. “Mount /home into your container, and you can read every user’s SSH keys, AWS credentials, and GPG secrets,” Nayak said. “Mount /var and you get the Docker socket – which means full host escape from inside the ‘sandbox.’” Besides updating OpenClaw to the latest version, it’s advised to enable sandbox mode for all non-main sessions, remove “exec” from the tool allowlist for channel-facing agents, and monitor for git clone commands containing the “ext::” external protocol helper that could be abused to run arbitrary system commands. “Before upgrading, restrict the affected feature to trusted operators or disable it when it is not needed,” OpenClaw said.

“As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.” Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

New MODBEACON RAT Uses gRPC Streaming for Encrypted C2 Traffic

The China-linked cybercrime group known as Silver Fox has been attributed to a new Rust-based remote access trojan (RAR) called MODBEACON . Chinese cybersecurity company QiAnXin said that while the threat cluster may appear like a low-sophistication, high-activity operation that propagates malware via counterfeit installers using SEO poisoning techniques, it belies their true organizational structure , which compromises multiple distributors. “These distributors conduct activities across Asia using counterfeit software installers distributed through SEO campaigns, leveraging variants of Gh0st RAT and WinOS (ValleyRAT) trojan families,” QiAnXin said . One such campaign observed in mid-June 2026 involved a distributor delivering a previously undocumented modular RAT targeting technology, education, and state-owned enterprises in the country.

MODBEACON’s requested command-and-control (C2) infrastructure is hosted on Amazon and Cloudflare’s Content Delivery Network (CDN). The distributor is assessed to be a hybrid threat actor, acting as a composite of “cybercriminal arms dealer” and “traffic broker.” One arm of its operations involves expanding its infection footprint across Asia through daily SEO operations for fraud business, while the other focuses on propagating advanced trojans, or renting high-value access to downstream customers, or establishing “criminal-on-criminal” schemes targeting the Cambodian gambling sector. The newly discovered campaign combines social engineering, custom malware, and post-compromise tooling to establish long-term access while minimizing detection on infected hosts. The memory-resident malware functions as a remote implant capable of fetching additional modules, running operator commands, and maintaining encrypted communications with attacker infrastructure.

“The Trojan is a professional and private C2 framework: the loader and beacon are separated, the configuration is injectable, the beacon employs a plugin-based architecture (native-v3 plugins with entry/init/fini RVA), and it uses gRPC tunnel streaming for communication,” QiAnXin explained. “The overall engineering quality is high. Its core highlight is the reuse of the transport layer from an open-source anti-censorship proxy framework (Xray/V2Ray) as its C2 channel.” Like previous campaigns attributed to the Silver Fox intrusion ecosystem, the attack chain uses counterfeit domains advertising bogus installers for popular domestic software as lures to trick unsuspecting users into downloading malicious ZIP archives responsible for deploying the malware. The core capabilities of MODBEACON include - Fingerprinting the host Loading plugins in memory Sending heartbeat messages Reporting the results of command execution Setting persistence using scheduled tasks “This capability can be used for subsequent on-demand expansion of information theft, lateral movement, proxy forwarding, or other payloads,” QiAnXin said.

The disclosure comes amid a gradual broadening of Silver Fox’s arsenal, which has deployed malware families tracked as Atlas RAT , ABCDoor , RomulusLoader, and SilentRunLoader , indicating that the threat actor is actively refining its tradecraft. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Unpatched XRING Flaw in XQUIC Lets Remote Clients Crash HTTP/3 Servers

A single wrong variable on one line in XQUIC, Alibaba’s QUIC and HTTP/3 library, lets any remote client crash the server with a short burst of completely legal traffic. There is no patch. FoxIO researcher Sébastien Féry disclosed the flaw on July 8 and nicknamed it XRING. He says it needs no login and no malformed packets: about 260 bytes of ordinary QPACK traffic takes the server process down.

XQUIC is open-source, so the risk is not Alibaba’s alone: any server that embeds it and serves HTTP/3 with the default QPACK settings is exposed. That includes Tengine, Alibaba’s Nginx-based web server, which FoxIO says fronts the company’s cloud and CDN on sites including Taobao and Alipay. Every release through v1.9.4, the latest, is affected. There is no fixed release and no CVE as of July 10.

Until a fix ships, operators can set SETTINGS_QPACK_MAX_TABLE_CAPACITY to 0, which turns off QPACK’s dynamic table, or drop HTTP/3 support entirely. The bug lives in how HTTP/3 compresses headers. To avoid sending the same header (say, user-agent) over and over, HTTP/3 uses QPACK. It keeps a shared table that the client directs the server to build up and resize through a dedicated control channel, the encoder stream.

XQUIC stores that table’s bytes in a ring buffer , a fixed block of memory where data wraps from the end back to the start once it fills. When the client asks to grow the table, XQUIC allocates a bigger buffer and copies the old data across. That copy has four cases, depending on whether the data wraps in the old buffer, the new one, both, or neither. In one of them, the code sizes the leftover tail data against the new, larger buffer’s capacity instead of the old one’s.

It overcounts badly. Grow a 64-byte table with the write cursor near the end, and resize to 65, and XQUIC decides there are 70 tail bytes to move when there are really 6. That wrong number flows into a memory copy. The copy length comes from subtracting the overcount from a smaller value.

Because that length is an unsigned size_t, it underflows and wraps to a near-maximum number, and the copy runs off the end of memory. In FoxIO’s release build on Ubuntu 26.04, glibc’s _FORTIFY_SOURCE=2 caught the bad length and killed the process. Without that check, the copy writes out of bounds, from the old buffer past the end of the new one. Féry showed a crash but did not test whether that corruption could be exploited further.

None of the values in the attack breaks QPACK’s rules. XQUIC advertises a 16 KiB dynamic-table limit by default; the payload asks for 64 bytes, then 65. The client only has to drive the table into the exact wrapped layout that hits the faulty branch. FoxIO says the mistake has been in XQUIC since its first public release in January 2022, and a proof of concept is public .

XRING is the latest in a string of remote crashes in HTTP/2 and HTTP/3 stacks. Three weeks earlier, THN reported a use-after-free in NGINX’s HTTP/3 module (CVE-2026-42530) that a remote, unauthenticated client could reach through the same QPACK encoder stream XRING abuses, a different bug class on the same attack surface. In June, Calif’s HTTP/2 Bomb caused remote denial of service against Nginx, Apache, IIS, and Envoy by abusing HPACK, HTTP/2’s header compression, and the predecessor to QPACK. In February, HAProxy patched two QUIC crashes , one an integer underflow during token validation, the same type of bug behind XRING, though it needed a malformed packet where XRING needs none.

That difference is the point: legal input, one arithmetic slip, a dead server. FoxIO demonstrated a crash, not code execution, and reported no exploitation in the wild. It says it emailed Alibaba on April 7 through the project’s security policy, which promises a reply within three working days, then followed up four more times through May 9 without an answer before going public. The Hacker News has asked Alibaba whether a fix and a CVE are coming, and whether FoxIO’s five disclosure attempts reached its security team.

It has asked FoxIO whether the flaw has been exploited in the wild and whether the underlying heap write can be pushed past a crash. The story will be updated with any response. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

From 17,000 to 1.1 Million Assets: How Lumen Technologies Rebuilt Exposure Management at Scale

Most enterprises assume their asset inventory is close enough to accurate. The evidence suggests otherwise. According to a survey of over 600 security leaders in the 2026 Axonius Actionability Report, only 45% of organizations consolidate their asset and exposure data into a single view, and every downstream security program inherits whatever the inventory gets wrong. Lumen Technologies , a telecommunications company with nearly a century of history, put this to the test.

Geoff Krahn, Director of Product and Platform Security at Lumen, and his team used the Axonius asset intelligence platform to reconcile data from more than 40 disconnected systems into one trusted view. They uncovered 60 times more devices than they knew they had, then rebuilt their exposure management program on that foundation. Why asset inventories break down at enterprise scale Lumen’s environment is an extreme case of a problem most security teams recognize. More than 40 independent IT and security tools tracked different slices of reality at different levels of maturity, none agreeing on device counts, ownership, or coverage status.

When leadership asked what percentage of servers had EDR, answering meant pulling from sources that contradicted each other. “We were constantly in incident response calls with no idea who owned what,” Krahn said. Axonius gave the team a way to reconcile all of those sources into one model. The scope turned out to be far larger than anyone expected: Starting point: ~17,000 known cyber assets across existing inventories After initial reconciliation: 500,000 devices identified and categorized Current scope: Approximately 1.1 million devices “It has really been an eye-opener for the organization as a whole how large our responsibilities are,” Krahn said.

“Being able to quantify it and highlight gaps in controls has allowed us to gain the leadership support and funding we need.” What trusted asset data makes possible Zero-day response When a critical vulnerability drops, speed depends on knowing what’s exposed and who owns it. Krahn’s team can now identify affected systems, confirm whether they’re externally exposed, and establish ownership within minutes, then push alerts to engineers through a chatbot built on top of Axonius. “Being able to get near-instantaneous information on how many assets are susceptible to a 0-day vuln, who owns them, are they externally exposed… is pivotal to timely response and communication,” Krahn said.

Application posture visibility Lumen runs thousands of internal applications. Knowing whether a server is patched doesn’t answer what it supports, who owns the application on it, or what revenue stream a compromise would put at risk. By correlating CMDB relationships with control coverage, vulnerability data, and end-of-life status, Lumen built an Application Posture Dashboard within Axonius that evaluates risk at the application level rather than the infrastructure level alone. Krahn plans to connect this directly to the products Lumen sells, tying cybersecurity exposure to revenue.

How risk-based exposure management replaces “scan and spam” Without reliable asset context, most teams default to sorting by CVSS score and working top-down. The Actionability Report found that 56% of organizations still rely primarily on CVSS for prioritization, despite broad agreement that exploitability, blast radius, and business impact should drive those decisions. Critical issues end up buried behind thousands of medium-severity findings that pose no environment-specific risk. Krahn describes the old model bluntly: “scan and spam.” Scan everything, dump the results, hope the right things get fixed first.

With trusted asset data in place, Lumen took a different path. Axonius Exposures allowed the team to combine technical findings with asset context, business criticality, and control coverage to surface which remediations deliver the greatest risk reduction. “Exposure management will allow us to evolve vulnerability management beyond scan and spam to intelligent risk-based requests driven by remediation actions that will deliver the most risk reduction,” Krahn said. Better asset data enables smarter exposure management, and exposure management outcomes reveal where asset data still needs to improve.

What happened when Lumen’s leadership trusted the data Trusted, quantified visibility changed what leadership was willing to decide: Cloud migration: End-of-life visibility drove Lumen’s decision to migrate the majority of its infrastructure to the cloud 10x security investment: Spending grew to roughly 10 times its previous level as leadership saw the full scope in terms they could act on Board-level reporting: Lumen’s board now relies on Axonius-generated reports for asset coverage, EDR deployment, and compliance insights “The visibility Axonius was able to shed on the end-of-life issues we had with our systems directly contributed to the decision to migrate the majority of our infrastructure to the cloud, reducing overall risk by 40%,” Krahn said. Is your asset data carrying the same gaps? If an organization with dedicated security leadership and 40-plus inventory systems found its cyber asset management picture was off by a factor of 60, most enterprises should assume their own data carries similar gaps. Every exposure management program inherits the quality of the asset data underneath it.

If that foundation hasn’t been tested, the prioritization, ownership mapping, and remediation workflows built on top of it are working from assumptions, not evidence. Learn more about Axonius Exposures and risk-based exposure management at enterprise scale. Found this article interesting? This article is a contributed piece from one of our valued partners.

Exposed Hacker Server Reveals WP-SHELLSTORM Backdooring Thousands of WordPress Sites

A cybercrime crew left one of its own servers wide open on the internet for three weeks, and it exposed the operation’s inner workings: the hacking tools, the activity logs, and target lists naming more than 1.4 million websites. Far fewer were actually broken into, but the exposed files showed researchers how a mass site-hacking operation runs from the inside. The operation, now tracked as WP-SHELLSTORM , is what SOCRadar calls a webshell access brokerage: a crew that breaks into sites at scale, plants a hidden backdoor (a “webshell”) on each, and packages that access for resale. The strongest activity hit WordPress sites running out-of-date plugins.

If you run WordPress or Joomla, the two flaws that mattered most were in the Breeze caching plugin and Joomla’s JCE editor; skip to the checklist below if that’s you. A forgotten server Two teams dug into the same exposed folder. SOCRadar’s threat intelligence team spotted it on June 11, 2026, on a US-based rented server at 137.175.93[.]126 with no password on it at all. Inside was roughly 800MB across 434 files: webshells, exploit scripts, scan results, the operator’s typed command history, and command-and-control settings.

Ctrl-Alt-Intel had analyzed the same directory too, having found it on Hunt.io’s open-directory platform, and published on June 22, weeks before SOCRadar’s own July 9 writeup. The exposure came down to a basic slip: the operator started a simple Python web server to move files around and left it running for 22 days. The crew took publicly known bugs in website plugins, most of them in WordPress, and built automated scanners to fire those exploits at massive target lists pulled from FOFA, a Chinese search engine for internet-connected systems, similar to Shodan. Where a site ran a vulnerable version, the exploit could upload a webshell: a small script that lets the attacker run commands on the server from anywhere, read files, steal passwords, and move deeper into the network.

The toolkit covered 27 known flaws, though a handful did most of the work. The biggest producer was a bug in the Breeze caching plugin (CVE-2026-3844), which the crew fired at more than 45,000 targets and, by its own count, backdoored over 17,000 of them. That one comes with a catch: it only works when a non-default “Host Files Locally – Gravatars” setting is switched on, so most Breeze installs were never exposed. The numbers, in plain terms The headline figure needs a caveat.

The 1.4 million count is how many domains were on the target lists, not how many were broken into, and those lists spanned WordPress, Joomla, and other platforms. The single largest file was a list of 587,034 Joomla targets. The number actually compromised was far smaller, and the two research teams measured it differently: Ctrl-Alt-Intel’s deduplicated count found 25,195 sites with confirmed or validated compromise evidence, while SOCRadar, counting active webshells, put the live figure at 5,700-plus. One flaw shows the gap plainly: a Joomla bug was fired at more than 560,000 targets but landed on only 77 of them.

Being on someone’s scan list is not the same as being hacked. Keep that in mind whenever a report leads with a frightening target number. The tooling and an earlier campaign The main backdoor, a file named down.php, was heavily obfuscated, four layers deep, and appears to be derived from an open-source Chinese webshell called BestShell. Once running, it could manage files, run commands, open reverse shells, scan the network, and check which security software the host was running.

For its own remote access, the crew used a SNOWLIGHT dropper to install VShell, a stealthy backdoor that disguises its process name as [kworker/0:2] to blend in with the kernel threads in a process list. Those two tools have a history: in April 2025, Sysdig linked this SNOWLIGHT-to-VShell chain to the suspected Chinese state group UNC5174, activity THN covered at the time . VShell itself, though, is a common tool in Chinese-speaking criminal circles, so its presence alone doesn’t point to a state actor. The server also held traces of an earlier, very different job.

SOCRadar found that before the noisy WordPress spree, the same crew ran a quieter campaign in early May 2026 against corporate Java systems. It pulled 613 configuration files from 11 systems across nine companies in fintech, e-commerce, logistics, gaming, and electronics. The haul included cloud login keys for AWS, Alibaba Cloud, Oracle, Tencent, and DigitalOcean, database passwords, and Alipay RSA private keys. It leaned on an old, well-known bug in Nacos, a configuration server ( CVE-2021-29441 ), that lets an attacker skip the login by faking a single web header.

SOCRadar reads the timing as a sequence: grab high-value corporate credentials first, then pivot weeks later to the higher-volume backdoor work, a funding round before scaling up. Sloppy tradecraft Both teams assess with medium-to-high confidence that the operator is Chinese or Chinese-speaking. They point to the fluent Simplified Chinese throughout the code and command history, the reliance on FOFA (which the researchers note needs a Chinese phone number to register), and the Godzilla and VShell tooling favored in Chinese-speaking forums. SOCRadar goes a step further, reading the crew as financially motivated rather than state-directed.

Names in the files (tance, chen-kk, chenyk) are treated as loose leads, not proof. One loose end stands out: a single IP address in Taiwan made more than 42,000 requests downloading the crew’s own tools. It could be a second operator, a customer, or another researcher. The logs cannot settle it.

For a group running a genuinely capable toolchain, the crew was careless. It left the server open, left a FOFA config file that FOFA can trace through its law-enforcement channel, and left an unedited command history that laid the whole thing out. When it finally noticed it had been spotted, sometime between July 2 and July 4, it deleted a batch of log lines. Three weeks too late.

The blunder is a familiar one. In March 2026, the same research shop caught Russia’s Fancy Bear (APT28) the same way: a forgotten open directory spilled the group’s phishing tools and logs, in a campaign Hunt.io called Operation Roundish . What to do now If you run any of the targeted software, check it today. These are not obscure bugs: two of them are under active exploitation elsewhere.

Wordfence tracked tens of thousands of blocked attacks against the Everest Forms Pro flaw (CVE-2026-3300) this spring, and the Joomla JCE bug (CVE-2026-48907) is a maximum-severity flaw CISA has added to its Known Exploited Vulnerabilities list . WordPress and Joomla, first: patch Breeze (CVE-2026-3844, fixed in 2.4.5) if the non-default “Host Files Locally – Gravatars” setting is on; it produced the most backdoors here. Treat the Joomla JCE flaw (CVE-2026-48907, fixed in 2.9.99.5) as urgent too, since it is a maximum-severity and on CISA’s actively-exploited list, even though it barely landed in this campaign. WordPress and Joomla, also check: ThemeREX Addons (CVE-2026-1969), Simple File List (CVE-2020-36847), Custom CSS JS PHP (CVE-2026-6433), BerqWP (CVE-2025-7443), Ninja Forms uploads (CVE-2026-0740), WavePlayer (CVE-2025-12057), WPBookit (CVE-2025-7852), and WP File Manager (CVE-2020-25213).

Both reports list Simple File List under CVE-2025-34085, a now-rejected duplicate; the valid ID is CVE-2020-36847. Nacos: upgrade to 2.2.1 or later and turn authentication on (nacos.core.auth.enabled=true). If your instance was ever exposed, rotate every credential that lived in it, not just the obvious ones. XXL-Job and Spring Boot: close unauthenticated executor endpoints and disable /actuator/heapdump in production.

Hunt for the backdoors: search for the crew’s webshell filename patterns, such as .bd.php, .wp-log.php, and .brq-*.php. Then check any process named [kworker/X:Y]. A real kernel thread runs no program of its own, so its /proc//exe points to nothing. It also has no command line and no network sockets.

A [kworker] that shows any of these is an impostor. Block the known infrastructure: 137.175.93[.]126, 43.108.17[.]80, and the domain xs.xxooonline[.]eu[.]cc. What makes WP-SHELLSTORM worth attention is not how advanced it is, but how ordinary. Public exploits, automated scanning, and a target list a million lines long were enough to compromise sites at scale, no zero-day required.

The details are public only because the crew forgot to close its own server. The Hacker News has reached out to SOCRadar for further details on their findings and will update this story with any response. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Study of 281 Free Android VPN Apps Finds Traffic Leaks, Unencrypted Data, and Tracking

Researchers ran 281 of the most popular free VPN apps on the Google Play Store through a new testing system and found that many fail at the basics people install a VPN for, i.e., keeping their traffic private and secure. The apps flagged with at least one problem have been installed more than 2.4 billion times. The problems are basic, not sophisticated. 29 apps let user traffic leak outside the encrypted tunnel, including the DNS lookups that reveal which websites you visit.

61 apps send some data in plain text that anyone watching the traffic on that network can read. Five of those send the app’s configuration file in the clear, which lets an attacker on the network redirect the connection to a server they control. The system, called MVPNalyzer , was presented at the NDSS security conference in February 2026 by researchers at the University of Michigan, the University of New Mexico, and IIT Delhi. It is a mobile counterpart to the same lab’s earlier VPNalyzer study of desktop VPN software, and the researchers describe it as the first framework built to systematically and repeatedly audit Android VPN apps.

A VPN wraps your traffic in an encrypted tunnel so your internet provider, or an eavesdropper on the network, cannot see what you are doing. The trade-off is that the VPN app now sees all of it. You are not removing the need to trust someone. You are moving that trust from your internet provider to whoever built the app.

The study asks whether these apps earn it. For many, they do not. The most serious flaw: tunnel hijacking The worst finding involves those five apps that download their configuration file without encryption. That file tells the app which server to connect to.

If it travels in plain text, an attacker on the same network, say a public Wi-Fi operator, can rewrite it in transit and point the app at a server they control. Architecture of the MVPNalyzer framework The user connects, sees the usual “connected” screen, and routes everything through the attacker. The researchers built this attack and confirmed it worked on phones under their control. They flagged the issue for all five providers as a priority.

Two responded, both promising to move the file to HTTPS. One said it would send the configuration files “securely using HTTPS with proper certificate validation.” The other three had not acknowledged it. Leaks, and apps that hide nothing Of the 29, 24 leaked DNS traffic, exposing the sites users visited to the local network; those apps alone account for about 360 million installs. Six leaked full browsing traffic outside the tunnel, and four ran “tunnels” with no encryption at all, with some apps failing in more than one way.

Separately, 169 apps made no attempt to disguise their traffic as anything other than a VPN, so a network operator or government censor can spot and block them with basic tools. Nearly two-thirds of those apps advertise that they beat blocking or unlock restricted content. They make the promise and do nothing to keep it. For someone in a country where using a VPN is itself risky, being easy to identify as a VPN user is the opposite of what they signed up for.

Tracking, from the apps built to stop it People often install VPNs to avoid being tracked. Many of these apps track anyway. 76 sent the device’s Advertising ID, a unique code advertisers use to follow a person from one app to the next. The study found that more than 80% of the apps, 246 of them, contacted known advertising and tracking servers.

Many also sent details like the phone model, operating system version, and screen size. On their own, those look harmless, but combined, they form a “fingerprint” that can single out one device. One app even sent the phone’s exact GPS coordinates. Weak setups under the hood The researchers also pulled apart the OpenVPN configuration files bundled with 108 of the apps, a separate check from the live-traffic tests above.

Only one followed every security best practice the study measured. About 89% relied on a single authentication method, either a password or a certificate, rather than combining the two. Nearly one in five used weak or outdated encryption, including the aging Blowfish cipher and triple DES. A few set the tunnel’s data cipher to none, which switches off encryption entirely.

Both of those old ciphers carry long-known weaknesses ( CVE-2016-6329 and CVE-2016-2183 ) that let an attacker recover data from long-running connections. Most of these problems trace back to the same root: the apps are barely maintained, and the Play Store’s automated checks let them through. Many rank among its top search results, where Google’s safety labels and its “Verified” badge for VPN apps are meant to signal trust. The study says those labels work more like marketing signals than a real security guarantee.

This is not a one-off Other recent research points in the same way. In August 2025, researchers at the University of Toronto’s Citizen Lab and Arizona State University found that several popular Android VPN apps, with more than 700 million combined downloads, were secretly linked, shared hard-coded passwords, and quietly collected location data. In October 2025, mobile security firm Zimperium reported that three of the roughly 800 free VPN apps it tested still bundled a version of the OpenSSL library vulnerable to Heartbleed, a well-known bug patched back in 2014. Many also asked for phone permissions far beyond what a VPN needs.

The three studies tell one story: free VPN apps keep pairing a strong privacy pitch with weak engineering, and they keep reaching millions of installs before anyone catches it. What users can do The most serious flaws here, the cleartext config fetch and the weak tunnel settings, are invisible from the user’s side. You cannot spot them by looking at the app, which is the whole problem. So the real defense is not which protocol the app advertises.

It is who is behind it. Favor providers that publish a recent independent security audit. Be wary of free apps that bury you in ads. And treat “verified” or “no-logs” claims as a starting point, not proof.

The researchers list every flagged app in the paper’s appendix, so you can check whether the one on your phone is among them. The team plans to release MVPNalyzer publicly so app stores and regulators can run these checks themselves. On this evidence, they will have to. The Hacker News has asked Google whether it is reviewing or removing the flagged apps, and for its response to the study’s finding that Play Store safety labels and the “Verified” badge function more as marketing than security guarantees.

We have also asked the MVPNalyzer research team to identify the five apps vulnerable to tunnel hijacking and to confirm whether the notified providers have since deployed fixes. This story will be updated with any response. Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.

Hackers Use Fake Microsoft Entra Passkey Enrollment to Gain Microsoft 365 Access

A threat actor has been targeting organizations spanning multiple sectors with voice-based fake security requests that prompt Microsoft 365 users to enroll a new Entra passkey with an aim to carry out data extortion attacks. The threat actor, tracked by Okta under the moniker O-UNC-066 , has deployed a panel-controlled phishing kit that’s capable of targeting the passkey enrollment process . The activity has singled out food and beverage, technology, healthcare, automotive, construction, and aviation industries. “The threat actor registers domains that incorporate the word passkey as part of a voice-enabled phishing (‘vishing’) scheme,” Okta researcher Houssem Eddine Bordjiba said .

“The threat actor then calls targeted users on the phone in an attempt to persuade them that they need to register a new passkey.” Users are then directed to a phishing kit that’s identical to the Microsoft passkey enrollment process, giving the impression that they are adding a passkey with Microsoft, when, in reality, the threat actor registers their own passkey against their Microsoft account, granting them unauthorized access. The development coincides with Microsoft allowing administrators to configure registration campaigns to nudge users to register passkeys during sign-in in an attempt to help organizations drive passkey adoption at scale. In other words, threat actors are abusing the phishing-resistant security upgrade process as a lure to enroll their own passkeys within victims’ accounts and facilitate follow-on activities. Unlike adversary-in-the-middle ( AitM ) landing pages that are prevalent in phishing campaigns designed to steal credentials and multi-factor authentication (MFA) tokens, the phishing kit used in these attacks is an operator-controlled PHP panel in which a victim is guided through the passkey enrollment process in almost real-time.

“The operator can use the kit to adapt the user experience to each victim’s MFA requirements (TOTP, push notification with number matching, SMS OTP) during the session,” the identity security company said. “The caller can control and adjust in real time what phishing pages and notifications a targeted user sees.” It’s suspected that the threat actor is leveraging the kit to take over the victim account and trick the user into approving an attacker-initiated registration of a passkey. There is no indication at this stage to suggest that the kit is redirecting users to third-party identity providers like Okta. The entire sequence of actions is below - The first page of the phishing kit (/gate) displays a page loading icon while the phishing kit performs anti-analysis checks in the background.

The second page (/identify) requests a username. The next page (/password) challenges the user for a password. The harvested credentials are sent in a POST request to an operator panel at “/backend.php.” The phishing kit operator (likely different from the individual calling the victim) enters the stolen credentials on the legitimate Microsoft sign-in page for the targeted tenant. The victim sees a “/processing” page that serves another loading screen as it awaits the operator’s instruction based on the observed MFA challenges presented to them in the legitimate flow.

The next page of the phishing kit is presented to the user: “/submit-otp” for an SMS-based one-time password (OTP) challenge, “/submit-authenticator” for time-based OTP challenge, or “/approve-authenticator” for a push MFA challenge . The captured OTP is sent in a POST request to “/backend.php.” At this point, the victim has been deceived over the phone into approving the attacker’s access to their Microsoft 365 account. The attack chain then initiates another set of actions focused around the passkey pretext - The victim is redirected to the “/passkey/register” page, which instructs the user to create a passkey. The Microsoft-branded “/passkey” page prompts the user to save their recovery key for confirming their passkey.

The “/passkey/check” page asks the user to verify the final word used in the seed phrase. The “/done” page confirms that a passkey registration was successful. The recovery key contains a series of 12 words that’s similar to secret recovery phrase or mnemonic phrase typically associated with cryptocurrency wallets. The step is assessed to be a distraction mechanism to keep the victim occupied with the task, while they enrolled their own passkey in the Microsoft account.

“The phishing kit appears to prey on lack of user familiarity with passkey authentication,” Okta explained. “In a real passkey registration ceremony, the user might expect a system dialog to register a passkey on their device. The passkey pages in this phishing kit appear to mimic this process without registering a passkey.” Okta noted that a threat actor linked to O-UNC-066 has been operating a data leak site since April 2026 under the name Pink. Palo Alto Networks Unit 42 is tracking this cluster as CL-CRI-1147, describing it as affiliated with a decentralized cybercrime collective known as The Com , of which Scattered Spider, ShinyHunters, and LAPSUS$ are part of.

Found this article interesting? Follow us on Google News , Twitter and LinkedIn to read more exclusive content we post.