| Alex Birsan actually published his findings for this vulnerability in Feb 2021 [1], and collected a bunch of bug bounties from various companies (Apple, Microsoft, Paypal, Yelp, Tesla, Shopify, Uber, Netflix). He was able to steal packages names for Python (PyPi), JS (npm), Ruby (Gem), where these various companies have their own private package repositories with private modules where they don't control the package names in the default repositories. The main requirements for this attack are 1. Having private repositories, where the package names in the default repositories is not owned by the owner of the package. 2. Package manager allows downloading packages from multiple repositories (the default and private repositories) without being able to pin specific package to only be downloaded from the private repositories. What's notable on his findings is the omission of Facebook and Google,
which I believe due to their usage of Buck/Bazel and monorepos for their internal codes.
Another thing to note was that Alex mainly target companies internal private packages,
while this particular instance affects an open source project which was providing package on their own repository and make use of a package (which I was not able to find any bug bounty program for). There's another post by Kjäll et.al [2] that explains how this particular vulnerabilities affects other package managers (PHP, Java, .Net, ObjC/Swift, Docker), in what conditions it's vulnerable, and how to mitigate the risk.
Two notable language package managers that were not affected are 1. Rust, mainly because you have to explicitly select the private registry for each private packages. 2. Go, mentioned as unlikely, due to the use of FQDNs in the package names and hash verification by default. I think anyone adding non default package repositories or providing one (their own private repo in enterprise setup, or 3rd party provided repositories), need to be aware of this particular class of vulnerability, and implement policy to mitigate it.
I would say, individual devs installing on their dev machines or CI/CD systems based on shell commands (rather than secured package manager setup) would be the main area of attacks mainly due to the relative difficulty of auditing those scenarios. [1]. https://medium.com/@alex.birsan/dependency-confusion-4a5d60f... [2]. https://schibsted.com/blog/dependency-confusion-how-we-prote... |
And from the engineering blog, "[...] PyTorch 1.0, the next version of our open source AI framework."[1] (emphasis mine)
[0] https://www.facebook.com/whitehat/
[1] https://engineering.fb.com/2018/05/02/ai-research/announcing...
However Meta has since ditched it[2], and a careful keyword search of pytorch.org, linuxfoundation.org, suggests there is not any current official bug bounties for PyTorch.
[2] https://pytorch.org/blog/PyTorchfoundation/