Reading view

Lone attacker published 14 malicious npm packages mimicking popular OpenSearch, Elasticsearch libraries

A single npm user on Thursday published 14 malicious packages within a four-hour window, all mimicking popular OpenSearch, Elasticsearch, DevOps, and environment-configuration libraries, according to Microsoft. It’s the latest in a seemingly never-ending string of supply chain attacks targeting developer tools, and stealing cloud credentials and CI/CD pipeline secrets in its wake. Using a newly created maintainer alias, vpmdhaj (a39155771@gmail[.]com), the threat actor published 14 packages impersonating legitimate libraries from the @opensearch and @elastic ecosystems and targeting Amazon Web Services, HashiCorp Vault, GitHub Actions, and the npm registry itself. This suggests that the attacker “likely chose a developer audience to have AWS and Elastic cloud credentials in their environments,” Microsoft warned in a Thursday blog. All of the malicious packages include the same install-time stager and the same Bun-compiled, second-stage payload: a 195 KB credential harvester purpose-built for cloud and CI/CD environments. Plus, as we’ve seen with all of the other open source supply chain attacks of late, after stealing tokens and other secrets, the attacker can move laterally across cloud environments, steal additional sensitive data, and push even more poisoned updates to packages owned by hijacked maintainer identities, thus expanding the attack beyond the initial 14. All of the malicious libraries have since been removed, and Microsoft published a list of all 14 in its blog. Give that a read to help identify systems that installed or built affected package versions on or after May 28. Be sure to also rotate an AWS IAM/STS, HashiCorp Vault, npm publish, and GitHub Actions tokens that may have been exposed. To trick users into installing these developer tools and search engines, the attacker used typosquatting - naming a package one or two letters off from the legitimate one - or lookalike naming (such as opensearch-setup-tool, opensearch-config-utility, and elastic-opensearch-helper) to impersonate well-known libraries. In addition to this social engineering technique, used to drive installs through users’ typing mistakes or trust, the attacker also used two other techniques to make the supply chain attack more believable. This includes spoofing upstream metadata. “Every unscoped package sets its package.json homepage, repository, and bugs fields to the legitimate github.com/opensearch-project/opensearch-js project,” Microsoft’s threat hunters explained. And finally, they inflated version numbers, so the phony “releases” jump straight to 1.0.7265, 1.0.9108, or 2.1.9201 to indicate a mature release history. After tricking users into installing the npm packages - all 14 are listed in the blog, so give that a read - the credential-stealing payloads automatically execute through preinstall hooks as soon as the victim runs npm install. For this, the attacker used one of two stagers. The Gen-1 stager uses install, preinstall, and postinstall hooks that all invoke preinstall.js, and then collects a ton of host information including hostname, platform, arch, Node version, USER/USERNAME, cwd, INIT_CWD, npm_package_name, npm_package_version. It then base64-encodes the JSON, and POSTs it to the actor’s command-and-control server, which then serves a second-stage payload, written to payload.bin in the package install directory. “The package’s index.js re-launches the same payload.bin on every subsequent require() of the module – a quiet persistence mechanism that survives across CI build stages and developer rebuild loops,” according to Microsoft. The later Gen-2 stager replaces the install-time C2 roundtrip with a stealthier loader that checks whether bun is already present on the host. If not, it downloads the legitimate Bun runtime v1.3.13, and then executes the second-stage payload, which sets to work stealing credentials across AWS, HashiCorp Vault, npm, GitHub Actions, and other CI/CD environments.®

  •  

ICE to keep an eye on your eyes under $25M biometric scanner deal

