eslint-rxjs 1.0.1 Is Malicious: Check Exposure

Short answer: The eslint-rxjs npm package version 1.0.1 is malicious, according to OpenSSF Package Analysis. If that exact package appears in a lockfile, build log, npm cache, or node_modules, remove it, rebuild from a known-clean environment, and investigate any outbound network activity from the install window.

This is a narrowly scoped alert, not evidence that RxJS, ESLint, or the legitimate eslint-plugin-rxjs package was compromised. The malicious package had a lookalike name, was created on September 1, 2026, and was removed from npm on September 2 after OpenSSF reported version 1.0.1 communicating with a domain associated with malicious activity.

What is the eslint-rxjs malicious package advisory?

OpenSSF advisory MAL-2026-15812 identifies eslint-rxjs@1.0.1 as malicious. The primary record was published at 02:11 UTC on September 2, 2026. GitHub mirrored it shortly afterward as GHSA-45hh-8cg6-r5qp.

The public advisory is intentionally limited. It says OpenSSF observed the package contacting a domain already associated with malicious activity. It does not yet describe the contacted hostname, the data sent, a lifecycle-script trigger, persistence, credential theft, or a broader campaign. Treat the network behavior as a compromise indicator, but do not invent capabilities that the primary source has not confirmed.

Which eslint-rxjs versions are affected?

The advisory names only eslint-rxjs@1.0.1. The package was new: npm registry timestamps show 1.0.0 appeared on September 1 and 1.0.1 followed on September 2. Both were later unpublished. OpenSSF has not marked 1.0.0 as affected in MAL-2026-15812, but there is no reason to retain any version of this removed lookalike package.

Do not confuse it with eslint-plugin-rxjs, a separate package with a different name and publishing history. A dependency on eslint-plugin-rxjs is not, by itself, evidence of exposure to this incident. Check the exact package key rather than searching loosely for the words “eslint” and “rxjs.”

How do you check whether a project installed eslint-rxjs?

Check source repositories, generated lockfiles, cached artifacts, developer workstations, and CI logs. The package has been removed from the registry, so a fresh install failing today does not prove that an earlier build was safe.

1. Search manifests and lockfiles. Look for the exact string eslint-rxjs in package.json, package-lock.json, npm-shrinkwrap.json, pnpm-lock.yaml, and Yarn lockfiles.
2. Inspect installed trees. Run npm ls eslint-rxjs --all, pnpm why eslint-rxjs, or yarn why eslint-rxjs as appropriate. A non-zero exit code can mean the package is absent, but confirm against the lockfile.
3. Search CI and shell history. Look for npm install eslint-rxjs, npm i eslint-rxjs, pnpm add eslint-rxjs, or npx eslint-rxjs. Include temporary preview environments and automated dependency experiments.
4. Check caches and build images. An ephemeral runner may be gone while its npm cache, container layer, or artifact remains. Search those records for the exact package name and version 1.0.1.
5. Correlate timestamps. Focus on installs between the package's publication on September 2 at 01:24 UTC and its removal at 03:18 UTC, while also checking any mirror or cache that could have retained the tarball afterward.

You can also run the free InstallSafe package scan against a package or dependency list. For a broader review process, use the checklist in How to check if an npm package is safe.

What should you do if eslint-rxjs 1.0.1 was installed?

Because the confirmed behavior includes suspicious outbound communication, respond as if code from an untrusted package executed in the affected environment until your investigation shows otherwise. The public advisory does not yet establish credential theft, so rotate secrets based on exposure evidence and the sensitivity of the machine rather than claiming a specific theft occurred.

