GitHub has disclosed a vulnerability that allows access to the contents of environment variables exposed in containers used in production infrastructure. The vulnerability was discovered by a Bug Bounty participant seeking a reward for finding security issues. The issue affects both the GitHub.com service and GitHub Enterprise Server (GHES) configurations running on user systems.
Analysis of the logs and audit of the infrastructure did not reveal any traces of exploitation of the vulnerability in the past except for the activity of the researcher who reported the problem. However, the infrastructure was initiated to replace all encryption keys and credentials that could potentially be compromised if the vulnerability was exploited by an attacker. The replacement of internal keys led to disruption of some services from December 27 to 29. GitHub administrators tried to take into account the mistakes made during the update of keys affecting clients made yesterday.
Among other things, the GPG key used to digitally sign commits created through the GitHub web editor when accepting pull requests on the site or through the Codespace toolkit has been updated. The old key ceased to be valid on January 16 at 23:23 Moscow time, and a new key has been used instead since yesterday. Starting January XNUMX, all new commits signed with the previous key will not be marked as verified on GitHub.
January 16 also updated the public keys used to encrypt user data sent via the API to GitHub Actions, GitHub Codespaces, and Dependabot. Users who use public keys owned by GitHub to check commits locally and encrypt data in transit are advised to ensure that they have updated their GitHub GPG keys so that their systems continue to function after the keys are changed.
GitHub has already fixed the vulnerability on GitHub.com and released a product update for GHES 3.8.13, 3.9.8, 3.10.5 and 3.11.3, which includes a fix for CVE-2024-0200 (unsafe use of reflections leading to code execution or user-controlled methods on the server side). An attack on local GHES installations could be carried out if the attacker had an account with organization owner rights.
Source: opennet.ru