bx-ui-framework Authentication Malicious Package Alert

Short answer: The authoritative OSV record MAL-2026-15866 flags every published version of @bx-ui-framework/authentication—1.2.0, 15.0.0, and 16.0.0—as malicious. Check lockfiles, dependency trees, build logs, and registry caches now; remove the package rather than upgrading, because OSV lists no safe version.

The bx-ui-framework authentication malicious package alert was originally disclosed on September 4, 2026 at 01:12:20 UTC. This is a defensive guide to identifying exposure and responding without making assumptions beyond the public evidence.

bx-ui-framework authentication malicious: what was disclosed?

OSV advisory MAL-2026-15866, sourced from Amazon Inspector and maintained in the OpenSSF malicious-packages repository, identifies @bx-ui-framework/authentication as containing malicious code. Its original publication timestamp is 2026-09-04T01:12:20Z. The year is 2026, matching the current year, and the disclosure was less than 72 hours old when this alert was prepared.

The package is not a normal authentication library with an ordinary registry dependency graph. The public evidence describes a tiny package whose manifest delegates the meaningful install behavior to a dependency fetched directly from an external HTTPS host.

For version 15.0.0, the manifest declares a dependency named microfrontend from:

https://repo.artifactorymanager.com/bx-ui-framework/authentication

That is a mutable URL rather than a registry version range with a package name, version, and integrity value in the normal npm resolution flow. The advisory explains that npm can fetch whatever bytes the remote host returns and may run lifecycle scripts included in that fetched artifact. The package itself is only a minimal stub, making the remotely supplied dependency the effective payload.

Current npm registry metadata also shows external URL dependencies in the other listed versions. Do not visit those hosts or try to retrieve the remote artifacts on a normal developer workstation. The advisory is enough to justify removal and containment.

Which package versions are affected?

At the time of writing, 16.0.0 is the registry's latest tag and is also listed as affected by OSV. Therefore, running a broad upgrade such as npm install @bx-ui-framework/authentication@latest is not remediation.

This is also not the kind of problem that npm audit fix can reliably solve by selecting a patched release. There is no fixed release in the advisory. Remove the dependency, replace it with a verified alternative if the project truly needs that functionality, and treat any environment that executed the install path as potentially exposed.

How can I check whether my project is exposed?

1. Query the installed dependency tree

npm ls @bx-ui-framework/authentication --all
npm explain @bx-ui-framework/authentication

A non-empty result means the package is present directly or transitively. npm explain helps identify which top-level dependency introduced it.

2. Search every lockfile and manifest

rg -n '(@bx-ui-framework/authentication|repo\.artifactorymanager\.com|repo\.remoteknight\.com)' \
  --glob 'package.json' \
  --glob 'package-lock.json' \
  --glob 'npm-shrinkwrap.json' \
  --glob 'yarn.lock' \
  --glob 'pnpm-lock.yaml' .

Search monorepos, archived release branches, container build contexts, deployment bundles, and generated lockfiles—not just the currently checked-out application directory. A lockfile match is evidence that the package was resolved, but it does not prove that a lifecycle script ran.

3. Check CI, build, and registry logs

Review jobs and developer installs from August 27, 2026 onward, when the first listed version was published. Look for package resolution, downloads involving the package name, outbound requests to the external hosts named above, and unexplained child processes during dependency installation.

If your organization uses a caching proxy, search its metadata and cached artifacts too. A package can disappear from a workstation while remaining reproducible from an internal cache.

4. Scan an exact package or lockfile

Use the free InstallSafe package scan to check the exact dependency against known OSV advisories. You can also follow the broader npm package safety checklist for publisher, release-age, install-script, and dependency checks.

What should affected developers do now?

1. Stop new installs. Block @bx-ui-framework/authentication at your registry proxy or policy layer before another workstation or runner resolves it.
2. Identify every affected environment. Inventory laptops, CI runners, containers, build agents, caches, and release branches that used versions 1.2.0, 15.0.0, or 16.0.0.
3. Isolate systems where installation executed. Prevent further outbound communication and preserve relevant process, DNS, proxy, and build logs for incident review.
4. Remove the dependency. Delete it from manifests, regenerate lockfiles from reviewed inputs, clear affected node_modules trees, and invalidate registry or CI caches containing the package.
5. Rebuild from a known-clean environment. Recreate runners or containers instead of assuming that deleting one directory reverses everything a remotely fetched artifact may have done.
6. Review reachable credentials. The public advisory does not document a specific credential-stealing payload, so do not claim confirmed theft. However, if untrusted install-time code could have run, rotate secrets available to that process according to your incident-response policy.
7. Add a preventive control. Enforce allowlists, advisory checks, and install-time policy consistently across developer machines, CI, and AI coding agents.

A package signature or a matching registry tarball hash is not enough to make the remote dependency safe. Those controls can prove which tiny npm tarball you received while that tarball still instructs npm to fetch mutable content elsewhere.

How does a registry firewall help?

A registry firewall places policy enforcement at the dependency installation boundary. Once MAL-2026-15866 is available in OSV data, an advisory-backed firewall can deny the affected package versions before they reach developer laptops, CI workers, or autonomous agents.

InstallSafe uses OSV.dev advisory data and blocks flagged versions while serving byte-for-byte npm tarballs for allowed packages. That creates one consistent control point for npm clients without pretending to detect an undisclosed zero-hour attack.

The timing distinction matters. A behavioral-analysis product may identify suspicious external dependencies before a formal advisory exists. An OSV-backed registry firewall acts when advisory data is published and propagated. Teams with higher risk should combine behavioral review, lockfile controls, restricted lifecycle scripts, egress controls, and the registry firewall architecture described in our implementation guide.

For ongoing monitoring, compare tools and coverage in the npm malware scanner guide. The practical goal is layered defense: investigate suspicious package behavior early, then turn confirmed advisories into enforceable install policy everywhere.

Frequently asked questions

Is @bx-ui-framework/authentication safe to install?

No published version is listed as safe. OSV flags versions 1.2.0, 15.0.0, and 16.0.0 as malicious.

Can I fix this by upgrading to version 16.0.0?

No. Version 16.0.0 is explicitly included in MAL-2026-15866 and was the registry's latest tag when this guide was written.

Does a lockfile match prove the malicious code executed?

No. It proves the package was resolved into the dependency graph. Use CI logs, install settings, network telemetry, process evidence, and cache records to determine whether install-time behavior executed.

Will npm audit remove the package automatically?

Do not rely on it. The advisory lists no patched version. Remove the package and regenerate dependency state from reviewed manifests.

Should I rotate credentials?

If installation could have executed remotely supplied code, follow your incident-response policy and rotate credentials reachable by that process. The public advisory does not confirm a specific credential-stealing payload, so frame rotation as a precaution based on possible code execution.

Can a registry firewall prevent future exposure?

It can block versions after they are flagged in its advisory feed and centralize policy across developers, CI, and agents. It cannot retroactively prevent installs that happened before disclosure or guarantee detection of unknown zero-hour threats.