As usual, I read the comments here first. I'm glad I read the article though because the comments here have pretty much nothing to do with the vulnerability. He

As usual, I read the comments here first. I'm glad I read the article though because the comments here have pretty much nothing to do with the vulnerability. Here's a summary because the article actually jumps over explaining the vulnerability in the gap between two paragraphs: This service is a kind of "app store" for JS applications installed on desktop machines. Their service hosts download assets, with a small installer/updater application running on the users' desktop that pulls from the download assets. The vulnerability worked like this: the way application publishers interact with the service is to hand it a typical JS application source code repo, which the service builds, in a container in typical CI fashion. Therefore the app publisher has complete control over the build environment. Meanwhile, the service performs security-critical operations inside that same container, using credentials from the container image. Furthermore, the key material used to perform these operations is valid for all applications, not just the one being built. These two properties of the system: 1. build system trusts the application publisher (typical, not too surprising) and 2. build environment holds secrets that allow compromise of the entire system (not typical, very surprising), over all publishers not just the current one, allow a malicious app publisher to subvert other publishers' applications.