A security firm has found that placing a disguised instruction file inside a user's Downloads folder is enough to manipulate AI coding agents into installing malware, with one leading tool executing a known-malicious package in more than nine out of ten test runs.
The finding comes from Forever Security, which said one of its customers had an `AGENTS.md` file sitting in their Downloads folder. The file was designed to look like routine engineering notes, but its actual purpose was to instruct any coding agent that opened the folder to install `function-color`, a package tied to the MALFEX npm supply chain campaign. Forever stopped the agent before the installation completed. The firm could not determine how the file got there.
How the Malware Chain Works
`function-color` is a wrapper package. It carries no payload of its own but silently installs `function-flag` as a dependency. That package runs a postinstall script that downloads a Windows executable from a remote host, saves it as `node.exe` inside `%APPDATA%`, and executes it in the background. The download routine sits inside an empty catch block, so a failed attempt produces no error and leaves no trace in the install log. As of early October, both packages remained installable on npm with no advisory flagging either one.
The reason the attack targets the Downloads folder specifically is not arbitrary. Browsers can save files to that directory without asking the user for permission or even requiring a click. Forever built a proof-of-concept web page that silently dropped a crafted `AGENTS.md` into Downloads during a normal browsing session. The firm did not establish that an attacker used this exact method against its customer, but the capability is real and requires no special access.
Test Results Across Two Major Agents
To measure how reliably the technique works, Forever ran controlled tests against OpenAI's Codex and Anthropic's Claude Code.
For Codex, the planted file instructed the agent to register a new server entry in `~/.codex/config.toml` and install the malicious package. Because that config file applies to every session on the machine, a successful write would persist across projects. Codex followed through in more than 90 percent of the test attempts inside an isolated virtual machine.
Claude Code required a different approach. The planted `CLAUDE.md` was written to resemble internal gateway setup documentation, and its goal was to write a custom API endpoint into the project's `.claude/settings.json` file. If an attacker controls that endpoint, every API call from the agent passes through their infrastructure, along with the session token. The token can then be used to take over the account. Claude Code normally prompts the user to approve writes of that kind, and it frequently rejected requests that looked suspicious. The extended engineering-document framing, however, got the write approved roughly half the time.
Neither Vendor Has a Patch
Forever stated plainly that there is nothing for OpenAI or Anthropic to fix. Each agent was doing what it was built to do: read instruction files in the working directory and carry out the steps listed in them. The firm compared the situation to a browser rendering a phishing page. The browser is not broken; the page is malicious.
That framing shifts the responsibility to users and organizations. Forever's own telemetry adds urgency to that point. About half of its customers run a coding agent from their Downloads folder, and roughly a quarter of agent sessions involve an open browser. In many of those cases, no person is actively watching the session when a new file arrives in the directory.
What to Do
The most direct fix is to stop running coding agents from the Downloads folder entirely. Beyond that, Forever recommends reading any `AGENTS.md` or `CLAUDE.md` file you did not write yourself before running a session, including files that arrive in freshly cloned repositories.
For anyone who suspects a file may have already been processed, the firm advises checking `~/.codex/config.toml` for unrecognized server blocks and reviewing `.claude/settings.json` for API endpoints that were not intentionally set. On Windows machines, the presence of `node.exe` inside `%APPDATA%` is a strong indicator that the function-flag payload ran successfully. If a planted file is confirmed, the session's login token should be treated as compromised and rotated immediately.
Keeping approval prompts enabled and running agents inside sandboxes reduces the attack surface, though the Claude Code test results show that approval prompts alone are not a reliable barrier when the malicious instruction is written to look like legitimate documentation.
Attackers hijacked 333 Tor exit relays in early October 2026, redirecting Secure Shell (SSH) connections through 12 interception servers to steal passwords and potentially deploy malware. Researcher kaba discovered the operation on October 2, while separate analysis identified 377 relays operated by 59 operators that had adopted the attackers' exit policy. The malicious configuration represented 7.46% of Tor's exit capacity at its October 4 peak.
Attackers Modified Relay Configurations
Tor exit relays forward traffic to destinations outside the network. Attackers modified the relays' "torrc" configuration files to permit connections over port 22, enabling SSH on 342 relays that previously blocked it and converting another 24 non-exit relays into exits.
The changes also blocked encrypted email ports while permitting plaintext-capable IMAP and POP3 connections on most affected relays. This potentially exposed unencrypted email retrieval, although investigators have not established whether attackers successfully captured messages.
Kaba discovered the campaign after an SSH connection through Tor triggered a warning that the remote host's identity had changed. Using exitmap, the researcher tested approximately 3,000 exit relays by routing SSH connections between controlled servers. The investigation identified 333 relays redirecting connections to the same 12 interception servers. Around a dozen presented fraudulent host keys directly, while the others redirected traffic without altering the key themselves.
The interception servers presented their own SSH host keys before connecting to the legitimate destinations. Users who accepted unfamiliar keys and entered passwords exposed their credentials. Attackers could then observe commands, check administrative privileges and attempt to install a Base64-encoded Perl payload.
Public-key authentication could not be transparently relayed in the same way because SSH authentication signatures are tied to individual sessions. However, users who accepted a malicious key could still be deceived into interacting with an attacker-controlled shell.
Ebury Backdoor Reveals an Earlier Intrusion
The Tor Project's Network Health team warned relay operators on October 5 that attackers appeared to be compromising Linux hosts and changing their configurations.
In an October 7 post-mortem, operator Zimmer confirmed Ebury version 1.8.3 on two Quetzalcoatl relay-family servers. The attacker had accessed a management server on August 28 using the operator's password, obtained root privileges within five minutes and installed Ebury. Approximately an hour later, the attacker compromised a second server, Switzerland2.
Zimmer attributed the initial intrusion to password reuse across SSH, "sudo" and backup encryption, with the password also stored in plaintext. SSH password authentication remained enabled on the internet-facing management server.
Ebury is a Linux backdoor and credential stealer associated with OpenSSH compromises since 2009. ESET estimated in 2024 that it had infected approximately 400,000 servers, with more than 100,000 still infected in late 2023.
The implant masqueraded as "/usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2", with "libkeyutils.so.1" pointing to the malicious file. Because the packaged library remained untouched, conventional integrity checks such as "dpkg -V" and "debsums" could miss it. ESET researcher Marc-Etienne Léveillé subsequently confirmed that version 1.8.3 had existed since at least June 2026 and published an updated detection script.
Investigation Leaves Unresolved Questions
On October 4, Tor directory authorities began applying BadExit and MiddleOnly flags to affected relays. BadExit prevents clients from selecting a relay to exit the network. By 17:00 UTC on October 5, no relay carrying the malicious policy remained in the consensus used by Tor clients.
A scripted restart subsequently affected 55 Quetzalcoatl hosts, but authorities rejected affected relays attempting to rejoin. Tor Metrics recorded approximately 370 fewer exit-flagged relays between October 3 and 5.
Investigators have not established how attackers accessed the other 58 operators' systems. Directory analysis found that 71 of 101 affected relays hosted by FranTech Solutions, associated with BuyVM, adopted the malicious policy, compared with 13 of 9,054 hosted elsewhere. This concentration raises questions about hosting-level access but does not prove the provider was compromised.
The campaign's attribution, the number of infected hosts and the number of exposed users remain unknown.
Indicators and Remediation
Operators should inspect "torrc" and included files for unauthorized changes to "ExitRelay", "ExitPolicy", "ContactInfo", "MyFamily" and "Nickname". Other indicators include unfamiliar listening processes, outbound connections, NAT rules redirecting port 22, unauthorized SSH keys, unexpected scheduled tasks and suspicious system services.
Additional Ebury indicators include the abstract UNIX socket "@event-0YsOG9WSOE", a disguised "/sbin/rsyslogd" process and the IP address "185.225.226[.]62", associated with the initial intrusion into Zimmer's management server.
Anyone who accepted an unfamiliar SSH host key and entered a password through Tor between October 1 and October 5 should treat that credential as compromised, change it and investigate the destination server.
Suspected infected hosts should be taken offline, forensic evidence preserved and systems reinstalled rather than merely cleaned. Operators should replace exposed credentials, generate new relay identities and report findings to the Tor Project's bad-relays mailing list.
The incident demonstrates that Tor's traffic-routing protections cannot guarantee the authenticity of a destination connection when a malicious exit intercepts it. Verifying SSH host keys, disabling password authentication where practical and maintaining unique credentials are essential defenses.
Attackers replaced the binary releases of OVHcloud's open-source CLI tool on GitHub with malicious builds designed to harvest secrets from developer machines, the company confirmed this week. The incident, which affected versions v0.11.0 through v0.15.0, went live on October 19 and was only caught after a customer raised an alarm about a suspicious release.
The malicious files were live for roughly 94 minutes. A customer's CI pipeline, which had a pinned SHA-256 checksum for the v0.15.0 Linux binary, failed when the hash no longer matched, and the customer opened issue #300 on the public GitHub repository. OVHcloud pulled the replaced assets at 14:21 UTC and shipped a clean replacement, v0.16.0, three hours later.
A Compromised Account, Months in the Making
The attack traced back to a single GitHub account: `HassenBF`, belonging to a legitimate OVHcloud contributor who had write access to the release repository. According to the security research group OpenSourceMalware, the account was compromised roughly seven months before the attack, with evidence pointing to early March 2026.
On March 5 and 6, four personal repositories on the account were force-pushed within a scripted window. Three of those rewrites embedded a `preinstall.js` loader file containing a payload hidden inside invisible Unicode variation-selector characters. A fourth repository inlined the same decoder into a React source file. The push cadence for the first three repositories was 42 seconds, which OpenSourceMalware interpreted as automated rather than manual activity.
After that, the account went quiet on the CLI project. It continued contributing to `ovh/ovhcloud-docs` through May to September 2026, with several pull requests merged normally. That cover of normalcy made the account hard to flag.
How the Malicious Binaries Were Built
The attacker did not touch OVHcloud's CI/CD pipeline. Instead, they built the infected packages locally and uploaded them directly using the GitHub Releases API, replacing the macOS (Intel and ARM), Linux (x86_64 and ARM64), and Windows x86-64 binaries across five versions. The i386, Windows ARM64, and WASM builds were left alone, which OpenSourceMalware read as deliberate targeting of developer and operations workstations.
Critically, the attacker also replaced the `checksums.txt` file last, so the new hashes matched the malicious binaries. Anyone who verified the checksum would still get a false sense of security.
OVHcloud CEO Octave Klaba confirmed that GitHub's release immutability setting had been turned off on the repository, which is what allowed an account with write access to silently overwrite already-published releases without triggering any CI checks. Since the incident, OVHcloud has re-enabled that setting. The v0.16.0 release is now marked immutable, meaning its files cannot be replaced.
A forensic check of the malicious binary using `go version -m` revealed it was built from a git checkout with uncommitted changes (`vcs.modified=true`), a dead giveaway that it came from a local workstation build rather than the official GoReleaser pipeline.
The Payload: A Solana Dead Drop and GlassWorm Fingerprints
OpenSourceMalware dug into the `preinstall.js` file loaded into the compromised account's repositories back in March. The loader uses a two-stage design. The first stage AES-256-CBC decrypts a hex blob, and the resulting second-stage script checks whether the victim machine appears to be based in Russia by testing language and timezone settings; if it is, the script exits after 10 seconds.
Otherwise, it contacts public Solana RPC endpoints, queries transactions from a specific wallet address, and reads a JSON memo embedded in the blockchain. That memo carries a base64-encoded URL pointing to the next-stage payload. This "dead drop" technique lets the attacker swap out the payload URL anytime without touching any code repository.
The Solana wallet in question, `BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC`, appears in public indicator lists for GlassWorm, a threat actor that has been running campaigns since late 2025 targeting VS Code, OpenVSX, GitHub, and npm. OpenSourceMalware attributes this attack to GlassWorm with moderate confidence.
Who Is Affected and What to Do
Any developer or CI pipeline that downloaded or ran the CLI through `install.sh`, the Homebrew cask, or a direct GitHub release between 12:47 and 14:21 UTC on October 19 may have been exposed. Klaba said the malware's goal was to collect secrets sitting on disk, and while he described the binary as low quality, he warned it was still capable of doing real damage.
Affected users should update to v0.16.0 or roll back to v0.10.0 immediately, but updating the tool alone is not enough. Any machine that ran a compromised version should be treated as having all its readable secrets exposed. That means rotating OVHcloud API keys, cloud credentials, SSH keys, Kubernetes configs, package registry tokens, and anything stored in `.env` files, from a separate, clean machine. Users on macOS should also check for an `~/init.json` file in the home directory, which the second-stage script writes as a throttle marker.
OVHcloud has said a full post-mortem is coming. Key questions remain open: how the developer account credentials were first stolen, whether the same actor maintained access for the entire seven months, and exactly what the final payload did before OVHcloud deleted the files.
Remote access trojan (RAT) XWorm has developed into an advanced surveillance threat whose capabilities extend beyond data theft and remote system control. According to cyber security researchers at Netskope Threat Labs, recent versions of this malware contain plugins for tracking the location of victims, capturing live audio, controlling webcams, and controlling active browser sessions.
It was discovered in 2022 that XWorm facilitated the control of compromised systems by logging keystrokes, capturing screenshots, and executing remote payloads. The malware has been modified by its developers since its discovery, adding new features and releasing updated versions. According to Netskope, 1,236 detection events were recorded across 100 customer organisations during the third quarter of 2026, representing a fourfold increase from the same period in 2025.
The malware's expansion has been accompanied by an expansion of its plugin collection. In July 2025, 35 plugins were supported, but by October 2026, 46 plugins were supported, which provided increased capabilities for monitoring and interacting with victims' devices.
A cracking of the XWorm builder and subsequent release of the source code for version 6.4 in August 2025 resulted in the wider dissemination of the malware. Since then, researchers have identified multiple versions operating in the wild, including V6.4, V6.5, V7.2, and V7.4 The malware has been modified in several ways, including code protection, delivery methods, and the ability to evade security analysis.
There are approximately 35% of affected customers that are affiliated with financial services companies, according to Netskope. The majority of reported incidents have occurred in the United States, India, Brazil, Italy, Panama, and Brazil. HBrowser plugins pose a significant security risk due to their ability to operate within existing browser sessions rather than relying on stolen passwords.
Command-and-control channels of the malware are encrypted using AES, allowing for remote mouse clicks, keyboard inputs, and other interactions with the active browser. By continuously taking screenshots, attackers can gain access to accounts already logged in and potentially gain access to sensitive information. By collecting device location data without a visible consent request, the Maps plugin adds another layer of surveillance.
Netskope's analysis shows that it attempts to retrieve GPS coordinates, but when GPS coordinates are not available, it switches to IP-based geolocation. Microphone plugins allow for recording audio from selected recording devices and transmission to operators in encrypted, compressed data chunks. In addition to webcam recording, attackers may also monitor compromised devices without displaying obvious warnings to the user using these functions.
Continued Development Raises Security Concerns
As the malware has evolved, it has also undergone changes to make analysis and detection more challenging. Recent variants have introduced stronger code protection techniques, techniques for avoiding virtual analysis environments, and modifications to payload delivery and command-and-control communication.
By expanding the plugin collection, operators have increased the range of options they have for tailoring attacks to meet their objectives. NetSkope anticipates continued development of XWorm following the public release of its builder and source code, with further development likely following that. The increasing surveillance capabilities of malware also highlight the limitations associated with multi-factor authentication alone.
An attacker who controls an already authenticated browser session on an infected device may not be able to prevent access to open accounts even when additional login verification is performed. It is recommended that security teams strengthen endpoint monitoring, investigate unusual process and network activity, and restrict unauthorised outbound communications.
Network segmentation will also allow you to limit the spread of malware across other connected systems. Detecting endpoints, monitoring traffic, and responding to incidents in a timely manner remain crucial for identifying suspicious activity and containing compromised devices before they can be exploited further by attackers.
In a statement published on October 8, 2026, Daiichi Kosho said it could not rule out the possibility that personal information stored on the affected computer had been exposed to unauthorized parties. But the company has not confirmed that the data was actually stolen or leaked.
“According to NCG, between October 1 and October 2, 2026, a malware infection was discovered on one of their employees' devices (a PC), and the device was isolated from the network on October 2. Following an investigation into the scope of the impact by NCG, we received a report from NCG on October 5,” read the statement.
After an initial investigation, NCG informed Daiichi Kosho about the incident on October 5. The investigation revealed that information collected through outsourced business operations had been temporarily stored on the compromised computer.
NCG has reset affected passwords and is investigating how the malware entered the system, whether information was accessed by unauthorized individuals, and the overall scope of the incident. The available information does not identify the malware.
Daiichi Kosho estimates that approximately 8.724 million records may have been affected. “Based on the information we currently have, approximately 8,724,000 customers who registered or made reservations at our stores may have had their names (registered names), genders, dates of birth, email addresses, and telephone numbers leaked to external parties,” the company warned.
The affected records are linked to customers who registered for membership or made reservations at the company’s establishments. The businesses include Big Echo, DK Dining, Mega Big, Karaoke Club DAM, Banana Club and B-Garage.
Daiichi Kosho has warned customers not to open unfamiliar links or attachments and to remain cautious when receiving unexpected emails, text messages or calls. The company has also clarified that passwords and credit card information are not included in the potentially exposed data.
Using fake Zoom installers, a macOS malware campaign distributes a backdoor known as CloudSyncD, a backdoor for MacOS.
Google is tightening restrictions on one of mobile malware's most persistent entry points. With Android 17, the company is limiting access to its AccessibilityService API to verified Accessibility Tools only, a change that takes effect the moment a user switches on Advanced Protection.
The move, announced Thursday, targets a problem that has haunted Android security for years. The AccessibilityService API was built to help people with disabilities use their smartphones. Screen readers, voice control apps, and motor-assistance tools all rely on it. But the privileges it carries are significant. Apps that tap into the API can run in the background, observe what appears on screen, intercept UI events, and take actions inside other applications on a user's behalf. That set of capabilities made it a target for malware developers almost immediately after it was introduced.
Google stated in its announcement that the new version automatically restricts AccessibilityService access to verified Accessibility Tool applications, closing off a major attack avenue while keeping genuine assistive technology functional.
A Clichéd Attack Path
Malware families have been weaponizing Android's accessibility services since at least 2017. The list of known offenders runs long: Vultur, SharkBot, Xenomorph, BianLian, Anatsa (also tracked as TeaBot), and more recently BTMOB RAT, a remote access trojan documented attacking banking customers across Brazil, Argentina, Spain, Portugal, and Mexico through 2025 and 2026. According to Kaspersky data, trojans accounted for 40 percent of Android malware infections in Q1 2025, with nearly 12 percent of malicious apps falling into the banking trojan category that specifically abused the Accessibility API, totaling around 154,000 apps.
The attack chain is well understood. A malicious app, typically distributed through sideloaded APKs or disguised as something routine, tricks a user into granting accessibility permissions. The Anatsa trojan, for instance, slipped onto Google Play as a PDF viewer update as recently as July 2025. Once the permission is granted, the malware operates without root access. It can monitor keystrokes, layer fake login pages on top of legitimate banking apps, approve system dialogs silently, and initiate fraudulent fund transfers from financial applications without the user noticing anything unusual on screen. Google noted in its announcement that this access also allows malware to block its own uninstallation, locking users out of any easy remedy.
What Changes in Android 17
The new restriction applies specifically when Advanced Protection is active, a device-level security mode introduced with Android 16 that consolidates multiple hardening features under a single toggle. When a user enables it, the system now automatically enforces that only verified, legitimate accessibility apps can request AccessibilityService access. Everything else is denied.
This is part of a gradual tightening that has been underway for several years. Android 13 made it significantly harder for sideloaded apps to acquire accessibility permissions. In-call protections, rolled out more recently, prevent users from granting those permissions during a phone call, cutting off a common social engineering scenario. Google also introduced the `accessibilityDataSensitive` flag to let developers mark UI elements as off-limits to third-party accessibility readers.
The Rest of Android 17's Security Updates
The accessibility change is one piece of a wider hardening effort in Android 17. Intrusion Logging, developed in collaboration with Amnesty International's Security Lab and other civil society organizations, creates a persistent, privacy-preserving forensic record of sensitive system events. Amnesty's team simultaneously updated AndroidQF and its Mobile Verification Toolkit to process the new log format, making it immediately useful for researchers investigating suspected spyware infections.
USB Protection blocks new data connections over a USB port while the device is locked, preventing physical access attacks where an attacker might attempt to extract data or push commands through a connected cable. Google has also included an option to disable WebGPU, a graphics API that has surfaced in sophisticated browser-based exploit chains. Failed Authentication Lock responds to repeated incorrect login attempts by locking the device entirely, making brute-force attempts against a stolen or seized phone substantially harder.
A fifth addition, View Supporting Apps, gives users a clear window into which installed applications have checked whether Advanced Protection is active on the device.
For developers, Google confirmed that applications can receive a notification when a user enables Advanced Protection, allowing them to switch on their own high-security features automatically for that audience.
Existing Advanced Protection users will receive a notification when the new capabilities land on their device. Intrusion Logging is not switched on by default and must be enabled manually from the Advanced Protection settings page.
Researchers at OX Security have flagged 101 npm packages that silently subscribe developers to WhatsApp spam channels the moment they are installed. The campaign abuses the open-source Baileys library, an unofficial implementation of the WhatsApp API that developers use to build customer support bots, chat managers, and automation tools, to carry out the subscriptions without any visible prompt or warning.
The packages have collectively been downloaded roughly 490,000 times, with 116,000 of those downloads occurring in the last 30 days. The single most downloaded package, `ourin-baileys`, accounts for 130,589 installs on its own, nearly a quarter of the campaign's total reach. As of publication, the majority of the 101 packages remain live on npm. Sixteen had been removed, and seven of those were pulled before researchers could review the code to determine which variant of the malware they carried.
The campaign did not begin in 2026. The oldest package in OX Security's list, `alipclutch-baileys`, was first published in October 2025. Several others date to December 2025, meaning this operation has been running quietly on the registry for close to a year before receiving a formal write-up.
Three Ways to Hide the Same Payload
OX Security researchers Nir Zadok, Moshe Siman Tov Bustan, and Vitalii Chepurko identified three distinct variants of the malware, each handling the subscription routine differently.
The first variant, found in 19 packages, fetches channel IDs from GitHub at runtime. By hosting the target list externally, operators can swap out which accounts receive new followers without ever publishing a new package version to npm. One package, `@rixxcodex/baileys`, hides the GitHub URL inside media-download code using Base64 encoding so it is unlikely to catch the eye of anyone skimming the source.
The second variant, covering 60 packages, simply embeds the channel IDs in cleartext inside the source code. Two packages took additional steps to bury this, placing the subscription logic inside an upstream connection handler and inside a file named after the Signal cryptographic protocol, a location most developers would never think to inspect.
The third variant, found in 14 packages, encodes the hardcoded channel IDs using Base64. One package in this group, `neuralwhatsapp`, takes a slightly different approach: rather than storing a channel ID directly, it resolves its target from a hardcoded WhatsApp invite code at runtime.
The Follower Inflation Business
The goal is not data theft or ransomware deployment. The channels identified in this campaign are mostly small bot-seller and marketplace accounts, largely Indonesian, where follower counts function as social proof for selling bot scripts, premium APKs, social media boosting services, and in-game resources.
Among the specific channels researchers identified: Neural has 798 followers and markets game-currency sales through a platform called JualanRSS, which deals in in-game resources including food, ore, stone, timber, and gold. MONTE-BMG has 1,000 followers. CORTANA TECH has 1,300 and points visitors to a dedicated website. Fyxzpedia.ID-Utama, with 4,800 followers, sells WhatsApp and Telegram bot scripts and bot-building services outright. One Spanish-language channel called Redes Oficiales sits at 19,000 followers and is linked to a YouTube creator, pushing back against the assumption that this is a purely Indonesian operation.
The threat actors mute these channels on the victim's device after subscribing them, so the added follower count appears organic to outside observers. A channel with thousands of followers reads as trustworthy, and that manufactured trust is the product being sold to the operators running these marketplaces.
One channel, MONTE-BMG, illustrates how the monetisation funnel actually works. It posts what appears to be a screenshotted sales negotiation in Arabic, ending with a group invite link. That link leads to a brand-new channel with only 12 followers, whose own description contains yet another group invite. The inflated parent channel is only the entry point. The actual transaction gets moved progressively deeper into a private chain of groups where there is no public record.
Beyond follower inflation, the SafeDep research team noted earlier this year that some Baileys forks in this campaign also inject the package author's advertising URL into every image and video the bot sends, a second payload the follower-count headline tends to obscure.
One Coordinated Operation, Many Names
OX Security found that 32 channels are followed by more than one package across this campaign. The single most reused channel, identified by the ID `120363400911374213@newsletter`, is targeted by ten separate packages. One remote channel list hosted on GitHub feeds five different packages simultaneously, meaning the operator can retarget all five installations by editing a single file.
Operators routinely publish near-identical packages under slightly different names to preserve the campaign when individual listings get removed. `noxleyss` and `@noxleyss/baileys`, for example, carry the same code under different publisher accounts.
Details of the abuse first emerged in August 2026 when SafeDep identified Baileys npm forks making installers' WhatsApp accounts follow attacker-controlled channels. Earlier this month, the Xygeni Security Research Team separately detailed another Baileys modification, `@dappaoffc/baileys-mod`, which subscribed developers' authenticated WhatsApp bot sessions to attacker-controlled newsletter channels.
The campaign follows a pattern OX Security has tracked on npm before. An earlier operation used the same registry to host fake Cloudflare CAPTCHA pages designed to redirect visitors to ClickFix phishing infrastructure. The registry's scale and the institutional trust developers place in what appear to be legitimate forks of known libraries make it a dependable distribution channel for this kind of abuse.
Because the packages carry none of the classic malware signatures, no API token theft, no heavy obfuscation across the board, no destructive payload, standard threat detection tools are likely to miss them entirely. That is precisely why most of these packages have remained live for months.
What Developers Should Do
Security recommends checking whether your WhatsApp account has been added to unknown channels and blocking or reporting any that appear. Developers should avoid any npm package that requires connecting a personal WhatsApp account and should add detection rules to their pipelines flagging known malicious Baileys forks. Remote channel-list URLs identified in these packages can be added to URL-reputation and threat-intelligence pipelines for ongoing monitoring.