Using CVE-2023-43641 as an example, I’ll explain how to develop an exploit for a memory corruption vulnerability on Linux. The exploit has to bypass several mitigations to achieve code execution.
On the evening of March 8, we invalidated all authenticated sessions on GitHub.com created prior to 12:03 UTC on March 8 out of an abundance of caution to protect users from an extremely rare, but potentially serious, security vulnerability affecting a very small number of GitHub.com sessions.
On March 2, GitHub received an external report of anomalous behavior for their authenticated GitHub.com user session. Upon receiving the report, GitHub Security and Engineering immediately began investigating to understand the root cause, impact, and prevalence of this issue on GitHub.com. We took initial corrective action to patch the vulnerability on March 5 and continued our analysis throughout the weekend.
The patch to resolve the bug and session invalidation resolves the issue and you may log back in at any time.
In extremely rare circumstances, a race condition in a backend request handling process could have misrouted a user’s session to the browser of another authenticated user, giving them the valid and authenticated session cookie for another user. It is important to note that this issue was not the result of compromised account passwords, SSH keys, or personal access tokens (PATs) and there is no evidence to suggest that this was the result of a compromise of any other GitHub systems. Instead, this issue was due to the rare and isolated improper handling of authenticated sessions. Further, this issue could not be intentionally triggered or directed by a malicious user.
The underlying bug existed on GitHub.com for a cumulative period of less than two weeks at various times between February 8, 2021 and March 5, 2021. Once the root cause was identified and a fix developed, we immediately patched GitHub.com on March 5. A second patch was deployed on March 8 to implement additional measures to further harden our application from this type of bug. There is no indication that other GitHub.com properties or products were affected by this issue, including GitHub Enterprise Server. We believe that this session misrouting occurred in fewer than 0.001% of authenticated sessions on GitHub.com.
Out of an abundance of caution, and with a strong bias toward account security, we’ve invalidated all sessions on GitHub.com created prior to 12:03 UTC on March 8 to avoid even the remote possibility that undetected compromised sessions could still exist after the vulnerability was patched. For the very small population of accounts that we know to be affected by this issue, we’ve reached out with additional information and guidance.
If you experience an account lockout due to being unable to complete the MFA challenge when logging back in, please refer to our account recovery process.
The security and trustworthiness of the platform is paramount to all of us at GitHub and we’re working hard every day to protect the home for so many developers. We believe transparency is critical to promoting that trust, which is why we’re sharing this publicly now, and we’ll share our root cause analysis on this issue in the coming weeks.
March 18, 2021 update: We have published our in depth analysis of this bug. Read more about how we found and fixed this vulnerability here.