If exploited, these flaws can allow attackers to gain unauthorized access to sensitive information or generally cause problems
Few days ago, GitHub unveiled Through a blog post, the details about a vulnerability which allows you to access the content of environment variables exposed in containers used in your production infrastructure.
The vulnerability was discovered by a participant in the Bug Bounty program, designed to find security problems and reward researchers for their findings. This problem affects both the GitHub service and to the configurations GitHub Enterprise Server (GHES) that run on users' systems.
The security vulnerability, cataloged under CVE-2024-0200 with a high severity score of 7.2 (CVSS), has not been exploited in nature, It is mentioned that after analyzing the records and auditing the infrastructure, no evidence of exploitation of the vulnerability in the past was found, except for the activity of the researcher who reported the problem. However, as a preventative measure, we replaced all encryption keys and credentials that could have been compromised if an attacker exploited the vulnerability.
GitHub Enterprise Server (GHES) is mentioned to be affected, but Exploiting the vulnerability requires an authenticated user with an owner role of the organization log into an account on the GHES instance, limiting the potential for exploitation.
This vulnerability is also present in GitHub Enterprise Server (GHES). However, the exploit requires an authenticated user with an Organization Owner role to log into an account on the GHES instance, which is an important set of mitigating circumstances for a potential exploit. A patch is available today, January 16, 2024, for GHES versions 3.8.13, 3.9.8, 3.10.5, and 3.11.3. We recommend that GHES customers apply the patch as soon as they can.
Credential churn on our production systems caused a series of service outages between December 27th and 29th. We recognize the impact they have had on our customers who rely on GitHub and have improved our credential rotation procedures to reduce the risk of unplanned downtime in the future.
It is worth mentioning that The vulnerability in GitHub has been fixed and an update has been released product release for GHES 3.8.13, 3.9.8, 3.10.5, and 3.11.3, GitHub characterized the vulnerability in GHES as a case of "Unsafe use of Reflection," which poses risks of reflection injection and remote code execution (as these types of vulnerabilities lead to code execution or user-controlled methods on the server side).
The replacement of these internal keys resulted in an interruption of some services from December 27 to 29. GitHub administrators have tried to learn from mistakes made while updating keys that affect customers.
Among the actions taken, updated GitHub GPG private commit signing key which is used to sign the commits you create on GitHub. These include commits created in the web editor, through a code space, through the command line in a code space, or through pull request operations or through Codespace. The old key became invalid on January 16 and a new key has been used since then. Starting January 23, all new commits signed with the old key will not be marked as verified on GitHub. On January 16, the public keys used to encrypt user data sent via the API to GitHub Actions, GitHub Codespaces, and Dependabot were also updated.
In addition to that, Users are recommended to use these GitHub-owned public keys to verify commits locally and encrypt data in transit that ensure you have updated your GitHub GPG keys so your systems continue to function after keys are changed.
finally if you are interested in knowing more about it, you can check the details In the following link.