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.®

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. ®

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.” ®