CVE-2022-29176: 
RubyGems vulnerability analysis and mitigation

RubyGems.org, a package registry for the Ruby language ecosystem, disclosed a critical vulnerability (CVE-2022-29176) on May 5, 2022. The vulnerability affected the 'yank' action, which allowed any RubyGems.org user to remove and replace certain gems without proper authorization. The vulnerability specifically impacted gems that had one or more dashes in their name, where the word before the dash was the name of an attacker-controlled gem, and which were either created within 30 days or had no updates for over 100 days (GitHub Advisory, SecurityWeek).

The vulnerability allowed attackers to exploit the 'yank' action by removing gems and uploading different files with the same name, same version number, but different platforms. For example, an attacker who owned a gem named 'something' could potentially take over a gem named 'something-provider'. The vulnerability received a CVSS v3.1 base score of 7.5 (HIGH) with the vector string CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H from NIST NVD, while GitHub assessed it as Critical with a CVSS score of 9.9 (NVD, NetApp Advisory).

Successful exploitation of this vulnerability could lead to the disclosure of sensitive information, addition or modification of data, or Denial of Service (DoS). Organizations with many gems were protected if they owned the gem with the name before the dash - for example, owning the gem 'orgname' protected all gems with names like 'orgname-provider' (GitHub Advisory, NetApp Advisory).

RubyGems.org patched the vulnerability on May 5, 2022. Users were advised to use Bundler in --frozen or --deployment mode in CI and during deploys to prevent applications from silently switching to versions created using this exploit. To audit application history for possible past exploits, users should review their Gemfile.lock and look for gems whose platform changed when the version number did not change (for example, gemname-3.1.2 updating to gemname-3.1.2-java) (GitHub Advisory).

GitLab immediately responded to the vulnerability by testing the usage of gems within their product and across their company. They confirmed that gems within GitLab.com from RubyGems.org were no longer vulnerable and found no malicious activity, exploitation, or indicators of compromise within GitLab.com and customer data (GitLab Blog).