If you thought US Immigration and Customs Enforcement’s widespread use of face recognition apps was a privacy violation, you’re about to get eye-rate over a new $25 million contract. According to a largely unreported contract summary published last week by ICE parent agency the Department of Homeland Security, US immigration cops have doled out about $25.1 million to a company called Bi2 Technologies for 1,570 biometric recognition devices able to identify people through fingerprints, iris scans, and facial recognition. Additional procurement data indicates that the devices can be used in the field in both mobile and stationary configurations, and they provide ICE agents with access to Bi2’s Inmate Recognition and Identification System (IRIS), which matches biometrics to a database of more than five million booking, arrest, and incarceration records from 47 US states. The Bi2 system is also able to access driver’s license and vehicle plate info. The deal was made without seeking any competing bids, and ICE justified the sole-source acquisition by pointing not only to Bi2’s capabilities being “unmatched by any competitor,” but also to a contract from last year in which it paid the company $4.6 million for what now appears to have been a one-year trial run of its technology on a much smaller scale. Per the FY 2025 contract, which expires at the end of this coming September, ICE got similar access to the IRIS database and mobile/stationary biometric scanning technology as this year’s award, but only 200 devices were deployed across the US. With the addition of this contract, 1,770 of the devices could now be on American streets by the end of May 2027. While the Bi2 contracts have yet to cause a stir on the level of other ICE biometric surveillance technologies, the widespread deployment of eyeball scanners linked to law enforcement databases and other forms of government documentation could end up stirring up more controversy. Senate Democrats have been railing against ICE’s use of biometric identification technology like Mobile Fortify, an app reportedly used by DHS under the Trump administration’s immigration enforcement push to identify people suspected of immigration violations and, potentially, protesters. In a letter last September, senators demanded ICE immediately cease using Mobile Fortify over concerns that the app could be inaccurate, biased, and might have a chilling effect on the legal expression of protected civil rights in the US. Neither ICE nor DHS responded to questions for this story. ®

  •  

No fix yet for critical RCE bug in open-source Git service Gogs - exploit module is out

There's a huge hole and no one is patching it thus far. A critical, remote code execution (RCE) bug in Gogs, a popular open-source self-hosted Git service, can be exploited by any authenticated user - no special privileges required - on a default installation to fully compromise vulnerable servers, steal credentials and multi-factor authentication secrets, or even modify code in hosted repositories in a wide-reaching supply-chain attack. A security researcher reported the 9.4-rated flaw to project maintainers in mid-March. It still doesn’t have a patch. It does, however, have a public Metasploit module - so we’d expect reports of in-the-wild exploitation to start very soon. The vulnerability affects all supported platforms, including Windows, Linux, and macOS, and installation methods, according to Rapid7 researcher Jonah Burgess, who found and reported the bug to Gogs maintainers via GitHub (GHSA-qf6p-p7ww-cwr9) on March 17. After they initially acknowledged that they received the report on March 28, Burgess says he never heard back from the Gogs team - not when he asked them for a status update, nor when he reminded them of the vulnerability disclosure date and asked if they wanted an extension to fix the flaw before its release. “We have not received any further communication from Gogs, and the GHSA has remained unanswered since March 28,” Burgess told The Register. “Because there is currently no official patch, our team submitted a pull request with a suggested fix today [Friday], which is currently awaiting review. At this time, we have no evidence suggesting that this vulnerability is being exploited in the wild.” Gogs sponsor DigitalOcean also did not respond to The Register’s inquiries, including when the security issue would receive a patch. The vulnerability stems from an argument injection flaw in Gogs’ pull request merge flow, specifically the Merge() function in internal/database/pull.go. If a Gogs repo owner or admin enables "Rebase before merging" and a user opens a pull request, the PR's base branch name gets passed directly to a git rebase command without a -- separator to mark the end of command options. Gogs also fails to properly sanitize the input. This means an attacker can create a malicious branch (such as --exec=touch${IFS}/tmp/rce_proof), and Git treats it as an --exec flag, not a branch name, and executes the payload. For Windows installations, the payload delivery method is slightly different, and Burgess developed an exploit module to auto-implement a cross-platform approach. Until the maintainers fix the flaw, Burgess suggests Gogs’ users take the following precautions to mitigate the issue. First, and most importantly, restrict user registration (DISABLE_REGISTRATION = true in app.ini) to prevent untrusted users from creating accounts. Restricting repository creation (MAX_CREATION_LIMIT = 0 in app.ini) to prevent users from creating their own repos also blocks the easiest attack path - creating a new repo with rebase enabled - but it won’t prevent exploitation by users with write access to existing repositories. Finally, audit rebase merge settings, and disable “Rebase before merging" under Settings > Advanced. “Note that this is not an effective defense against a malicious user who owns or has admin access to a repo, since they can re-enable rebase at will,” the threat hunter warns. “There is no global or organization-level setting to restrict this.” ®

  •  

23andMe inherits lawsuit over 'disturbing' DNA data breach

