Digital assets after death: Managing risks to your loved one’s digital estate
Fraudsters often target the accounts of the deceased or their grieving relatives. Here’s how to keep the scammers at bay.
WeLiveSecurity – Read More
Fraudsters often target the accounts of the deceased or their grieving relatives. Here’s how to keep the scammers at bay.
WeLiveSecurity – Read More
Attackers stole a long-lived npm access token belonging to the lead maintainer of axios, the most popular HTTP client library in JavaScript, and used it to publish two poisoned versions that install a cross-platform remote access trojan. The malicious releases target macOS, Windows, and Linux. They were live on the npm registry for roughly three hours before removal.
Axios gets more than 100 million downloads per week. Wiz reports it sits in approximately 80% of cloud and code environments, touching everything from React front-ends to CI/CD pipelines to serverless functions. Huntress detected the first infections 89 seconds after the malicious package went live and confirmed at least 135 compromised systems among its customers during the exposure window.
This is the third major npm supply chain compromise in seven months. Every one exploited maintainer credentials. This time, the target had adopted every defense the security community recommended.
The attacker took over the npm account of @jasonsaayman, a lead axios maintainer, changed the account email to an anonymous ProtonMail address, and published the poisoned packages through npm’s command-line interface. That bypassed the project’s GitHub Actions CI/CD pipeline entirely.
The attacker never touched the Axios source code. Instead, both release branches received a single new dependency: plain-crypto-js@4.2.1. No part of the codebase imports it. The package exists solely to run a postinstall script that drops a cross-platform RAT onto the developer’s machine.
The staging was precise. Eighteen hours before the axios releases, the attacker published a clean version of plain-crypto-js under a separate npm account to build publishing history and dodge new-package scanner alerts. Then came the weaponized 4.2.1. Both release branches hit within 39 minutes. Three platform-specific payloads were pre-built. The malware erases itself after execution and swaps in a clean package.json to frustrate forensic inspection.
StepSecurity, which identified the compromise alongside Socket, called it among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.
Axios did the right things. Legitimate 1.x releases shipped through GitHub Actions using npm‘s OIDC Trusted Publisher mechanism, which cryptographically ties every publish to a verified CI/CD workflow. The project carried SLSA provenance attestations. By every modern measure, the security stack looked solid.
None of it mattered. Huntress dug into the publish workflow and found the gap. The project still passed NPM_TOKEN as an environment variable right alongside the OIDC credentials. When both are present, npm defaults to the token. The long-lived classic token was the real authentication method for every publish, regardless of how OIDC was configured. The attacker never had to defeat OIDC. They walked around it. A legacy token sat there as a parallel auth path, and npm‘s own hierarchy silently preferred it.
“From my experience at AWS, it’s very common for old auth mechanisms to linger,” said Merritt Baer, CSO at Enkrypt AI and former Deputy CISO at AWS, in an exclusive interview with VentureBeat. “Modern controls get deployed, but if legacy tokens or keys aren’t retired, the system quietly favors them. Just like we saw with SolarWinds, where legacy scripts bypassed newer monitoring.”
The maintainer posted on GitHub after discovering the compromise: “I’m trying to get support to understand how this even happened. I have 2FA / MFA on practically everything I interact with.”
Endor Labs documented the forensic difference. Legitimate axios@1.14.0 showed OIDC provenance, a trusted publisher record, and a gitHead linking to a specific commit. Malicious axios@1.14.1 had none. Any tool checking provenance would have flagged the gap instantly. But provenance verification is opt-in. No registry gate rejected the package.
Three npm supply chain compromises in seven months. Every one started with a stolen maintainer credential.
The Shai-Hulud worm hit in September 2025. A single phished maintainer account gave attackers a foothold that self-replicated across more than 500 packages, harvesting npm tokens, cloud credentials, and GitHub secrets as it spread. CISA issued an advisory. GitHub overhauled npm’s entire authentication model in response.
Then in January 2026, Koi Security’s PackageGate research dropped six zero-day vulnerabilities across npm, pnpm, vlt, and Bun that punched through the very defenses the ecosystem adopted after Shai-Hulud. Lockfile integrity and script-blocking both failed under specific conditions. Three of the four package managers patched within weeks. npm closed the report.
Now axios. A stolen long-lived token published a RAT through both release branches despite OIDC, SLSA, and every post-Shai-Hulud hardening measure in place.
npm shipped real reforms after Shai-Hulud. Creation of new classic tokens got deprecated, though pre-existing ones survived until a hard revocation deadline. FIDO 2FA became mandatory, granular access tokens were capped at seven days for publishing, and trusted publishing via OIDC gave projects a cryptographic alternative to stored credentials. Taken together, those changes hardened everything downstream of the maintainer account. What they didn’t change was the account itself. The credential remained the single point of failure.
“Credential compromise is the recurring theme across npm breaches,” Baer said. “This isn’t just a weak password problem. It’s structural. Without ephemeral credentials, enforced MFA, or isolated build and signing environments, maintainer access remains the weak link.”
|
What SOC leaders need |
|
vs. axios attack |
The gap |
|
Block stolen tokens from publishing |
FIDO 2FA required. Granular tokens, 7-day expiry. Classic tokens deprecated |
Bypassed. Legacy token coexisted alongside OIDC. |
No enforcement removes legacy tokens when OIDC is configured |
|
Verify package provenance |
OIDC Trusted Publishing via GitHub Actions. SLSA attestations |
Bypassed. Malicious versions had no provenance. Published via CLI |
No gate rejects packages missing provenance from projects that previously had it |
|
Catch malware before install |
Socket, Snyk, Aikido automated scanning |
Partial. Socket flagged in 6 min. First infections hit at 89 seconds |
Detection-to-removal gap. Scanners catch it, registry removal takes hours |
|
Block postinstall execution |
–ignore-scripts recommended in CI/CD |
Not enforced. |
postinstall remains primary malware vector in every major |
|
Lock dependency versions |
Lockfile enforcement via |
Effective only if lockfile committed before compromise. Caret ranges auto-resolved |
Caret ranges are |
SOC leaders whose organizations run Node.js should treat this as an active incident until they confirm clean systems. The three-hour exposure window fell during peak development hours across Asia-Pacific time zones, and any CI/CD pipeline that ran npm install overnight could have pulled the compromised version automatically.
“The first priority is impact assessment: which builds and downstream consumers ingested the compromised package?” Baer said. “Then containment, patching, and finally, transparent reporting to leadership. What happened, what’s exposed, and what controls will prevent a repeat. Lessons from log4j and event-stream show speed and clarity matter as much as the fix itself.”
Check exposure. Search lockfiles and CI logs for axios@1.14.1, axios@0.30.4, or plain-crypto-js. Pin to axios@1.14.0 or axios@0.30.3.
Assume compromise if hit. Rebuild affected machines from a known-good state. Rotate every accessible credential: npm tokens, AWS keys, SSH keys, cloud credentials, CI/CD secrets, .env values.
Block the C2. Add sfrclak.com and 142.11.206.73 to DNS blocklists and firewall rules.
Check for RAT artifacts. /Library/Caches/com.apple.act.mond on macOS. %PROGRAMDATA%wt.exe on Windows. /tmp/ld.py on Linux. If found, preform a full rebuild.
Harden going forward. Enforce npm ci --ignore-scripts in CI/CD. Require lockfile-only installs. Reject packages missing provenance from projects that previously had it. Audit whether legacy tokens coexist with OIDC in your own publishing workflows.
Three attacks in seven months. Each different in execution, identical in root cause. npm’s security model still treats individual maintainer accounts as the ultimate trust anchor. Those accounts remain vulnerable to credential hijacking, no matter how many layers get added downstream.
“AI spots risky packages, audits legacy auth, and speeds SOC response,” Baer said. “But humans still control maintainer credentials. We mitigate risk. We don’t eliminate it.”
Mandatory provenance attestation, where manual CLI publishing is disabled entirely, would have caught this attack before it reached the registry. So would mandatory multi-party signing, where no single maintainer can push a release alone. Neither is enforced today. npm has signaled that disabling tokens by default when trusted publishing is enabled is on the roadmap. Until it ships, every project running OIDC alongside a legacy token has the same blind spot axios had.
The axios maintainer did what the community asked. A legacy token nobody realized was still active and undermined all of it.
Security | VentureBeat – Read More
The Meta subsidiary alleges that Italy’s SIO spyware manufacturer designed the phony app specifically for iPhones. Most of the impacted users are in Italy, according to a WhatsApp announcement.
The Record from Recorded Future News – Read More
Apple pushes rare iOS 18 security patch to protect devices at risk from the DarkSword exploit, urging users to update or move to iOS 26 for stronger protection.
Hackread – Cybersecurity News, Data Breaches, AI and More – Read More
Finder tags are great, but most are pretty fragile. These Ugreen Finder Pro tags are some of the toughest I’ve tested.
Latest news – Read More
The latest patch provides protection against the deadly DarkSword exploit for iPhone users who have chosen to remain on iOS 18.
Latest news – Read More
A LinkedIn phishing scam uses fake notifications and lookalike domains to steal credentials, hijack accounts, and access sensitive professional data.
Hackread – Cybersecurity News, Data Breaches, AI and More – Read More
I just had a ‘living in the future’ moment with Gmail, of all things. Here’s what happened.
Latest news – Read More
The company is investigating the full scope of the incident, including whether any files have been compromised.
The post Toy Giant Hasbro Hit by Cyberattack appeared first on SecurityWeek.
SecurityWeek – Read More
While this post comes out on April 1, the threat described has little to do with April Fools’ Day — except for the fact that the CrystalX malicious RAT, discovered by Kaspersky experts, can do more than just gain remote access to a victim’s device, steal cryptocurrency and credentials from browsers and apps, or conduct actual surveillance. It can also flip the victim’s screen, swap mouse buttons, write nonsense directly onto the screen, and even block keyboard input. Furthermore, it’s advertised as malware-as-a-service (MaaS) — meaning it’s subscription-based — on Telegram and through instructional videos on YouTube.
In this post, we explain some basics as to how this new malware was built, what makes it difficult to detect, and what to do so you don’t end up among its victims.
In March 2026, our experts discovered previously unknown malware circulating on private Telegram channels. Borrowing from classic marketing tactics, the Trojan was offered for purchase via three different subscription tiers. Its capabilities cover a fairly broad spectrum: judge for yourself what it can do to a victim’s computer:
Yet that’s only the harmless side of the malware — the prank functionality that harks back to the joke viruses of past decades. The real damage from CrystalX comes from its stealing login credentials for Steam, Discord, Telegram, and all Chromium-based browsers. It can also monitor and change the contents of the clipboard; typically, attackers watch for a crypto wallet address to be copied, and then swap it with their own. This is a popular scheme for stealing crypto: while intending to make a legitimate transfer, the victim copies the recipient’s wallet address, but ends up pasting the scammers’ address instead.
But there’s more: a keylogger feature and full device control with remote access to the screen, camera, and microphone — including video and sound recording capabilities.
The malware was first mentioned in January 2026 in a private Telegram chat for RAT developers. At that time, this Windows Trojan was called WebCrystal RAT and, based on technical details, was revealed to be a clone of another RAT known as WebRat. A short time later, the author of WebCrystal rebranded it as CrystalX RAT, and began touting the Trojan on a newly created Telegram channel.
The initial infection vector for this stealer is currently unknown, but according to telemetry the victims at the time of writing are predominantly located in Russia. And since we’re continuing to find new versions of the malware, we deem it a rapidly growing and evolving threat.
Developing any complex cyberattack used to come with a steep learning curve. You needed to understand cryptography and network protocols, and know how to write code that could fool antivirus solutions. It was a high bar to clear, but the malware-as-a-service model has been changing the game.
These days, an attacker only needs basic computer literacy to rent a ready-made platform with a user-friendly user interface. The threat is becoming widespread specifically because malware creators aren’t carrying out the attacks themselves anymore — they’re selling shovels during a gold rush. They focus on supporting their customers, improving the user interface, and pouring money into aggressive marketing.
Hackers are even setting up YouTube channels where they use the pretext of “for educational and entertainment purposes” to explain how to manage the Trojan from the control panel. Instructional videos that were once buried in the dark web have gone mainstream, putting hacking techniques in front of a broad, general audience.
No matter how technically advanced a hacking app’s code is, it will die as a project without a constant stream of new clients. This makes marketing efforts vital to its survival — even if they significantly increase the risk of the developer ending up behind bars. However, the creators of CrystalX have figured out how to protect their creation.
The control panel allows clients to build their own unique versions of the Trojan with extensive configuration options. For example, they can enable location filtering to target users in specific countries, choose an icon for the executable file, and toggle anti-analysis features. The finished Trojan is compressed using zlib and then encrypted with a ChaCha20 stream cipher using a 256-bit key and a 96-bit nonce. This ensures that every customer receives a unique version of the malware.
CrystalX is also capable of detecting virtual machines and checking if it’s running in a test or debugging environment, which complicates discovery. You can read more about the structure and functionality of this new Trojan in our Securelist story.
The good news for Kaspersky users is that our security solutions both detect and neutralize CrystalX.
Here are a few simple tips to help you avoid infection by CrystalX and other similar malware:
Read more about remote access Trojans, miners, crypto-stealers, and other digital nasties:
Kaspersky official blog – Read More