5 ms·
There's more: > vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization. > We deter
by xPaw 5y ago
There's more:
> vulnerability that would allow an attacker to publish new versions of any npm package using an account without proper authorization.
> We determined that this vulnerability was due to inconsistent authorization checks and validation of data across several microservices that handle requests to the npm registry. In this architecture, the authorization service was properly validating user authorization to packages based on data passed in request URL paths. However, the service that performs underlying updates to the registry data determined which package to publish based on the contents of the uploaded package file.
- brazzledazzle 5y agoThis seems like a much bigger deal. Disclosing private names is not ideal but I think you have to assume your namespace and package names will leak at some point. In my opinion you should prepare for this well ahead of time by ensuring your organization uses a unique namespace/org that matches your internal/private namespace/org and squat on it. This will prevent a supply chain attack where they take a leaked namespace/package, register it and publish packages with higher versions.