1. Isolate the affected environment. Stop further builds and disconnect or quarantine the runner, workstation, or container if it still exists.
2. Preserve evidence. Save the lockfile, install logs, process telemetry, DNS logs, proxy records, and the npm cache before cleaning. Record the installation time and which credentials were present.
3. Remove the dependency. Delete eslint-rxjs from manifests and regenerate dependencies from a reviewed lockfile in a known-clean environment. Do not rely on deleting one directory from an already affected machine.
4. Review outbound traffic. Examine DNS and HTTP records for new or unusual destinations contacted by Node.js, npm, pnpm, Yarn, or the CI runner around the installation time.
5. Rotate exposed credentials when warranted. Prioritize npm tokens, GitHub tokens, cloud credentials, deployment keys, CI secrets, and values from accessible .env files. Revoke first, then issue replacements from a clean machine.
6. Audit for follow-on access. Review package publications, repository changes, workflow edits, cloud audit logs, and authentication events after the suspected exposure.
7. Rebuild rather than trust cleanup. Replace disposable runners and containers. For developer endpoints, follow your incident-response process before restoring access.

Why package-name confusion matters here

The name eslint-rxjs looks plausible because developers often combine an ecosystem name with a framework name. The established package many teams may recognize is eslint-plugin-rxjs. A hurried developer or an AI coding agent can choose the shorter lookalike after reading a generated command, an outdated snippet, or a hallucinated dependency suggestion.

That makes exact package identity a security boundary. Before adding a dependency, confirm its canonical name from the project's official repository, check publisher history, inspect release age, and review whether the package's files and scripts match its stated purpose. A package created hours ago with no established adoption should not enter a sensitive CI environment without review.

How does a registry firewall help with malicious npm packages?

A registry firewall places policy enforcement in the package download path. Developers, CI jobs, and AI agents continue to use normal package-manager commands, but requests flow through a controlled registry endpoint. Once an advisory such as MAL-2026-15812 is available, the firewall can block the flagged version consistently across every client rather than depending on each user to notice an alert.

This form factor is especially useful when an AI agent chooses dependencies autonomously or when short-lived CI workers are difficult to inventory. A byte-for-byte registry proxy also avoids replacing upstream artifacts while enforcing the same decision at installation time. See the practical guide to blocking AI agents from installing malicious npm packages.

A registry firewall is not a time machine. InstallSafe uses OSV advisory data, so it can block a version after that version has been flagged; it does not claim to detect every zero-hour package before disclosure. Behavioral scanners, release-age policies, disabled or allowlisted install scripts, least-privilege CI credentials, and restricted outbound network access remain important complementary controls. Review deployment options if you need registry-level enforcement across a team.

What should teams change after this advisory?

• Require exact dependency names and owner verification in code review.
• Block packages younger than a defined cooling-off period unless explicitly approved.
• Use immutable lockfiles and review every new direct and transitive package.
• Keep registry and OSV checks in CI, but remember that advisory publication can lag package release.
• Limit secrets and outbound network access during dependency installation.
• Apply the same package policy to human developers, CI systems, and AI coding agents.

Frequently asked questions

Is eslint-rxjs safe?

No. OpenSSF identifies eslint-rxjs@1.0.1 as malicious, and the package has been unpublished. Remove any version of this package and investigate installations of version 1.0.1.

Is eslint-plugin-rxjs affected?

No compromise of eslint-plugin-rxjs is described in this advisory. It is a separate npm package. Verify exact names in manifests and lockfiles.

What behavior did OpenSSF confirm?

OpenSSF confirmed communication with a domain associated with malicious activity. The public record does not yet specify credential theft, persistence, or a broader campaign.

Can npm audit find eslint-rxjs 1.0.1?

Advisory-backed tools can flag it after the malicious-package record is ingested. Historical exposure still requires checking lockfiles, logs, caches, and build artifacts.

Should I rotate every secret?

Rotate credentials that were accessible to an affected environment when telemetry is missing or suspicious network activity is present. Revoke high-impact tokens first and replace them from a known-clean machine.

Does a registry firewall prevent every zero-hour package?

No. An advisory-backed registry firewall blocks known flagged versions. Pair it with release-age rules, behavioral analysis, restricted install scripts, least privilege, and egress controls.

Last updated September 2, 2026. This article will be revised if OpenSSF or another primary source publishes additional verified indicators.