A research team’s path to 500 open source CVEs
The GitHub Security Lab recently crossed a notable threshold: 500 CVEs disclosed to open source projects. On its face, more vulnerability reports might seem like bad news, but for the researchers who do this work, each record represents a defect that maintainers now know about—and, in the vast majority of cases, have already fixed.
The Security Lab is a team of security experts who audit open source projects (not just those hosted on GitHub) and work with maintainers to remediate the issues they find, free of charge. That audit work feeds the team’s other efforts, including security education, improvements to its open source static analysis rules, and developer tooling.
From Semmle to the Security Lab
The group’s origins trace back to Semmle, the company behind CodeQL. In 2017, Semmle realized that its static analysis product could be a powerful vulnerability-hunting tool. The company formed a small research team that used CodeQL to search for security flaws in open source code and built LGTM.com, a portal where any open source project could run CodeQL for free and get alerts about potential issues in pull requests.
When GitHub acquired Semmle in September 2019, the Security Lab was born with a larger team and new responsibilities—including curating the GitHub Advisory Database. CodeQL found a permanent home as the engine behind code scanning and a core part of GitHub Advanced Security, remaining free for open source. The Lab has since expanded beyond CodeQL to use other techniques like fuzzing, but CodeQL remains a primary tool because it enables variant analysis at scale and lets the team share executable queries that encode knowledge about insecure patterns.
Maintainers come first
Not every vulnerability the Lab reports receives a CVE. If there’s no downstream consumer to inform—such as a flaw in a CI workflow, or a bug caught and fixed before a release—there’s no need for a record. The team has actually reported and helped fix over 1,000 vulnerabilities; the 500 CVEs are only the subset where disclosure was warranted.
What the Lab tracks most closely is its fix rate. While roughly 80% of reports in the GitHub Advisory Database are eventually fixed by maintainers, 96% of the Security Lab’s reports end up with a fix. The team credits a maintainer-first approach: flexible disclosure timelines when safe, concrete fix suggestions, help testing new releases, and an open source report template that other researchers are free to use.
Notable vulnerabilities among the first 500
CVE-2017-9805: Apache Struts RCE
This is the bug that started it all. Researcher Man Yue Mo found an unsafe deserialization flaw in Apache Struts that let an unauthenticated remote attacker execute arbitrary code. The framework was already in the spotlight because the earlier CVE-2017-5638 had been used in the Equifax breach. Mo, then on Semmle’s data science team, found the new flaw by modifying the team’s CodeQL query for unsafe deserialization.
This is the starting point for me personally. I came across this without realizing its significance when looking at the unsafe deserialization sinks. This bug helped us realize the power of CodeQL and understand how it can be used to find serious vulnerabilities that are otherwise hard to find, by customizing its dataflow sources, sinks, and steps.
CVE-2018-4407: Apple’s ICMP crash
An integer overflow in the XNU kernel’s network stack meant that a malicious TCP packet could trigger an out-of-bounds memory access and instantly crash the macOS or iOS kernel on any device sharing the attacker’s network. No user interaction was required, and the bug even had a tweetable proof of concept.
We recorded the video of the poc in our Oxford office. I modified the poc so that it could crash multiple devices simultaneously, but I made a mistake and accidentally broadcast it to the whole office, crashing all the Macs and iPhones in the office that day! People on the other floors had no idea what had happened. 😬
RCE in the Corona Warn App server
The German government’s contact-tracing application had a remote code execution flaw that would let an unauthenticated attacker fully compromise the server collecting citizens’ anonymous infection data. No CVE was issued because the app was only deployed by the German and Belgian governments, meaning there were no third-party downstream consumers to notify.
This was a novel vulnerability category we found at the Security Lab. I was researching how certain data validators, in theory used to make sure that untrusted data conformed to safe patterns, could actually be abused for the opposite purpose, and actually make the application vulnerable to a different type of attack. This research led to the publication of the Bean Stalking: Growing Java beans into RCE article and soon after we found many applications vulnerable to this vulnerability, including the Corona Warn App which we promptly reported to the maintainers.
CVE-2021-3560: polkit privilege escalation
polkit is installed by default on major Linux distributions like RHEL and Ubuntu. A race condition in its error-handling code—triggered simply by disconnecting the client too early—allowed an unprivileged local user to obtain a root shell.
Local privilege escalation vulnerabilities on Linux are often in the kernel and require some tricky code to exploit. This bug was different because it was very easy to exploit by running a few commands in the terminal.
CVE-2021-45046: Log4Shell mitigation bypass
December 2021’s Log4Shell vulnerability in the popular Log4J logging library was arguably the worst flaw ever to hit the Java ecosystem. Apache maintainers moved quickly to publish a fix, but the Security Lab found it was incomplete and reported a bypass affecting certain operating systems.
Having researched and published how JNDI injections could lead to RCE back in 2016 at the BlackHat security conference, I was shocked that such a vulnerability was hidden in plain sight for so long affecting probably the most popular Java logging library. It made me realize how separated the developers and security researchers worlds actually are and how important it is to close this gap in order to build secure software.
Script injection in GitHub Actions workflows
The team spotted emerging insecure patterns in how open source projects implemented GitHub Actions and helped fix more than a hundred instances. They also published guidelines, CodeQL queries to detect the vulnerability classes, and an open source tool that helps developers set appropriate token permissions for CI/CD pipelines. Because these flaws lived in pipeline implementation rather than shipped code, they didn’t get CVEs.
One pattern, which we coined as ‘pwn request’ was especially interesting because it was a combination of two unrelated features. When used together it led to a vulnerability.
CVE-2022-20186: Arm Mali GPU privilege escalation
This flaw in the Arm Mali GPU kernel driver allowed an untrusted app on a Pixel 6 to gain arbitrary kernel memory access, escalate to root privileges, and disable SELinux.
This bug somewhat kicked off a series of powerful bugs that exploited the memory management code in the Arm Mali GPU, which provided a very reliable and simple way to exploit the kernel, despite all the mitigations that were introduced in recent years.
Onward to the next 500
CodeQL continues to improve, with new framework modeling and acceleration from large language models. The team is disclosing vulnerabilities faster and at a larger scale than ever before. The long-term hope, however, is that education and prevention efforts will eventually catch up with audit and disclosure, and the number of vulnerabilities found in open source will start to decline. Wider adoption of code scanning, the team notes, has the dual effect of helping researchers find more issues while helping developers prevent them in the first place.
The Security Lab also invites the wider community to participate. Developers can use multi-repository variant analysis to scale their own audits by taking an insecure pattern and searching for all its occurrences in their code portfolios. They can contribute CodeQL queries back to the open source query repository, and maintainers can enable code scanning, Dependabot, and private vulnerability reporting to build first-line defenses against the next generation of bugs.