The office of Rob Bonta, California's attorney general, is suing 23andMe for the data protection failings that led to the genetics company's disastrous 2023 breach. Bonta and his team claim [PDF] that 23andMe failed to implement adequate security controls for the sensitive records it stored, and misled customers about the nature of the mishap after the fact. "23andMe collected genetic data about millions of people, failed to meet its obligation under California law to keep that information safe, and then lied to consumers about the severity of its 2023 data breach," said Bonta on Thursday. "Our investigation found that the company failed to take basic steps to protect users' data – data including the sensitive personal information, family histories, and health conditions of consumers "The sale of this data on the dark web took place amidst a period of mounting anti-Asian American and Pacific Islander and antisemitic hate and violence – and explicitly called attention to the deeply personal and identifying nature of that information. This is disturbing and incredibly dangerous. Today, my office is suing 23andMe for its categorical failure to comply with California law." The lawsuit was filed against Chrome Holding Co., formerly known as 23andMe. TTAM Research Institute bought 23andMe's assets last year. TTAM Research Institute was founded and is led by Anne Wojcicki, who was also 23andMe's CEO at the time of the breach and one of the company's co-founders. The nonprofit's purchase of 23andMe assets was completed on July 14, 2025, at which time it promised to run 23andMe charitably, using its data to further medical research and education. 23andMe continues to operate as it always did, taking customers' saliva samples and turning it into fun insights, such as what percentage of their makeup is Neanderthal, and whether their DNA makes them more or less likely to enjoy a scattering of cilantro on their food. 'Disturbing' Announcing the lawsuit, Bonta's office used "disturbing" no less than three times to describe the events that transpired before and after 23andMe's mega breach. To recap, a cybercriminal going by the name Golem popped up on a forum in 2023 claiming to offer a slew of data belonging to millions of 23andMe customers. Investigations carried out by regulators later found that Golem only breached around 14,000 accounts, but because of 23andMe's DNA relatives feature, which allows users to connect with other 23andMe users who share a percentage of the same DNA, the crook was able to access the details of nearly 7 million customers. It also soon emerged that 23andMe failed to spot the intrusion for five months, and the 14,000 or so accounts Golem accessed were compromised as a result of credential-stuffing attacks. What followed was a multi-faceted game of finger-pointing. 23andMe's decision to blame customers for recycling credentials instead of admitting it should have mandated 2/MFA on all accounts by default went down about as badly as one might expect. To this day, 23andMe allows customers to use its service without 2/MFA, although it issues regular prompts to those who don't have it set up. Regulators, on the other hand, highlighted that the company's security practices were less than perfect, while security experts were divided. Many agreed there was blame to be placed on both sides. Then came the fines and the settlements. The UK's Information Commissioner hit the company with a £2.3 million ($3.09 million) fine in June 2025, three months after the bankruptcy filing. In its ruling, it echoed the findings of US authorities from 2023, accusing the company of relying on inadequate password requirements. The Information Commissioner rebuked 23andMe for failing to detect the intrusion promptly and not implementing measures to prevent bulk downloading of genetic data. 23andMe also settled a class action lawsuit for $30 million in 2024. Bonta's office alleged that 23andMe’s statements to customers were "misleading and omitted or misrepresented critical information." "While 23andMe assured the public that it had not experienced a data security incident within its systems, downplayed the sensitivity of the stolen data by claiming that the information stolen from the 'DNA Relatives' feature was essentially public, and attempted to shift blame for the breach to its customers, 23andMe was simultaneously negotiating and paying a ransom to the threat actor in exchange for, among other things, the threat actor removing damaging information regarding the breach that had been posted online and providing information about multiple 23andMe security vulnerabilities, including vulnerabilities the threat actor exploited during the data breach." The Register contacted 23andMe's publicists for a response. We only received one on behalf of the 23andMe Research Institute, which despite managing requests directed to the 23andMe platform's only press contact address, distanced itself from Chrome Holding, which, like TTAM Research Institute, does not have a public-facing contact. It also did not help us contact 23andMe's operator. The institute said: "The 23andMe Research Institute is a newly established independent nonprofit organization and is not involved in the matters described in the California Attorney General's complaint filed against Chrome Holding Co., formerly known as 23andMe. The lawsuit pertains to events and operations associated with the former commercial entity prior to the creation of the 23andMe Research Institute. The institute was not involved in the complaint and has no role in the underlying litigation. "The 23andMe Research Institute is focused on advancing nonprofit scientific and health research with a strong commitment to privacy, ethics, transparency, and responsible data stewardship." ®

  •  

Attackers Use LLM Agent for Post-Exploitation After Marimo CVE-2026-39987 Exploit

An unknown threat actor has been observed using a large language model (LLM) agent to conduct post-compromise actions after obtaining initial access following the exploitation of a publicly-accessible Marimo network using a recently disclosed vulnerability. "The attacker compromised an internet-reachable Marimo notebook via CVE-2026-39987, extracted two cloud credentials from the compromised

  •  
❌