⚠ Risky-Tool Advisory Analyzed codelake triage · 2026-10-20

A security-hygiene observation, not a malware finding. This advisory documents dangerous security practices in a legitimate-purpose tool — for example transmitting credentials over plaintext HTTP, heavy code obfuscation, or automatic global installs. It is not a claim of theft, backdoor or malicious intent: the tool does what it advertises, and the risk falls on its own users and their data. It is published so operators can make an informed decision before installing or deploying it.

Advisory · CLR-2026-3670

A Baileys (WhatsApp) fork with an opt-in helper that sends looked-up phone numbers to an undocumented third-party host

@sakataoffc/baileys is a fork of the popular WhatsApp Web library Baileys. Alongside the normal WhatsApp protocol traffic it adds an exposed checkBan() helper that performs an HTTP GET of a caller-supplied phone number to a hardcoded, undocumented endpoint https://kyuux-r.indevs.in/api/check-whatsapp, stamped with an author watermark (t.me/luyatiem). This is not malware — the method is opt-in and never auto-invoked, and there is no covert exfiltration of WhatsApp credentials or session state — but a WhatsApp library quietly routing user phone numbers to an undocumented third party is a privacy/supply-chain risk for the tool's own users.

MediumRisky toolThird-party phone-number leakUndocumented endpointNo session/credential exfilOpt-in · not auto-invoked

Summary

@sakataoffc/baileys version 9.0.0 (npm) is a fork of the WhatsApp Web library Baileys. The bulk of the package is the genuine upstream library — Signal/Noise protocol, USync, media handling — and it is a legitimate-purpose WhatsApp automation library.

This advisory is about a single addition the fork makes to the socket layer: an exposed checkBan(number) method. codelake independently flagged the 9.0.0 release during routine supply-chain triage; the published 9.0.0 version is not recorded in OSV (OSV's malicious records for this package family cover earlier 1.0.0–8.0.0 releases).

Why this is Risky, not Malware

Reading the code statically (no execution), checkBan() normalises a phone number passed by the caller and issues GET https://kyuux-r.indevs.in/api/check-whatsapp?phone=<number>, returning the response annotated with creator: "t.me/luyatiem". The host kyuux-r.indevs.in is not a WhatsApp/Meta endpoint — it is an undocumented third-party server controlled by the fork author.

The decisive malware question for a trojanised Baileys fork is whether it covertly transmits the WhatsApp session or credentials. It does not: the only non-WhatsApp external host in the entire library is this one endpoint, every reference to creds/authState is legitimate upstream protocol code (pre-key upload, pairing code), and checkBan() is defined and exported but never called internally — it runs only if the library's user explicitly invokes it, and it transmits only a phone number that user passed in. There is no credential harvesting, no auto-exfiltration and no dropper.

What earns the Risky classification is the undocumented routing of user-supplied phone numbers to a third-party host baked into a widely-forked WhatsApp library — a privacy leak the tool's users would not expect. This advisory records an independent detection; it does not claim credential theft, session hijacking or a covert backdoor, none of which were found.

Indicators & characteristics

PKG@sakataoffc/baileys — npm, v9.0.0 (fork of Baileys / @whiskeysockets/baileys)

HOSThttps://kyuux-r.indevs.in/api/check-whatsapp — hardcoded undocumented third-party endpoint

APIGET /api/check-whatsapp?phone= — opt-in checkBan() helper (lib/Socket/socket.js)

TAGresponse annotated creator: "t.me/luyatiem" — author watermark

CODEcheckBan() defined ~socket.js:392, exported ~:1103, NOT auto-invoked anywhere

NEGno covert transmission of creds/authState/session; only non-WhatsApp host is the above endpoint

Response & guidance

#	Action	Priority
01	Treat phone numbers passed to `checkBan()` as disclosed to a third party. Any number you look up via this helper is sent to `kyuux-r.indevs.in`, an undocumented host unrelated to WhatsApp. Avoid the helper if that is not acceptable.	Warning
02	Prefer the upstream library. If you only need WhatsApp automation, use the maintained upstream Baileys, which has no such third-party endpoint.	Caution
03	Fork fix: remove the hardcoded third-party endpoint, or make the external lookup explicit, documented and opt-in with a user-provided URL.	Fix

Analyzed independently by codelake Research · AI-assisted triage + deterministic static code review (no execution). Classified Risky tool: a legitimate-purpose library whose added third-party endpoint endangers its own users' privacy — not malware. codelake stores only the detection rule, indicators and analysis, never raw payloads.