5 Years, 160 Comments, and the Vulnerability That Refused to Die
How a 5-year-old deserialization flaw, a vacation phone call, and some persistence led to a safer Java ecosystem
Jonathan Leitschuh
United States
Jonathan Leitschuh is a Security Software Engineer and Security Researcher, and is currently the first ever Dan Kaminsky Fellow. Jonathan is best known for the July 2019 Zoom Video Conferencing 0-Day Vulnerability. He also championed an industry-wide initiative for JVM ecosystem artifact servers to to formally decommission the support of HTTP in favor of HTTPS exclusively. He has a degree in Robotics and Computer Science from Worcester Polytechnic Institute. His security research focuses on widespread-common security vulnerabilities impacting OSS. He enjoys finding security vulnerabilities in OSS, as well as contributing to the GitHub Security Lab Bug Bounty Program. He's a strong proponent for security researchers having and enforcing vulnerability disclosure policies. He has spoken at conferences ranging from BSides, to Black Hat and DEF CON! In his free time, Jonathan sails his Hobie Getaway Catamaran in Boston Harbor.
Community Contributions
When Open Source Isn’t: How OpenRewrite Lost Its Way
Moderne quietly relicensed community-contributed OpenRewrite code from Apache 2.0 to a proprietary license, abandoning its open source commitments. This decision risks legal exposure, undermines community trust, and sets a dangerous precedent for OSS stewardship.
WIRED: ‘Stupid and Dangerous’: CISA Funding Chaos Threatens Essential Cybersecurity Program
Collaborated with Lily Hay Newman @ Wired on this article discussing the near shutdown of the MITRE CVE program.
Falsehoods People Believe about CVE’s
CVE ≠ Vulnerability (And 35 Other Confusions Regarding CVE)
Project Safe Source: Identifying potential vulnerabilities in Wolfi upstream
TL;DR: A security scan with CodeQL of over 1,000 open source projects packaged in Wolfi found seven classes of potential vulnerabilities across 226 projects — 1,878 alerts in total — that can potentially be fixed with automated (or “bulk”) pull requests. This experiment, part of a nascent initiative from Chainguard Labs called “Project Safe Source,” represents another step toward making Chainguard the safe source for open source.
Model Outbound Vulnerability Disclosure Policy: Version 0.1
Worked with the Open Source Security Foundation: Vulnerability Disclosure Working Group to develop and publish the "Model Outbound Vulnerability Disclosure Policy: Version 0.1". This policy encapsulates the best practices of several industry disclosure policies into one disclosure policy for open source software security researchers.
Congratulations! You Found a Security Vulnerability in an Open Source Project! Now What?
After hours of puzzling over your debugger, decompiler, or pentesting toolkit, you’ve finally cracked it. The security vulnerability you strongly believed was present, almost evaded you, but now, you’ve got proof! You’ve achieved the thrill of finding a vulnerability that, hopefully, no one else on the planet knows exists!
Now the process of vulnerability disclosure can begin. But where do you start? How does this process work? How do you report a vulnerability? To whom? How do you actually get these things called CVE numbers you’ve heard so much about? What do you do if the process falters?
In this talk we will demystify the vulnerability disclosure process by presenting a recently published Open Source Security Foundation (OpenSSF) guide for open source vulnerability finders (“Guidance for Security Researchers to Coordinate Vulnerability Disclosures with OSS Projects”). From tracking down the correct place to disclose to publishing your findings so the wider world can defend themselves adequately. We’ll even discuss that pesky human element that permeates this entire process along the way, too.
Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All
I spoke at Black Hat about the work I've been performing as the first ever Dan Kaminsky Fellow.
