Auditing npm Package Maintainer Metadata for Security Gaps

Description and use

The author investigates the npm API to check for changes in package maintainer lists following the Qix security incident. It was found that the API only shows current maintainers, lacking historical data, which hinders the detection of unauthorized ownership transfers.

Problem

npm's public API provides current maintainer lists but lacks historical diffing capabilities, making it impossible to detect unauthorized ownership changes or remediation actions after security incidents like the Qix compromise.

Outcome

The investigation confirmed that npm's API returns current maintainers but no history. For packages like 'chalk', the maintainer changed from Qix to sindresorhus, but the API does not indicate when or why. PyPI and crates.io offer even less structured ownership data.

Workflow

• Identify packages affected by a known security incident (e.g., Qix compromise).
• Use curl to query the npm registry API endpoint (https://registry.npmjs.org/{name}) for each package.
• Parse the JSON response to extract the 'maintainers' array.
• Compare current maintainer lists against known pre-incident maintainers.
• Cross-reference with other registries (PyPI, crates.io) to compare metadata availability.
• Document discrepancies and note the lack of historical diffing capabilities.

Evidence

GET https://registry.npmjs.org/{name} is keyless, no auth, and returns a maintainers array

Source

Seven of ten now list a single account — sindresorhus... with zero trace of qix.

Source