TripBFF exposed recent live latitude & longitude data and birth date for every user on their platform

TL;DR: The TripBFF App, which the founders say has over 1M downloads, 100k active users, and earns them over $1M ARR was found to be exposing exact user location and exact birthdays via an internal API to any end-user. We also found that we could move our location to any point in the world, and enumerate the local users in that area, giving us an accurate recent app-open location of every single active user on the app.

The TripBFF founders were incredibly receptive to our report and immediately fixed the identified privacy exposure. We were impressed with the rapid response by the TripBFF team. However, after initially responding warmly to the reported issues, the TripBFF team ended up ghosting us, leaving a few open and unanswered questions.

I’m currently living the life of a digital nomad, traveling the world. I’ve been looking to meet fellow world travelers. When I saw the app TripBFF mentioned in a Reddit post I got curious. I installed the app and paid for a pro account. After poking around a bit, I was confronted with a map of Seattle with location pins of everyone using the app in the City.

While the app’s map prevented users zooming in far enough to get an accurate location on other users visually, my security research spidey sense was saying, “Huh, that location pin for me looks surprisingly accurate, I wonder what the client is receiving on the backend”. I was concerned that the zoom fidelity filter was only at a visual level within the app; so, I decided to take a deeper look.

Enter Adam Baldwin (aka. EvilPacket)

Adam and I have been friends since 2019. We first met at Microsoft’s micro-conference Package Con where a bunch of package maintainers came together to discuss the security of packaging ecosystems. At the time, I was representing Gradle, and Adam was representing pre-acquisition NPM. Over the years, I’ve called Adam up when I’ve been in over my head and have always appreciated his mentorship and support. Adam lives in the greater Seattle area, and since I was in town, I figured I’d drive up to see him. I mentioned to him this app that I’d found earlier in the day and my curiosity regarding the map and we decided to sit down and take a crack at it.

Hacking TripBFF

I’d never tried any form of mobile hacking before, so this was an awesome opportunity to get my feet wet with someone more experienced than myself. In order to just get a bit of information regarding what internal tooling/libraries we were working with I decided to take a quick peek at the iOS application. Initial pass was to download the iOS binary ipa file with a helpful tool called ipatool (majd/ipatool). This gave me insights into the libraries being used under the hood, including nanopb, Google Firebase, and MapBox for map rendering. I was thinking that in order to do any dynamic testing, I was going to need to work with the app with something like Corellum, but Adam said "why don't we just intercept the traffic with BurpSuite". This isn't something I'd ever done before but after following PortSwigger's rather short and straightforward guide I was seeing HTTP traffic from my phone!

Aside: If trying to reproduce this, ensure you’re not on a WiFi network at an internet cafe or library. Many public networks, and home guest networks — if securely configured — will have client isolation enabled, meaning this will not work. I tried to figure out how to make this work with TailScale, unfortunately without success. Late into this research I discovered ProxyMan for iOS that allows you to do this sort of on-device HTTP request/response inspection and rewriting without needing to route your HTTP traffic through your computer.

Findings

Although I’d chosen to sign up for the TripBFF premium trial, Adam did not. As such, we got the opportunity to observe how the application behaved differently between the two of us.

Looking at all the requests, we quickly saw the primary authentication mechanism for the back-end servers is a JWT token sent in the Authorization: header. This is generally easy to spot when you see a long string of characters that begin with eyj or even just ey.

You’re initially ”shadowBanned”: true

One of the first requests Adam saw was a call to POST /checkShadowbanStatus which, for his account, seemed to initially return "shadowbanned":true. Adam used a simple Burp find-and-replace rule to configure the proxy so that the endpoint always returned "shadowbanned":false instead. We believed that this would begin to unlock functionality of the app.

Ethan Brimhall, TripBFF's CTO stated that: "This has nothing to do with paying customers and new users are not initially shadowbanned. We have an extensive algo to determine if a user is "spam" that is checked on every app open. Additionally, the "result" from that function does absolutely nothing client side. It's always validated on the server." Given this context from Ethan, we're not sure why the client makes a request for this API, but regardless, the API is one of the first API calls made when the app initially opens.

Request

Response

Location Data Sent to TripBFF Servers

After the POST request to /checkShadowbanStatus, the next interesting request we see sent from the TripBFF app to the backend servers is a POST request to /updateLocation. This seems to be how the app tells the TripBFF servers where you are in the world both via the 7 digit "geoHash", and the "latitude" and "longitude" values. The "neighbors" are also the neighboring geohash values of the 4 digit geoHash area surrounding the more precise "geoHash" value.

Request

Response

Exposing Location Data that is waaay too Accurate

One of the first things we spotted was a POST request to /fetchNearbyUsers. This POST request takes four arguments: isPremiumUser, latitude, longitude, and geoHash. The latitude, longitude, and geoHash values come from the user's current location, except when they've used the in-app "Teleport" feature to move to a different location. Of course, for Adam isPremiumUser was false but for me, it was true. Again, with another few configuration tweaks to the Burp Proxy, and any proxied requests to /fetchNearbyUsers would automatically get set to true.

Request

Interestingly, isPremiumUser is not validated by the backend. Adam, aka "Joe McPwnerson", still running the app through a proxy, and having not paid for the app, set it to true to get full user data on any account without paying for it. In Burp Repeater, Adam set up an interceptor rule that replaced all "isPremiumUser": false with "isPremiumUser": true.

As a non-premium user, any user could easily reproduce this with a ProxyMan rule on your device, replacing the request data on every call, thus always returning more rich information, even if you weren’t paying for premium. However, a ProxyMan license costs $99/year if you’d like to continue to receive updates, which is more than TripBFF costs at $55.99/year.

Response

With Adam sitting right next to me, using the /fetchNearbyUsers API I was able to locate his user account in the list. I quickly grabbed the latitude and longitude data out of the entry tied to his account and dropped it into Google maps. Turning the Google Maps screen around to face him, I asked:

“That location pin is directly on your house, isn’t it?”

To which Adam replied with both a grimace and a laugh…

“Yes… Yes it is.”

Further, we were able to manipulate the latitude and longitude values in the POST request to /fetchNearbyUsers. This could have allowed us to scan the entire globe for the most recent app-open location of every single user of the app, without physically moving ourselves.

Because the TripBFF services introduced no randomization/jitter into the data sent to their services, and this exact data is retrievable by any other user, all users were able to view the exact location where any user last opened the app.

Additionally, the /fetchNearbyUsers response returns, in Seattle, a list of ~10 users. However, the app then makes another call to /fetchNumberOfNearbyUsersLast30Days which at time-of-writing, returns 224 users with each element containing both a filled out latitude and longitude value as well as realLatitude and realLongitude values.

Interestingly, these two latitudes and longitudes are different from one another, usually starting at the decimal point. It’s not clear to me what these different values are intended to represent and why they deviate so far from one another.

The Security Protection That Won’t Save You

The app has a “Hide my nearby distance” feature that you can use to hide how close/far you are from another user. This is disabled by default but can be enabled by a user, presumably for additional security protections.

Unfortunately, this security protection had a critical security flaw. While the "distanceKM" and "distanceMI" values are changed to "Nearby". The "realLatitude" and "realLongitude" values continue to expose the exact latitude and longitude of the user.

Below is a sample POST /fetchNearbyUsers response for a user with "Hide my nearby distance" enabled. Again, bogus but realistic latitude and longitude data.

Response

Basically, even when you had “Hide my nearby distance” enabled, your exact location data was still being leaked.

Saving Grace

As far as we can tell, the iOS app only updated your location (by sending a POST to /updateLocation) when you initially open the app, so as long as you're actively moving you shouldn't be easily trackable. However, if you're using the app at home, hotel, AirBnB or hostel, you'd be easily traceable to your exact location.

I Know Your Birth Date

The birthday in the response from /fetchUserProfile, unfortunately, exposed the full user's birthday using the unix epoch date that was provided during app sign-up.

Request

Response

Throwing the "birthday"."_seconds" value of 337404978 into an epoch converter, we are quickly able to determine that value maps to Wednesday, September 10, 1980, Joe McPwnerson's fake birthday used at account creation.

Stealing Data En-Mass

Since the /fetchNearbyUsers endpoint allows you to set the location you'd like to search, it would be rather easy to create a script to walk the planet, searching the app's databases for every single active user and exfiltrating that data. If this behaviour were to go undetected by the TripBFF developers, this could be used by third parties to track the locations of users of the TripBFF app on a near continuous basis.

The out-of-date Privacy Policy

In reviewing the TripBFF Privacy Policy (WayBack Machine: September 19th 2025) we found no mention of the fact that TripBFF collects location information. Although the iOS app does list that location data may be collected. Obviously, in order for the app and service to function properly, it must be collecting and storing user location information.

I pointed out this gap between the Privacy Policy and the app’s obvious feature set to the TripBFF team, and while it was confirmed that they planned to fix this, as of the date of publication, the Privacy Policy has yet to be updated. Although I’m not a lawyer, I would assume that not explicitly stating what/how location data is being used for their EU users is likely a potential GDPR violation.

Proposed Fixes

When reported to the TripBFF team, we submitted the following proposed fixes for the identified data exposures:

• Fifteen decimal precision on latitude/longitudes is completely unnecessary to be sending to a backend server. Limit the accuracy to two decimal places of real data, with a third decimal place should be randomly generated, to create some skew/anonymization.
• All geohash values should be reduced to a maximum of 6 characters of precision. This would limit the granularity to a cell ≤ 1.22km width x 0.61km cell.
• Don’t send the full epoch birthday value back in the /fetchUserProfile response.
• Implement rate-limiting for users that request data from the /fetchNearbyUsers endpoint too quickly as this could be an attempt by a malicious actor to scrape data from the API.
• “Hide my Distance” should pin the user’s location to the center of the nearest city, or do more to fully anonymize the location of the user that has enabled this setting.

Response by the TripBFF Team

The TripBFF team was incredibly receptive to our report. I initially reached out by simply asking where to report security issues like this to the team, and Ethan, the CTO, responded within 6 min of my having reached out.

Immediately upon receiving our full report the TripBFF team pushed to prod a change to skew the coordinates returned from the backend when fetching /fetchNearbyUsers as a short-term fix. They also committed to shipping an iOS update that would collect far less accurate coordinates (although as of November 18th, 2025 this has not occurred).

Further GET requests from /fetchNumberOfNearbyUsersLast30Days will no longer return the exact user's coordinates anymore. Coordinates now snap to a 1 km grid, and add a + or - 400 m jitter. This jitter has a minimum offset from the true location, and the jitter rotates daily. One concern that does arise from this solution is the question as to if it’s sufficient if the user lives in an incredibly rural area, or is, for example, hiking deep in the wilderness. There are only so many places someone could be along a linear trail, so 1km ± 400m might not be sufficient in all cases.

Additionally, the updates to the server also fix accounts so if “Hide My Nearby Distance” is enabled, the API will always just return 0.0, 0.0 instead of the real coordinates.

Finally, a change was pushed to the server to skew the birthday value returned, until they were able to push an iOS update to accept a returned “age” rather than a full date of birth.

Overall, these seem like adequate changes that add reasonable privacy protections for users while still offering the user experience desired by the app users. Overall we were impressed with TripBFF’s reception to our report and commend them on their fast response to quickly address the security concerns we raised.

All that being said, the TripBFF maintainers promised that they would “Reduce the accuracy of the coords being sent in /updateLocation POST”. However, as of writing, this fix has not materialized into any release I’ve tested. The data being sent to the TripBFF servers is still incredibly accurate latitude and longitude data. While not a concern if you trust TripBFF, this is something you should be aware of.

Areas for Further Exploration

We believe that the chat functionality may be leveraging gRPC using nanopb buffers. Using burp we were unable to proxy any of the traffic for any of the chat functionality in the app. We were curious what additional functionality within the app we could unlock, but was beyond what we were willing to explore in the time we had.

Conclusion

Given that TripBFF does collect user location information, if you’re concerned about your privacy, I’d advise not sharing your location data with the app. Additionally, I’d suggest that you be smart about location sharing, linking Instagram & TikTok to your physical location can be risky if you’re in an at-risk population. You want to be even more careful if you’re planning on traveling to a very remote location, as it will be much easier for other users to locate you even with the skew randomization introduced. All that being said, sharing your location is kinda the whole point of the app, and a core feature of what makes it fun to connect with other travelers, so just understand the risk you’re signing up for.

Overall, I’ve been pretty impressed with the TripBFF app. The UI design was very clean and user friendly. As a world traveler, I’ve personally found it to be a fun and useful tool for meeting other travelers while exploring the world, especially in Europe. However, as with everything, the devil is in the implementation details. Just a brief dive into the internal interactions between the app and its backend servers were enough to quickly reveal the exposure of sensitive user information for other users. It’s imperative that developers releasing applications like this get their apps professionally pentested by third parties to see if they are exposing their end-users to data theft, especially when working with live or close-to-live location information.

📣 I’m on the Market

Like what you read? I’m currently exploring my next opportunity in software security, open source, or developer tooling. If this kind of work resonates with you, I’d love to connect.

• 📧 Email: Jonathan.Leitschuh@gmail.com
• ⛓️ LinkedIn: https://www.linkedin.com/in/jonathan-leitschuh
• 📅 Schedule Time: https://calendly.com/jlleitschuh
• ☕️ Buy me a coffee: https://buymeacoffee.com/jlleitschuh

Digital Travel App TripBFF Exposed Location Data Way Too Accurately was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

The bureaucracy of the CVE system continues to frustrate me. Next up: the publicly disclosed vulnerability 72 hour rule!

In theory: you should be able to get a CVE assigned for a publicly disclosed security vulnerability within 72 to 144 hours of a CNA being made aware of it.

In practice, here’s how the world really works.

The 72 Hour Rules

There are three 72 hour rules that cover CVE assignment and disclosure for publicly disclosed security vulnerabilities: 4.2.1.2, 4.5.1.4, & 4.5.1.6.

Let’s say that, as a security researcher, have been made aware of publicly disclosed security vulnerabilities impacting multiple vendors, all in basically the same way. And you’d like to get multiple CVE numbers assigned for those impacted vendors.

Well, who’s best equipped to handle this mutli-vendor disclosure? In my experience CERT/CC. CERT Coordination Center (CERT/CC) is the coordination center of the computer emergency response team (CERT) for the Software Engineering Institute (SEI), a non-profit United States federally funded research and development center. CERT/CC has a tool called VINCE for handling multi-vendor security vulnerability disclosures.

But what happens if CERT/CC doesn’t assign CVEs in the 72 hour window? Then based upon my initial reading of the rules, you should be able to appeal to MITRE as the Root CNA.

With a cursory read of the CNA rules, you’d think that it should be relatively easy to get timely CVE number assignment for publicly disclosed vulnerabilities, ideally within 72 hours. Let’s take a look at the CNA Operational Rules:

4.2.1.2 For Publicly Disclosed Vulnerabilities, if the CNA with the most appropriate scope:

1. preemptively documents that it will not assign, or

2. responds within 72 hours that it will not assign, or

3. does not respond within 72 hours,

then an appropriate Root MUST make a Vulnerability determination. If the Root determines that one or more Vulnerabilities exist, the Root MUST direct a CNA-LR or another CNA with appropriate scope to assign as quickly as possible and no later than 72 hours after becoming aware of the first refusal. Ownership of the CVE Record MAY be transferred.

In my case, I believed CERT/CC to be the CNA with the most appropriate scope. CERT/CC’s scope for CVE assignment is “Vulnerability assignment related to its vulnerability coordination role.” Unlike many other non-supplier CNAs, CERT/CC does not have a clause in their scope that forbids assignment of CVE’s in another CNA’s scope. However, at first CERT/CC at first did not respond to my request for CVE assignment within 72 hours, and then later communicated they would not assign.

MITRE’s Response

As I learned from MITRE 4.2.1.2 does not seem to apply if you involve CERT/CC in CVE assignment as MITRE in an email on the 29th of August to me said that “4.2.1.2 relates to Supplier CNAs and CERT/CC is not a Supplier CNA.” In my personal opinion, it does not, the rule nor surrounding rules nowhere mentions “Supplier CNAs”.

Some individuals who were directly involved in the 4.0 rules change process disagree with MITRE’s current interpretation. Their view is that “appropriate scope” was deliberately left broad, intended to include organizations like CERT/CC, and that limiting 4.2.1.2 to supplier CNAs was never the intent. From this perspective, the ambiguity in the rules is less about exclusion and more about under-definition.

“appropriate scope” was deliberately left broad, intended to include organizations like CERT/CC, and that limiting 4.2.1.2 to supplier CNAs was never the intent

MITRE has also said on the 9th of September “4.2.1.2 only applies in a situation where there was a CNA with most appropriate scope, and that CNA either didn’t respond or indicated that it is a valid vulnerability but they are not assigning, none of that is true in this situation, and therefore there is no 72-hour timeline.”

The insanity of the whole thing is that, according to MITRE, there must exist a CNA with an “appropriate scope” to dispute with in order for the 72 hour CVE assignment to apply. Otherwise, MITRE, as the Top-Level Root, is under no obligation to do anything in a timely manner. And the industry is left with a publicly disclosed security vulnerability floating around for god knows how long without anyone actually being required to act diligently upon it. The current set of circumstances, at least MITRE’s reading of it, that must arise for 4.2.1.2 to actually be useful, is far too narrow.

The industry is left with a publicly disclosed security vulnerability floating around for god knows how long without anyone actually being required to act diligently upon it

Meanwhile, 4.5.1.4, & 4.5.1.6 both require that an undisclosed CVE number has been already assigned, so if you can’t convince anyone to assign CVE numbers to your publicly disclosed security vulnerability, you’re shit outta luck!

So, next time you’ve got a publicly disclosed security vulnerability that you want a rapid CVE assignment on, be prepared for MITRE’s response of… “yea whatev’ man… we’ll get to it someday”.

FAQ

What was the vulnerability that CVEs were being requested for?

Browser plugin password manager clickjacking vulnerabilities disclosed by Marek Tóth at DEF CON on August 9th, 2025.

Did you submit CVE data to MITRE and CERT/CC?

Yep. Here’s the link to the original GitHub gist.

Have the vulnerabilities been fixed?

According to Marek Tóth, all of the impacted vendors have since published fixes for the identified vulnerabilities, except for 1Password. 1Password has added mitigations that are not enabled by default.

TL;DR?

CERT/CC stated on September 2nd, 2025 that they would not assign CVEs for these publicly disclosed security vulnerabilities. MITRE still won’t assign per their role as CNA-LR.

The CVE CNA 72 Hour Rules are Insane was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

What does it take to sweep up after the industries security vulnerabilities that have been left unpatched or undisclosed?

A while ago, I changed my job title on LinkedIn to OSS Vulnerability Janitor.

It perfectly captures the kind of work I find myself doing over and over again in the OSS software industry: quietly cleaning up security messes that shouldn’t still exist — things that fell through the cracks, or were swept under the rug, or never properly acknowledged in the first place.

I love reading security vulnerability disclosures. I love digging into how software breaks in insecure ways. I enjoy reading the patches to understand how, and why the patch was implemented the way it was. But what I started noticing, over and over again, is this: a lot of OSS vulnerabilities don’t get fixed. Or they get do fixed, but quietly, but without a CVE. Or they get patched around downstream, while the root cause in a shared open source dependency stays vulnerable.

So I started doing something about it. I started sweeping up the vulnerabilities.

The CVE Machine

The CVE system is like this giant machine. Once a vulnerability is assigned a CVE, it enters a pipeline that kicks off a global process of disclosure automation. Security teams take notice. Tools like GitHub’s Dependabot and Mend’s Renovate light up and begin opening pull requests. Vendors start patching. Downstream consumers get alerts. The machine begins to churn.

But here’s the unfortunate nature of the beast: if a vulnerability never enters the pipeline, it often never gets fixed. It doesn’t show up in dashboards. It doesn’t raise alarms. It doesn’t exist in the industry’s shared mental model of “what we should be worried about.”

If you maintain open source software, do security research, or hunt for vulnerabilities, one of the highest‑impact actions you can take is to make sure the vulnerabilities you find actually get fixed downstream is by getting them assigned a CVE ID.

Getting a CVE assigned is often the critical step in protecting end users. It’s how the industry declares: this matters.

The Case of Graphite (and the SSRF That Lingered)

One of the first times this really hit me was when I revisited a 2017 critical remote code execution vulnerability discovered by Orange Tsai in GitHub Enterprise. It was a spectacular exploit chain, and GitHub had rightfully paid a hefty $5,000 bounty for it.

But years later, I went back to look more closely at the individual components of the chain. One of them involved a library called Graphite. I dug into it and realized: the vulnerable behavior was still there in the open source code.

GitHub had addressed the issue in their product, sure. But the underlying OSS library hadn’t been touched.

So I reached out to the maintainers in 2019 and said, hey, this SSRF is still live (link). Their response? “Oh yeah, we don’t even use that part of the code anymore. We can just remove it.”

And they did.

But how many people had unknowingly built software on top of that vulnerable code in the years since? How many more GitHub Enterprises were out there, quietly vulnerable, instead of benefiting from an upstream fix?

This is what I mean by janitorial work.

The Eclipse Theia RCE

Another case that stuck with me involved a serious vulnerability in Eclipse Theia — a security researcher, @omespino, hunting against Google’s bug bounty program discovered a way to escalate from an XSS to full root access in Google Cloud Shell, which happened to be using Eclipse Theia under the hood. The write-up was published October 1, 2020.

Google patched it. And issued a $5,000 bounty.

But the vulnerability? Disclosed without a CVE. No advisory. Crickets from Eclipse.

In February of 2021, a full four months after disclosure, I ended up chasing down the vulnerability through GitHub issues, mailing lists, backchannels at Google, and eventually almost escalating to the MITRE CVE dispute process.

This was one case where I found myself quite frustrated with both the Google and Eclipse CNA team. This vulnerability had been exploited in the wild. It had been public since the beginning of October. However, the Eclipse Foundation had a policy of only assigning CVEs if the maintainers requested them explicitly. And the maintainers were unresponsive. The only thing standing between the industry and coordinated disclosure was… bureaucracy.

I care deeply about this work, and seeing bureaucracy get in the way of informing end-users about vulnerabilities in their OSS components drives me a little crazy.

After my pushing, a CVE (CVE-2020–27224) was finally assigned.

The Real Work: Monotony, Not Glory

Vulnerability research isn’t always the thrilling, hacker-movie stuff people imagine.

Frequently, it’s about:

• Waiting out a 90 day disclosure timeline, and hoping the world doesn’t catch on fire in the meantime
• Chasing unresponsive maintainers and vendors
• Submitting a GitHub issue, then sending an email, then another follow up email
• Writing and rewriting an advisory to make it clear enough to matter
• Dealing with the sometimes insane bureaucracy of trying to get a CVE assigned
• Arguing with a CNA about why a CVE should be assigned

One critical thing I’ve learned is that it’s about closing the loop — making sure vulnerabilities are actually fixed, documented, and known to the broader community.

That work is often thankless. It’s slow. It’s annoying. And it’s absolutely critical.

The SAST Noise Problem (and Why I’m Trying to Delete Alerts)

One of the most frustrating things in security tooling — especially static analysis (SAST) — is how much noise we’ve normalized.

In many cases we’ve built this whole industry around flagging the symptoms of insecure defaults rather than fixing the actual root causes.

We see the same footguns pop up again and again in SAST output because the underlying libraries and APIs were never hardened. Why are we training engineers to duct-tape around dangerous behavior in libraries instead of fixing the damn thing upstream?

That’s one of the things I try to do now: follow the alert upstream, figure out why it exists, and patch the real bug.

It’s slow. It’s messy. It’s janitorial.

But every time a dangerous default gets fixed at the source, we eliminate hundreds or thousands of future alerts. We make security better for everyone — quietly, invisibly.

unCVEed: Feeding the Machine

This problem is pervasive, and it’s something I keep running into again and again and again.

That’s why I created unCVEed — a project to document and track publicly disclosed vulnerabilities that likely should have CVEs but don’t. It’s a public triage point, a staging area, and a signal boost for overlooked security issues.

My goal is to raise awareness of vulnerabilities, build pressure, and eventually help push these issues through the CVE system so they can trigger the machinery that leads to actual remediation.

If you know of a vulnerability that hasn’t gotten the attention it deserves — if the system missed something — please consider opening an issue.

Why We Need More Vulnerability Janitors

So why isn’t this kind of work more common?

Because it’s hard. It’s draining. It’s slow. You need tact and persistence and empathy and sometimes a thick skin.

Most devs are being paid to ship features, not fix industry-endemic issues.

You have to convince maintainers — often volunteers — that a feature they lovingly built is actually dangerous. That an API they designed ten years ago is actively harming people. That the impact of their decision isn’t theoretical — it’s dozens of CVEs, hundreds of security hours wasted downstream, and thousands of developers confused.

You have to have that conversation with kindness, but also conviction.

It’s not glamorous. But if we want the open source ecosystem to actually get better — not just shuffle risk around — we need more people doing this work.

Why I Do It Anyway

I love open source.

I love that the same project can power a Fortune 500’s flagship product and help a high school student learn how to code.

That kind of scale and accessibility is magical. But it also means we owe it to the ecosystem to make sure it’s safe.

That’s why I keep doing this work — even when it’s exhausting. Even when it feels like yelling into the void.

Because someone needs to.

Are You a Vulnerability Janitor Too?

If this resonates with you — if you also find yourself cleaning up long-forgotten security issues, chasing down unpatched footguns, or yelling into the CVE void — you might be a vulnerability janitor too.

You’re not alone.

I’m involved in the Open Source Security Foundation (OpenSSF), (join us on Slack) particularly in the Vulnerability Disclosure Working Group. If this kind of work speaks to you, we’d love to have you join us. Or just shoot me a message. I’d love to hear your story.

We need more janitors.

Because if we don’t clean up the messes, who will?

📣 Let’s Chat!

If you found this post insightful reach out, I’m always curious to hear about software security, open source, or developer tooling. Happy to hop on a call to connect!

📧 Email: Jonathan.Leitschuh@gmail.com
⛓️ LinkedIn: https://www.linkedin.com/in/jonathan-leitschuh/
📅 Schedule Time: https://calendly.com/jlleitschuh

What’s an OSS Vulnerability Janitor? was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

🔥 The supply chain bug that couldn’t be ignored — so I torched it

Introduction: A Typo That Could Compromise the JVM

In 2019, while debugging one of my own builds, I noticed something odd. The build was resolving dependencies over http:// instead of https://. Just one character off — a typo. Harmless? Not quite.

That tiny misconfiguration opened the door to a broader realization: the Java ecosystem was riddled with this insecure dependency resolution pattern. This wasn’t just my build. It was absolutely everywhere.

The vulnerability itself was simple: if you could man-in-the-middle an HTTP connection, you could inject malicious code into thousands of Java builds. And worse, some of the biggest names in the ecosystem were affected: JetBrains, Apache, Red Hat, Spring, Jenkins, Gradle, ElasticSearch, and many more.

That single character typo led me down a wild multi-year rabbit hole — one that started with uncovering an industry-wide supply chain vulnerability, and ended with a simple mission: driving coordinated changes across artifact hosts, build tools, and open source projects to eliminate the vulnerability class entirely.

This is the story of how I did it — and what I learned along the way.

Part I: Understanding the Threat — Dependency Resolution over HTTP

Dependency resolution is at the heart of every build system. When you build a Java project, tools like Maven and Gradle fetch external libraries — often from public artifact repositories like Maven Central, JCenter, or custom corporate mirrors. These dependencies are downloaded and cached locally.

But for years, many of those download URLs, hard coded in build systems, were configured using plain old http://. No encryption. No integrity checking. No other guarantee the content came from who it claimed to.

Incredibly, back in 2012, Sonatype charged a $10 donation fee for projects to be allowed to use HTTPS with Maven Central (source) — a barrier that predictably saw little adoption.

In 2014, Max Veytsman wrote about this in his excellent post How to Take Over the Computer of Any Java Developer. His tool, Dilettante, was a proof-of-concept proxy that injected malicious payloads into JARs as they were downloaded over HTTP. It simply rendered a picture of a cat. It could’ve just as easily delivered malware. This blog post, and the resulting outcry, finally pushed Sonatype to offer HTTPS for-free to everyone.

However, years later, many of the same vulnerabilities were still present — not due to malice, but due to typos, insecure defaults, and bad copied & pasted code. After extensive GitHub searches I found the problem was very much still alive, and it was everywhere!

Part II: Enlisting the Artifact Hosts — Shutting the Door for Good

One of the earliest realizations I had was that even if developers fixed their projects and tools improved their defaults, it wouldn’t matter if the servers still allowed insecure downloads. The problem needed to be addressed at the very foundation: the artifact hosts.

So I reached out to the largest public artifact hosts in the JVM ecosystem — Maven Central (Sonatype), JCenter (JFrog), the Gradle Plugin Portal, Spring, JetBrains, Eclipse, and Red Hat — and proposed a coordinated timeline to block all HTTP-based artifact downloads.

To my surprise, many of them agreed.

By January 15, 2020, Maven Central, JCenter, and Spring had all shipped changes to reject HTTP requests. This was a massive milestone. It meant even if a user or build tool tried to fetch dependencies over HTTP, it would simply fail.

This move was covered in official blog posts from:

• Gradle
• Spring
• JFrog
• Sonatype

It was one of the clearest examples of the ecosystem coming together to shut a door — not just for new code, but for old habits and bad defaults.

Aside: Between the start of this research and the January 15, 2020 cut-off, I’d joined Gradle’s security team. That gave me the surreal experience of being the one to actually pull the plug on Gradle’s support for HTTP.

At the time the shutdown occurred, Sonyatype noted that they were still seeing 20% of their traffic still using HTTP. On and after January 15th, 2020, there were several confused StackOverflow posts asking why builds were suddenly failing.

Part III: Shifting the Foundations — Changing the Build Tools Themselves

Once artifact hosts began shutting off HTTP support, the next logical step was ensuring that the build tools themselves would reinforce this security posture. Fixing infrastructure was important — but, as CISA notes in their “Secure by Design” initiative, fixing the developer defaults is just as critical.

🐘 Gradle

While working at Gradle, I authored PR #10065 to introduce a strict mode that required developers to explicitly opt in to resolving dependencies over HTTP. This change ensured that a one-character typo (http:// instead of https://) could no longer silently open a security hole — it had to be intentional.

🔧 Bazel

I reached out to the Bazel team at Google and filed issue #8607. Their response was the creation of the flag:

--incompatible_disallow_unverified_http_downloads

This flag blocks HTTP downloads unless a checksum is provided or a fallback HTTPS URL is available.

🛡️ SBT

I also engaged the maintainers of the Scala build tool, SBT, filing SBT issue #4905. They too responded positively and shipped changes to mitigate the same HTTP repository injection risks.

Each of these tools implemented different mechanisms — opt-in flags, verification requirements, or outright blocks — but the goal was the same: secure-by-default builds that reduce the blast radius of a typo.

Part IV: Cracking the Toughest Nut — The Apache Maven Saga

While Gradle, Bazel, and SBT responded with relatively swift and thoughtful fixes, Maven proved to be a far harder challenge.

In late 2020, I began a coordinated disclosure process to report a critical issue in Maven: transitive repository injection. Maven projects could inherit http:// repositories from dependencies without the developer even realizing it. It meant you could write a perfectly secure POM — and still get compromised.

My colleague at Gradle, Cédric Champeau, authored a proof-of-concept, and I submitted it while engaging in the back-and-forth disclosure process with the Apache Security Team and the Maven PMC. The back-and-forth stretched across months. Emails went unanswered. Conversations stalled. Multiple reminders were sent. At one point, I had to loop in CERT/CC to escalate.

Meanwhile, I wrote code to scan the entire Maven Central index — parsing millions of POM files to identify real-world usage and generate a list of affected coordinates. The results were staggering. Over 100,000 libraries were affected. Mend later published a public write-up summarizing the issue and its implications, which you can read here: Maven Security Vulnerability: CVE-2021–26291.

Eventually, after significant pressure — and after weeks of unanswered emails, stalled conversations, and repeated follow-ups — I wrote to the ASF security team:

“What fundamentally disturbs me here is that all of us as individuals, and the companies we work for… all play a critical role in protecting the supply chain of the JVM ecosystem. To that end, we’ve all failed in some way here… This game of ‘not my problem, it’s yours’ does nothing to protect users.”

I believed this issue was real. And someone had to push to get it fixed.

CERT/CC eventually threatened to go over the Apache Security Team’s head and issue a CVE for the unpatched vulnerability. This threat finally spurred the Apache Maven team into action. Apache Maven issued CVE-2021–26291 and shipped a fix in version 3.8.1, changing the default behavior to block HTTP repository resolution.

This was a hard-fought win — and one that highlighted just how difficult it can be to drive coordinated change even when the risk is well-documented and easily fixed.

Part V: Fixing It at Scale — From Bulk PRs to Black Hat

With changes underway across artifact hosts and build tools, I wanted to see just how far I could take this — not just by changing policies or defaults, but by actually eliminating the vulnerable code in the wild. That’s when I built an automation engine for secure pull request generation.

To do that, I built a tool: the bulk-security-pr-generator. In early 2020, I live streamed myself using it to generate 1,596 pull requests in one sitting, patching insecure dependency resolution across the JVM ecosystem. Over the past several years, over 40% of these pull requests have been merged. That means that 600+ OSS repositories that were vulnerable, no longer are.

This wasn’t just a stunt. It was the first successful demonstration that mass vulnerability mitigation via automation was not only possible — it was practical.

That work led me to become the inaugural Dan Kaminsky Fellow, which gave me the time and support to turn this idea into a replicable process: one that could scale security research across entire ecosystems.

The culmination of that work was a talk — actually, many talks:

“Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All”

Imagine a world where a security researcher becomes aware of a security vulnerability, impacting thousands of Open Source Software (OSS) projects, and is enabled to both identify and fix them all at once. […] Let’s not just talk about vulnerabilities — let’s actually fix them at scale.

This talk was presented at:

• Black Hat USA
• DEF CON 30
• GitHub Universe
• BSides LV
• SEC-T Stockholm
• No Hat Italy
• Code Blue Tokyo
• IWCon

It told the story not just of fixing vulnerabilities, but of building and demonstrating a new model for open source security work:

• Find a vulnerability pattern (via CodeQL, GitHub Search, grep, etc.)
• Automate the search across thousands of repositories
• Automatically generate PRs with real, reviewable fixes
• Submit them respectfully, with clear descriptions and opt-out options
• Contribute those queries upstream to prevent regressions

And most importantly: do all of this in a way that helps maintainers — not burdens them.

📣 Interlude: I’m on the Market

Like what you’re reading? I’m currently exploring my next opportunity in software security, open source, or developer tooling. If this kind of work resonates with you, I’d love to connect.

📧 Email: Jonathan.Leitschuh@gmail.com
⛓️ LinkedIn: https://www.linkedin.com/in/jonathan-leitschuh/
📅 Schedule Time: https://calendly.com/jlleitschuh

Part VI: What It Takes to Eliminate a Vulnerability Class

If there’s one lesson I’ve taken away from this work, it’s this: eliminating a vulnerability class from an ecosystem requires persistence — and a multipronged strategy.

You can’t assume that someone else will finish the work. You can’t rely on a single fix, a single flag, or a single PR. You have to:

• Patch the vulnerable consumers
• Fix the defaults in the tools
• Change the behavior at the source
• Coordinate across organizations, vendors, and open source maintainers
• Follow through until the job is actually done

This wasn’t just a bug to fix — it was a systemic weakness in how the Java ecosystem resolved dependencies. It was an invisible dependency problem hiding in plain sight. And it had to be rooted out on all sides.

Security is rarely about discovering something new. Often, it’s about fixing what we already knew was broken — but at scale, with care, and with follow-through.

We didn’t just patch a bug. We made a vulnerability class obsolete.

And that’s how you burn it with fire.

Burn It With Fire: How to Eliminate an Industry-Wide Supply Chain Vulnerability was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

How a 5-year-old deserialization flaw, a vacation phone call, and some persistence led to a safer Java ecosystem

“I’ve Seen This Before”: Rediscovering an Old Vulnerability in New Code

This whole story starts, as any good story starts, reading CVE’s on GitHub’s advisory feed. A few years back I was reading CVE-2022–1471, a vulnerability in SnakeYaml reported by Google’s security team. It caught my eye immediately — not because the attack was novel, but because it absolutely wasn’t. The vulnerability allowed remote code execution (RCE) in Java applications using SnakeYAML via unsafe deserialization of YAML input. Sound familiar?

It should. I’d seen this exact vector before — five years earlier — in Moritz Bechler’s now-classic paper, Java Unmarshaller Security: Turning Your Data Into Code Execution. Bechler’s paper had already documented how SnakeYAML, like many Java unmarshalling libraries, allowed attackers to instantiate arbitrary classes just by feeding them crafted YAML documents. SnakeYAML wasn’t just mentioned — it was one of the very first examples in the paper.

So I wasn’t surprised by the CVE itself — I was actually quite grateful the Google security team had gone back and assigned a CVE to this ancient vulnerability. What surprised me was the reaction from the project maintainer, Andrey Somov, who initially marked the issue as “Won’t Fix.” To him, it wasn’t a bug; it was a “feature” that had been documented for years. If users didn’t want arbitrary classes instantiated from YAML, they should have known to use SafeConstructor—but most didn’t. And they had no reason to.

Here’s the insecure, default usage found in nearly every tutorial:

// Insecure by default (prior to SnakeYAML 2.0)
Yaml yaml = new Yaml();
Object obj = yaml.load(input);

And here’s what they would have had to do to stay safe:

// Safer alternative using SafeConstructor
Yaml yaml = new Yaml(new SafeConstructor());
Object obj = yaml.load(input);

Unless a developer already understood the security implications, they’d never know to opt into safety — because the dangerous behavior came baked in, silently, by default.

But here’s the problem: secure defaults matter. And worse, there were already dozens of CVEs in the wild — real, exploitable security bugs — caused by this exact design flaw. I had also seen them show up in GitHub’s CodeQL scans of the open-source ecosystem, which I’d been helping analyze and triage.

In fact, at the time I was personally working to improving CodeQL’s UnsafeDeserialization query. I was going through the documented deserialization classes in that query and adding information on whether each one was secure by default or not. That work sparked some spirited debate in GitHub’s PR #11700, where I argued that CodeQl's tooling should not just flag unsafe APIs—but help developers understand what constitutes secure usage, and why that distinction matters.

So when I joined the Bitbucket issue thread for SnakeYAML, I brought that same mindset. This wasn’t just about tooling or compliance — it was about helping maintainers see how real-world developers were misusing their API, and why the burden of secure configuration shouldn’t fall solely on the end user.

💰Perverse Incentives in the Vulnerability Economy

One of the things I’ve come to appreciate — grudgingly — as a security researcher is just how skewed the incentives are when it comes to fixing vulnerabilities at the root.

Vendors building static analysis tools — CodeQL, Fortify, Checkmarx, SonarQube — play an incredibly important role in securing the software ecosystem. But from an economic standpoint, their incentives are often misaligned with what actually makes software safer in the long term. Adding a new rule or query that lights up thousands of dashboards? That’s measurable progress. That’s sales collateral. But working with upstream maintainers to fix a bad default that’s causing the vulnerability in the first place? That’s hard. That’s time-consuming. And that doesn’t directly translate into more tool adoption.

It’s a kind of perverse incentive system. The focus ends up being on detecting badness, not eliminating it at the source.

And to be clear: I’ve been on both sides of that divide. I’ve helped write CodeQL queries that flag unsafe vulnerability patterns. I’ve watched those alerts show up across thousands of open-source repositories. I’ve also received bounties for several of the queries I contributed as part of the now-defunct GitHub Security Lab CodeQL Bug Bounty Program.

But I’ve also seen the futility of closing the same vulnerability over and over again in downstream projects, when the root cause — a dangerous default, a misused API, a permissive parser — remains unaddressed upstream.

So when I saw SnakeYAML’s maintainer dismiss the vulnerability as a non-issue — effectively saying, “This isn’t a problem with the library, just with how people use it” — I couldn’t let that go unchallenged. Because I knew from real-world data that people were using it this way. And they were getting burned.

⚔️ When “Intended Behavior” Becomes an Attack Surface

At that point, I knew what I had to do. If a theoretical argument wasn’t going to move the needle, I’d make it practical.

I went back to Moritz Bechler’s marshalsec paper and payload generator and pulled out actual deserialization payloads he’d documented five years earlier — payloads that still worked against SnakeYAML’s defaults. These weren’t obscure edge cases. These were minimal, weaponizable YAML snippets that could instantiate dangerous classes already sitting on many applications’ classpaths.

I after running the payload generator, I dropped all nine of them directly into the Bitbucket thread.

That first example alone can lead to remote code execution if the right classes are in the classpath — something that’s surprisingly easy even in plain Java environments, without needing Spring, JDBC drivers, or JNDI.

I also pointed to other documented gadgets: JdbcRowSetImpl, TemplatesImpl, even Spring's own JNDI-backed bean factories. Every one of them had shown up in either published CVEs or in my own CodeQL scans of the ecosystem.

This wasn’t hypothetical. It was happening, in production, across hundreds of projects.

And yet, the official guidance from the maintainer boiled down to: “Don’t deserialize untrusted YAML,” and “You should have known to use SafeConstructor.”

That argument misses the forest for the trees. Yes, a knowledgeable engineer could choose SafeConstructor. But most developers aren’t parsing YAML because they want deserialization—they just want a config file. And they’re using libraries the way the README tells them to:

new Yaml().load(input);

That line of code — the one in nearly every tutorial and StackOverflow post — was unsafe by default. And real people were paying the price.

🌊 The Beach, the Spec, and the Breakthrough

Somewhere around the 80th comment in the thread, it became clear we weren’t going to resolve this through Bitbucket alone. So I did something I don’t usually do: I offered to hop on a call.

At the time the offer for a call was accepted, I was on Christmas vacation in Punta Cana, in the Dominican Republic. I took the call from the balcony of my hotel room, listening to waves crash in the background while I talked deserialization edge cases and YAML parsing internals for nearly an hour.

I’ll admit — I wasn’t optimistic. Up to that point, most of our exchanges had been tense. The maintainer, Andrey, didn’t see this as a vulnerability. I and much of the community of users did. We were stuck.

But that hour-long conversation ended up being a turning point — not just for the issue, but for me. We dug deep into the YAML spec, particularly how tags work. For anyone who hasn’t spent their vacation reading YAML specs: a tag in YAML is a way to annotate a node with type information. SnakeYAML had been parsing these tags — especially what the spec calls “global tags” — and treating them as Java class names to instantiate.

That was the problem. That’s how !!javax.script.ScriptEngineManager became a security issue.

After a long back and forth, where I was honestly about ready to give up, I asked a question — I can’t remember exactly what it was — but it reframed the conversation. Suddenly, we weren’t arguing over whether this was “intended behavior.” We were talking about what SnakeYAML should actually do by default.

And then something clicked. I remember Andrey saying something to the effect of, “Yeah, I could probably do that.” And with that, the wheels were in motion for this old vulnerability to finally get fixed.

That’s what led to this post in that way-too-long BitBucket thread:

To that end, I proposed that the change we make is to modify SnakeYaml so it doesn’t process class names in, what in the YAML spec are called ‘global tags’. By not reading class names and attempting to instantiate classes from these global tags — at least not by default — I believe we will remove the vulnerability from SnakeYaml, allowing it to safely operate on untrusted data without leading to this remote code execution vulnerability.

That proposal became the foundation for what would eventually ship in SnakeYAML 2.0.

🔒 Secure by Default: A Long Time Coming

A few months later, SnakeYAML 2.0 was released. The changelog was modest. But the change itself was anything but.

By default, SnakeYAML would no longer instantiate Java classes from global YAML tags. The exact same payloads that once led to remote code execution would now safely fail unless a developer explicitly configured the library to allow them. The risk was no longer hidden in plain sight — it was opt-in.

It wasn’t a huge pull request. But it was a huge shift in philosophy: Secure by default. Unsafe only with informed consent.

Looking back, the thing I keep thinking about is how close this change came to never happening. CVE-2022–1471 was initially dismissed. It took a mammoth public thread, real-world exploit payloads, and a vacation phone call to finally align on a fix.

And even now — years after the fix shipped — I still get surprised by the impact. I’ve had random strangers walk up to me at conferences and thank me for my work on this issue. I’m always a little shocked when it happens. I wasn’t trying to be a hero. I was just doing what I thought was important: helping make open source safer. But it turns out, when you help get a security fix like this over the finish line, it echoes. Maintainers notice. They remember. And sometimes they carry those lessons into their own projects.

🔚 Final Thoughts

If you’re a security researcher: don’t stop at writing the alert. Help build the fix. If you’re a maintainer: if people are misusing your library in dangerous ways, maybe the problem isn’t the users. And if you’re building tools: detection is important — but the real win is when you make vulnerabilities impossible to write in the first place.

Secure by default isn’t a luxury. It shouldn’t be the exception. It should be the expectation.

📣 I’m on the Market

If you found this post insightful, I’m currently looking for my next opportunity in software security, open source, or developer tooling. Always happy to hop on a call to connect.

📧 Email: Jonathan.Leitschuh@gmail.com
⛓️ LinkedIn: https://www.linkedin.com/in/jonathan-leitschuh/
📅 Schedule Time: https://calendly.com/jlleitschuh

5 Years, 160 Comments, and the Vulnerability That Refused to Die was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

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.

On December 26th 2024, I opened GitHub and discovered that openrewrite/rewrite-java-security — a repository I had spent the better part of two years building recipes for — had been moved, made closed source, relicensed, and made proprietary by Moderne, Inc. The code I authored, the recipes I wrote, and the security work that had been funded by open source security initiatives was now locked behind the Moderne Proprietary License (MPL). No heads-up. No contributor outreach. No blog post.

Just a new license.

A Quick Recap

OpenRewrite is a code refactoring framework that enables large-scale, automated changes to Java (and other JVM) codebases. At its best, it offers a vision of what developer tooling could be: scalable, modular, and language-aware. It was originally developed by Moderne CEO Jonathan Schneider while at Netflix as an almost entirely Apache 2.0 licensed codebase, until recently.

I was one of the earliest and most active contributors to the rewrite-java-security project. My work on it began in 2022 under the Dan Kaminsky Fellowship at HUMAN Security, and continued in 2023 through a position with the Linux Foundation’s OpenSSF Project Alpha-Omega, funded by Microsoft, Google, and Amazon. I led a small team of interns to author OpenRewrite recipes that automatically fixed common security issues in vulnerable codebases. I used these recipes to generate hundreds of OSS pull requests to fix security vulnerabilities at-scale; then subsequently spoke publicly about this work on stages like Black Hat and DEFCON.

Combined, these efforts represented many thousands of hours of community investment into a resource intended to benefit the entire open source ecosystem.

Then Moderne changed the license.

The License Lockdown

In December 2024, Moderne moved rewrite-java-security under the Moderne Proprietary License (MPL). This license is not open source, not OSI-approved, and requires a signed commercial contract with Moderne to use or access the code going forward.

This means:

• Any improvements or changes Moderne makes to the code I originally wrote are no longer publicly available.
• I am no longer able to make changes, improvements, or even contribute bug fixes to that code.

Despite being one of the primary maintainers of the project, my ability to contribute to it has been fully revoked.

This licensing shift didn’t just impact rewrite-java-security. It affected a wide swath of the OpenRewrite ecosystem. Moderne applied its new licensing approach across many repositories and modules, including some with longstanding community involvement.

Here’s how the license breakdown now looks across various OpenRewrite modules: Full list available here.

This happened without a blog post, and without an announcement to the community. It was done silently during, for most projects, a minor version bump.

When I raised these concerns in the OpenRewrite community Slack channel, I was hoping for a good-faith discussion about community impact. Instead, I was privately criticized and dismissed as being self-centered for speaking up. That kind of response made it clear that this was not a collaborative decision — it was a unilateral one.

“Committed to the Principles of Pure Open Source”

In April 2024, Moderne announced that OpenRewrite was joining the Commonhaus Foundation, a nonprofit supporting open-source sustainability:

“Moderne is committed to the principles of pure open source… Commonhaus supports our commitment to keep OpenRewrite community-driven and accessible, ensuring its utility and relevance for years to come.”

This press release has since been deleted.

On December 9th, Moderne formally withdrew OpenRewrite from the foundation. The reasoning included concerns over:

• Trademark policy constraints that would limit Moderne’s creative use of the OpenRewrite brand
• A majoritarian voting structure that could, they felt, pose future risks to Moderne’s commercial interests

Despite expressing support for Commonhaus’s goals, Moderne concluded that its vision for OpenRewrite couldn’t coexist with the foundation’s governance model.

The irony here is hard to ignore. A company that professed commitment to community-led governance and “pure open source” walked back that commitment in both practice and policy — first by withdrawing from a nonprofit governance body, then by relicensing community-contributed code as proprietary.

“Protecting Ourselves From AWS”

When asked why they made this change, Moderne leadership cited concerns about companies like Amazon and VMware using OpenRewrite recipes without contributing back.

That might be a fair frustration. But here’s the hypocrisy:

• Amazon didn’t strip your name from your code.
• VMware didn’t relicense your work without your consent.

At Moderne’s CodeRemix Summit 2025, several employees explained that this fear crystallized in late 2024 when several prospective customers reportedly said they didn’t see value in paying for Moderne. Why? Because they believed that solutions like Amazon Q Code Transformer, Sourcegraph Batch Changes, or Broadcom Application Advisor would suffice.

In other words, Moderne had built a powerful open source tool — OpenRewrite — and now found itself competing with its own creation. Worse, they felt they were competing against tech giants using their own tooling without contributing anything back.

Originally, Moderne leadership viewed the company’s core value in its SaaS infrastructure, not the recipes. The OpenRewrite project — and its growing recipe library — was meant to be the open source foundation, while Moderne’s differentiator would be in the serialization and storage of large-scale abstract syntax trees (LSTs). But when third-party platforms demonstrated they could run OpenRewrite recipes at scale without Moderne, that became an existential threat to the company.

The fear was real. But the response — locking down code contributed by others — was deeply flawed and has left myself and other members of the community feeling hurt.

This Isn’t Just About Me

Moderne CEO Jonathan Schneider stated:

“We looked through every repo, and those repos that either Moderne only contributed to or for which there were only ‘contributions like this’, we felt comfortable making the change… rewrite-java-security was the only really oddball one that needed to have some of its stuff archived and some of its stuff moved.”

However, this statement does not align with observed contributions. There are multiple examples of non-trivial community contributions that have been swept into Moderne’s proprietary or source available license, including from major enterprise contributors:

• VMware
• AliBaba

These are clear counterexamples that demonstrate community-written recipes — contributed under Apache 2.0 — have now been relicensed without consent.

Other contributors have raised similar concerns. Some have seen their Apache-licensed recipes swept under restrictive terms. Others have flagged that attribution and SPDX headers were removed. All of this breaks the unspoken contract that powers open source: contribute in good faith, and your contributions will be respected and remain open.

All of this left many of us asking if this license change was even legal.

That’s not just a rhetorical question. Under the Apache 2.0 license, relicensing code without permission from each contributor — unless governed by a Contributor License Agreement (CLA) — is a legally murky move. While companies like MongoDB and Elastic have made similar license transitions, those shifts sparked community forks and ongoing debate about their legality. Moderne’s decision follows this controversial pattern, but does so without the scale, communication, or governance that often accompany such major transitions. That raises real questions for downstream adopters and contributors alike.

Worse still, this sets a dangerous precedent:

Any company investing in the OpenRewrite ecosystem today risks having their employee-contributed recipes pulled into a proprietary licensing regime tomorrow.

This mirrors broader industry trends — like the relicensing decisions made by MongoDB and HashiCorp — where companies facing commercial pressure restrict the freedoms of the very communities that helped them grow.

We can acknowledge that “open source is free, as in free puppy.” Maintaining large-scale projects like OpenRewrite is not free, and Moderne — like any steward of OSS infrastructure — needs a viable business model. But that doesn’t make what they did right.

After crunching some data, I found that across OpenRewrite non-composite recipes, there are 2,635 unique recipe contributor pairs. Of those, ~350 are from email addresses that do not end in @moderne.io nor are identifiable personal emails of Moderne employees. At least some of these are real, non-trivial community contributions.

We can disagree about business models. We can even disagree about licenses. But we shouldn’t just retroactively rewrite history to consolidate ownership over public, community-authored code.

Moderne’s Corrections and Course Adjustments

In the weeks following community pushback, Moderne took steps to correct some of the most immediate concerns:

1. Apache-licensed repositories were restored and archived, preserving prior community contributions in a public, accessible form, including rewrite-java-security.
2. Major version bumps were introduced to properly signal the license changes in affected projects.
3. Split namespaces (e.g., org.openrewrite vs. io.moderne) were introduced to distinguish between fully open and source-available/proprietary modules.

These changes demonstrate that some of the feedback was heard and acted upon. However, the fact remains: these were not proactive measures discussed openly with the community — they were reactive corrections to a course that was set in motion without our input.

A Path Forward

What Moderne should do:

1. Revert the license changes on all community-authored recipes. Let what was given freely by the community remain free and open for the community.
2. Commit to community discourse: Changes like this should not be a surprise, and if they need to be, then they should be communicated publicly instead of silently.
3. Respect versioning: Moving forward, license changes should be major semver bumps, not slipped into a v2.17.0 update.

What I’m doing:

Despite all of this, I’m still passionate about automated security remediation at scale, especially for OSS projects. I plan to continue leveraging OpenRewrite as a powerful tool to perform security research and fix vulnerabilities at-scale across OSS. If you want to explore how your organization can use OpenRewrite effectively, feel free to get in touch or book some time with me.

Final Thoughts

Open source doesn’t work without trust. And trust is easy to lose. It only takes a quiet relicense, a removed attribution, and a private dismissal when you raise concerns in good faith. I came to the community expecting collaboration, only to be told I was being self-centered for asking questions about code I helped write.

This wasn’t just a licensing update. It was a violation of the norms, values, and expectations that hold open source communities together.

But it doesn’t have to be this way. We can build ecosystems that value contribution, respect consent, and center community over control.

OpenRewrite showed what’s possible when open source and security come together to empower developers at scale. The ideas behind it still matter. The need still exists. And I still want to help build that future — one that’s grounded in shared ownership, transparency, and trust.

Correction: An earlier version of this article incorrectly stated ~600 contributions were from non-moderne employees, this has been updated to be ~350 after some feedback from Moderne.

When Open Source Isn’t: How OpenRewrite Lost Its Way was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

CVE ≠ Vulnerability (And 36 Other Confusions Regarding CVE)

Billions of dollars are spent on security tooling, vulnerability scanners light up dashboards in every SOC, and somewhere in the middle of it all is a humble acronym: CVE™. It shows up in reports, tickets, release notes, investor decks, press releases, and breach reports. It is often used interchangeably, often incorrectly, with “vulnerability,” “exploit,” and “security flaw.”

Despite its ubiquity, there is widespread confusion about what a CVE actually is. Many people — some of them in charge of large enterprises— believe a CVE is the same thing as a software vulnerability. Or that every software vulnerability has a CVE. Or that a CVE always includes technical details, a fix, a CVSS score, and a confession from the developer who introduced the bug.

Inspired by Falsehoods Programmers Believe About Names, this is a list of things people (wrongly) believe about CVEs. Some are naive. Some are overly optimistic. A few are just wishful thinking.

All of them are false.

1. A CVE and a vulnerability are the same thing
2. A CVE exists for all publicly disclosed vulnerabilities
3. A CVE existing means the vulnerability was disclosed
4. A CVE exists
5. A CVE being assigned means that a vulnerability must exist
6. A CVE is only for big, dramatic bugs — nobody bothers with a CVE for trivial issues
7. A CVE has never been assigned for a hardware vulnerability
8. A CVE is always assigned to a single vulnerability
9. A CVE is always assigned to a single product
10. A CVE is always fixed in a single version of the software
11. A CVE’s year (CVE-[YEAR]) the is the year the CVE was published
12. A CVE will always be assigned and published on the same day the vulnerability is disclosed
13. A CVE will always be assigned and published within the same year that the vulnerability is disclosed
14. A vulnerability that has been discussed at a security conference will, of course, have a CVE assigned to it
15. Surely someone will have followed up after the conference, right?
16. Within a year?
17. A CVE has a fix
18. A CVE is never a duplicate of another CVE
19. A CVE is guaranteed to be exploitable
20. The rules governing assigning a CVE in end of life (EOL) software is exactly the same as maintained software
21. A CVE contains sufficient information to compute it’s CVSS score
22. A CVE contains sufficient information to determine the severity of the vulnerability
23. A CVE contains sufficient information to determine what product is affected
24. A CVE contains sufficient informa… 🙄
25. A CNA would never write a CVE description carefully and specifically to influence NIST to assign a specific CVSS score
26. Both the software vendor and the security researcher must agree a vulnerability exists for a CVE to be assigned
27. A CVE is never withdrawn or disputed
28. A software product that has lots of CVEs must be less secure
29. A software product with no CVEs must be more secure
30. A CVE is hard to get assigned for a vulnerability
31. A CVE is easy to get assigned for a vulnerability
32. CVE is a government program
33. CVE is run by the National Vulnerability Database (NVD)
34. CVE is run by MITRE
35. CVE is exclusive to the USA
36. The CVE system is free from politics
37. CVEs are assigned by an all-knowing, infallible committee that never makes mistakes

This list is by no means exhaustive. If you’re skeptical that these misconceptions exist, I invite you to attend one vulnerability disclosure panel, or read through a few dozen CVE entries. Or better yet, try requesting one yourself.

Feel free to suggest more falsehoods in the comments, and share this post the next time someone insists that every CVE has a fix, a proof-of-concept exploit, a CVSS score, and universal agreement on whether it’s even real.

Thanks: Special thanks to everyone at Vuln Con 2025 who offered their own falsehoods and helped proofread this blog post.

January 13th-15th, 2020 will break over 21% of the industry’s Java build infrastructure. Six months since my initial article disclosing this industry-wide vulnerability, where are we now and what does the future hold?

On June 10th, 2019 I publicly disclosed an industry-wide vulnerability impacting the Java ecosystem in an article titled ‘Want to take over the Java ecosystem? All you need is a MITM!’ In that article, I detailed how many of the most popular JVM based libraries were resolving their dependencies via their build tool over HTTP instead of HTTPS.

As a part of this research, I reached out to the security teams of several of the Java ecosystem’s most used artifact servers, and on January 15th, 2020 many of these artifact servers will drop support for HTTP in favor of only supporting HTTPS. It’s important to remember that as of June 2019, 25% of Maven Central downloads were still using HTTP. As of December 12th, 2019 21% of Sonatype Maven Central downloads are still using HTTP.

21% of Sonatype Maven Central downloads are still using HTTP

It’s important to stress that this breakage will force a very healthy and important shift in the security of the Java ecosystem’s supply chain.

Artifact Server Host Announcements

Listed below are the artifact servers I’ve reached out to and their current responses.

Maven Central — Sonatype

Maven Central will drop support for HTTP on January 15th, 2020.
You can read their full announcement here.

JCenter — JFrog

JCenter will drop support for HTTP on January 13th, 2020.
You can read their full announcement here.

Bintray — JFrog

JFrog has informed me that they will not be decommissioning HTTP for dl.bintray.com as it is used for resolving artifacts for other ecosystems. I have pleaded with them to reconsider this decision, but at this time they are not willing to commit to this breaking change.

Gradle Plugin Portal — Gradle

The Gradle Plugin Portal will drop support for HTTP on January 15th, 2020.
You can read their full announcement here.

Spring — Pivotal

The Spring Artifact Repository will drop support for HTTP on January 15th, 2020.
You can read their full announcement here.

Eclipse — Eclipse Foundation

Although I’ve reached out to the Eclipse Foundation here and they were initially receptive, currently there has been no commitment on their part.

JetBrains

JetBrains is not willing to commit to a timeline at this point for their repositories they use to host artifacts.

RedHat

I’ve reached out to the RedHat security team on multiple occasions about this initiative and they have been unwilling to commit to a timeline for backing this initiative at this time. They are concerned that such a change will break their paying customers and are therefore unwilling to commit to this change at this time.

Twitter

Similarly, the Twitter Security team has been unwilling to commit to this initiative.

Warnings from the Build Tools

Starting in Gradle 6.0 and Scala Build Tool (SBT) 1.3.x, both will begin warning users that they are using HTTP instead of HTTPS to resolve dependencies with the ability to disable the warning on a per-repository basis.
Additionally, Google’s Bazel build will now require users to specify an SHA-256 hash for any resources downloaded over HTTP.

Unfortunately, at this time, no work has been made towards implementing the same warning in Apache Maven.

Deprecate HTTP Download & Upload

Eliminating this vulnerability in Open Source

GitHub Security Lab: CodeQL

GitHub recently acquired Semmle and with it their query language QL. QL enables security researchers to write an abstract query for a given vulnerability and find all variations of that vulnerability across Open Source Software (OSS). Additionally, GitHub recently announced a new Open Source Bug Bounty Program which rewards researchers for submitting their queries. Semmle’s QL query language is evaluated against every new Open Source project on GitHub. The implications of this are that researchers can now create queries that will eliminate entire classes of vulnerabilities across the OSS ecosystem.

I recently contributed this simple QL query as a part of the new GitHub Security Lab Bug Bounty Program. The submission to the Bug Bounty program can be found here.

This fairly simple query will detect and flag all POM.xml files that use HTTP or FTP. As soon as this query is merged and deployed, it will begin detecting this vulnerability in all future open source contributions to GitHub.

I highly recommend that all GitHub Repositories that haven’t applied the LGTM GitHub integration should do so here!

Bounty!

For the above query, the GitHub Security Lab team was kind enough to award me with a $2,300 reward as a part of the ‘All for one, one for all’ program.

More information here: GitHub Security Lab Bug Bounty Program.

What do I need to do?

As a software developer, security engineer, or operations engineer, please proactively check your Maven, Gradle, SBT, Bazel, Buck, JFrog Artifactory and/or Sonatype Nexus configurations to ensure that your company or project won’t be impacted by this change on January 13th -15th, 2020.

Follow Infosec Write-ups for more such awesome write-ups.

InfoSec Write-ups

Update: Want to take over the Java ecosystem? All you need is a MITM! was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.

Over 6 years ago I was working on a project called WPILib. WPILib is a library used by High School FIRST Robotics teams to program their robots. This particular year, the development team decided to use MDNS to resolve the IP address of the robot. When tested, everything worked for the devs so they moved forward with using it.

I joined the team at the beginning of the summer between my Sophomore and Junior year of college and was using a Mac for development. As the entire development environment only supported Windows I ended up setting up the dev environment in a Parallels VM.

At some point in the development process, I end up needing to deploy code to the robot. However, for me, it didn’t work.

After a lot of head-scratching, we finally narrowed it down. I was the only developer who hadn’t installed iTunes on their machine.

Why iTunes you may ask? As we quickly learned Windows doesn’t ship with MDNS support out of the box. Apparently, when you install iTunes, the installer also installed Bonjour printer services into your OS Networking Stack. Bonjour adds support for MDNS.

Needless to say, it was good that we caught this issue before the software was shipped to 4000 robotics teams.

Humorously, I suggested that we just document with something like:

If you have problems uploading code to your robot, try installing iTunes.

Funnily enough, this was actually the suggestion the team ended up pursuing. This is from the official FIRST Robotics Documentation for MDNS support:

A vulnerability in the Mac Zoom Client allows any malicious website to enable your camera without your permission. The flaw potentially exposes up to 750,000 companies around the world that use Zoom to conduct day-to-day business.

CVE-Numbers

• DOS Vulnerability — Fixed in Client version 4.4.2 — CVE-2019–13449
• Information Disclosure (Webcam) — Unfixed —CVE-2019–13450

UPDATE — July 9th (am)

As far as I can tell this vulnerability also impacts Ringcentral. Ringcentral for their web conference system is a white labeled Zoom system.

UPDATE — July 9th (pm)

According to Zoom, they will have a fix shipped by midnight tonight pacific time removing the hidden web server; hopefully this patches the most glaring parts of this vulnerability. The Zoom CEO has also assured us that they will be updating their application to further protect users privacy.

UPDATE — July 15th

If you have updated Zoom to the latest version, you are now greeted with this new UI confirming you would actually like to join the meeting.

Jonathan Leitschuh on Twitter

This new @zoom_us feature fully patches the #SecurityVulnerability where users were maliciously joined to a call without their permission. Doing this in a week is an example the kind of fast response times we want to see in a properly executed bug bounty program! Go Update!

UPDATE — July 17th

It has since come to light that Zoom and 13 of their white label applications contained a Remote Code Execution (RCE) vulnerability. Zoom, RingCentral, Telus Meetings, BT Cloud Phone Meetings, Office Suite HD Meeting, AT&T Video Meetings, BizConf, Huihui, UMeeting, Zhumu, Zoom CN, EarthLink Meeting Room, Video Conferencia Telmex, & Accession Meeting. Apple has since silently removed these applications from your computer by utilizing MRT.

Foreword

This vulnerability allows any website to forcibly join a user to a Zoom call, with their video camera activated, without the user's permission.

On top of this, this vulnerability would have allowed any webpage to DOS (Denial of Service) a Mac by repeatedly joining a user to an invalid call.

Additionally, if you’ve ever installed the Zoom client and then uninstalled it, you still have a localhost web server on your machine that will happily re-install the Zoom client for you, without requiring any user interaction on your behalf besides visiting a webpage. This re-install ‘feature’ continues to work to this day.

This vulnerability leverages the amazingly simple Zoom feature where you can just send anyone a meeting link (for example https://zoom.us/j/492468757) and when they open that link in their browser their Zoom client is magically opened on their local machine. I was curious about how this amazing bit of functionality was implemented and how it had been implemented securely. Come to find out, it really hadn’t been implemented securely. Nor can I figure out a good way to do this that doesn’t require an additional bit of user interaction to be secure.

This vulnerability was originally responsibly disclosed on March 26, 2019. This initial report included a proposed description of a ‘quick fix’ Zoom could have implemented by simply changing their server logic. It took Zoom 10 days to confirm the vulnerability. The first actual meeting about how the vulnerability would be patched occurred on June 11th, 2019, only 18 days before the end of the 90-day public disclosure deadline. During this meeting, the details of the vulnerability were confirmed and Zoom’s planned solution was discussed. However, I was very easily able to spot and describe bypasses in their planned fix. At this point, Zoom was left with 18 days to resolve the vulnerability. On June 24th after 90 days of waiting, the last day before the public disclosure deadline, I discovered that Zoom had only implemented the ‘quick fix’ solution originally suggested.

Ultimately, Zoom failed at quickly confirming that the reported vulnerability actually existed and they failed at having a fix to the issue delivered to customers in a timely manner. An organization of this profile and with such a large user base should have been more proactive in protecting their users from attack.

Timeline

• Mar 8, 2019 — Requested security contact via Twitter (no response).
• Mar 26, 2019 — Contacted Zoom Inc via email with 90-day public disclosure deadline. Offered a “quick fix” solution.
• Mar 27, 2019
  - Requested confirmation of reception.
  - Informed that Zoom Security Engineer was Out of Office.
  - Offered and declined a financial bounty for the report due to policy on not being able to publicly disclose even after the vulnerability was patched.
• Apr 1, 2019 — Requested confirmation of vulnerability.
• Apr 5, 2019 — Response from Zoom Security Engineer confirming and discussing severity. Settled on CVSSv3 score of 5.4/10.
• Apr 10, 2019 — Vulnerability disclosed to Chromium security team.
• Apr 18, 2019 — Updated Zoom with the suggestion from Chromium team.
• Apr 19, 2019 — Vulnerability disclosed to Mozilla FireFox security team.
• Apr 26, 2019 — Video call with Mozilla and Zoom Security Teams
  Disclosed details of impending DNS expiration.
• June 7, 2019 —Email from Zoom about a video call to discuss fix.
• June 11, 2019 — Video call with Zoom Security team about impending disclosure. Discussed how Zoom’s planned patch was incomplete.
• June 20, 2019 — Contacted about having another video call with Zoom Security Team. Declined by me due to calendar conflicts.
• June 21, 2019 — Zoom reports vulnerability was fixed.
• June 24, 2019 — 90-day public disclosure deadline ends. Vulnerability confirmed fixed with ‘quick fix’ solution.
• July 7, 2019 — Regression in the fix causes the video camera vulnerability to work again.
• July 8, 2019
  - Regression fixed.
  - Workaround discovered & disclosed.
  - Public Disclosure.

Details

On Mac, if you have ever installed Zoom, there is a web server on your local machine running on port 19421. You can confirm this server is present by running lsof -i :19421 in your terminal.

First off, let me start off by saying having an installed app that is running a web server on my local machine with a totally undocumented API feels incredibly sketchy to me. Secondly, the fact that any website that I visit can interact with this web server running on my machine is a huge red flag for me as a Security Researcher.

My original thoughts when I learned that this web server existed was that if there is a buffer overflow anywhere in the parameter handling of this web server, someone could achieve RCE on my machine. That’s not what I’ve found, but that was my original thought process.

If you look at what’s logged to the web developer console when visiting one of those Zoom ‘join’ links, you should see something like this:

I also found that, instead of making a regular AJAX request, this page instead loads an image from the Zoom web server that is locally running. The different dimensions of the image dictate the error/status code of the server. You can see that case-switch logic here.

The scary thing is that this enum seemed to indicate that this web server can do far more than just launch a Zoom meeting. What I found out was that this web server can also re-install the Zoom app if a user has uninstalled it, more on that later.

One question I asked is, why is this web server returning this data encoded in the dimensions of an image file? The reason is, it’s done to bypass Cross-Origin Resource Sharing (CORS). For very intentional reasons, the browser explicitly ignores any CORS policy for servers running on localhost.

Chrome does not support localhost for CORS requests (an open bug since 2010).
- https://stackoverflow.com/questions/10883211/deadly-cors-when-http-localhost-is-the-origin

I’m guessing that this is intentionally done for security reasons. Regardless, it seems that Zoom is abusing a hack to bypass CORS protection. More on that later.

The Video Call Vulnerability

I created a personal meeting with a different account and cracked open Postman and started to remove parameters to see what the minimal GET request was that was required to launch a Zoom meeting.

There are a lot of random parameters that are sent to the localhost web server but the only ones that seem to matter are the following.

• action=join
• confno=[whatever the conference number is]

Using the following GET request from Postman I was successfully able to get my computer to join the Zoom call that the other account had created.

Once I had this, I started tinkering with what other “action” parameters I might be able to pass to get the client to do other things. I wasn’t able to find anything even after searching through the various public documents and the public ProtoBuff schema for hints about what hidden functionality may exist. Again, this webserver’s API is completely undocumented as far as I can tell and I’ve spent several hours searching for any mention of this Desktop web server in the official and unofficial documentation.

So now I had a minimal POC that I could use to maliciously get any user into a call, however, the default setting for the “New Meeting” is to allow the user to choose whether to join their Audio/Video. I would consider this alone a security vulnerability.

The above-described behavior continues to work to this day! You can still use this exploit to launch someone into a call without their permission.

I read about the Tenable Remote Code Execution in Zoom security vulnerability which was only patched within the last 6 months. Had the Tenable vulnerability been combined with this vulnerability it would have allowed RCE against any computer with the Zoom Mac client installed. If a similar future vulnerability were to be found, it would allow any website on the internet to achieve RCE on the user’s machine.

I advised Zoom that if they have any users that are still using Zoom 4.1.33259.0925 versions or lower, this would be a very potent attack.

So far, I could only achieve getting a user into a call without their permission. Although this has hypothetical security implications, I didn’t have a true exploit. I started tinkering with figuring out how to get someone’s camera activated. When setting up a meeting for work I was greeted with this screen.

Enabling “Participants: On” when setting up a meeting, I discovered that anyone joining my meeting automatically had their video connected.

When I got back to my personal machine, I tried this same functionality and found that it worked exactly the same.

This prompted me to create the Proof Of Concept below.

Proof Of Concept

The local client Zoom web server is running as a background process, so to exploit this, a user doesn’t even need to be “running” (in the traditional sense) the Zoom app to be vulnerable.

All a website would need to do is embed the above in their website and any Zoom user will be instantly connected with their video running. This is still true today!

This could be embedded in malicious ads, or it could be used as a part of a phishing campaign. If I were actually an attacker, I’d probably invest some time to also include the incrementing port logic that the code in the Javascript running on Zoom’s site.

A fully working POC that you can test out yourself can be found at the link below. Warning: Clicking this link on Mac will launch you into a Zoom call!
https://jlleitschuh.org/zoom_vulnerability_poc/

A fully working POC that will launch you into a call with your video camera active can be found here. Warning: Clicking this link on Mac will launch you into a Zoom call with your camera activated!
https://jlleitschuh.org/zoom_vulnerability_poc/zoompwn_iframe.html

Quick Fix

To fix the “auto join with video” part of the vulnerability, I advised Zoom on their backend server they immediately disable a meeting creator’s ability to automatically enable a participants video by default. I advised that this was 100%, not a complete fix. However, it could serve as a quick way to protect users from the invasion of privacy component of this attack.

I also advised that if there is hidden functionality where a meeting host can forcibly join computer audio (perhaps something I’m not seeing because I don’t have a Pro account), this should also be disabled.

I commented that allowing a host to choose whether or not a participant will automatically join with video should be considered it’s own standalone security vulnerability.

To this advisement, I received the following response:

Zoom believes in giving our customers the power to choose how they want to Zoom. This includes whether they want a seamless experience in joining a meeting with microphone and video automatically enabled, or if they want to manually enable these input devices after joining a meeting. Such configuration options are available in the Zoom Meeting client audio and video settings.

However, we also recognize the desire by some customers to have a confirmation dialog before joining a meeting. Based on your recommendations and feature requests from other customers, the Zoomteam [sic] is evaluating options for such a feature, as well as additional account level controls over user input device settings. We will be sure to keep you informed of our plans in this regard.

It’s important to note that the default configuration for Zoom is to allow a host to choose whether or not your camera is enabled or not by default.

Zoom did end up patching this vulnerability, but all they did was prevent the attacker from turning on the user’s video camera. They did not disable the ability for an attacker to forcibly join to a call anyone visiting a malicious site.

UPDATE: July 7th, 2019: There has been a regression in the fix implemented by Zoom thus allowing this vulnerability to be exploited with the video camera activated.

The Denial Of Service (DOS) Vulnerability

This same vulnerability also allowed the attacker to DOS any user’s machine. By simply sending repeated GET requests for a bad number, Zoom app would constantly request ‘focus’ from the OS. The following simple POC demonstrated this vulnerability.

This DOS vulnerability was patched in version 4.4.2 of the Zoom client.

The Install Vulnerability

If you have ever installed Zoom on your computer, this web server is installed. It continues to run if you uninstall Zoom from your computer.

This server also supports updating and installing a new version of Zoom in addition to launching a call. I did some additional decompilation of the Zoom web server to see the code path that these endpoints seemed to call.

Using Hopper Disassembler to disassemble the Objective-C bytecode of the web server I found the following method.

This method is gated by the following logic.

One of the API’s inside of this web server running on all Macs with Zoom installed is an endpoint that allows the current version of Zoom that’s installed to be updated or re-installed by this server.

You can confirm that this logic does indeed exist by doing the following:

1. Install the Zoom client on your computer if you don’t already have it installed.
2. Open the Zoom client, then shut it down.
3. Uninstall the Zoom client from your computer by dragging the Applications/zoom.us.app file to the trash.
4. Open any Zoom join link and Zoom will ‘helpfully’ be re-installed for you in the Applications folder and will be launched by this web server.

Using the list of domains listed inside of the application that could be used to download updates for the Zoom app, I decided to check and see what each of the sites returned when visited. For example, here’s the result of visiting https://zipow.com/upgrade?os=mac

Doing a whois lookup on all of the domains listed in the source code returned some interesting results. For example, the domain zoomgov.com was scheduled to expire on May 1st, 2019. Had this domain registration been allowed to lapse, the takeover of this domain would have allowed an attacker to host an infected version of the Zoom installer from this site and infected users who had uninstalled Zoom from their computers. Essentially, this would have made this vulnerability a Remote Code Execution (RCE) vulnerability. I disclosed this bit of information to the Zoom team during my call with the Mozilla security team on April 26th, 2019. Within 5 hours of the end of that call that domain had been registered out to May 1st, 2024.

Fundamental Security Vulnerability

In my opinion, websites should not be talking to Desktop applications like this. There is a fundamental sandbox that browsers are supposed to enforce to prevent malicious code from being executed on users machines.

Having every Zoom user have a web server that accepts HTTP GET requests that trigger code outside of the browser sandbox is painting a huge target on the back of Zoom. It’s important to note that if you try to pull off the same exploit directly with a Javascript AJAX request, you are greeted with the following exception.

CORS-RFC1918

In discussing this vulnerability with both the Chromium and Mozilla Firefox security team they both said that they couldn’t do anything about this vulnerability. The Chromium team pointed me to CORS-RFC1918 which is a proposal that will require browser vendors to query users for permission before allowing sites to make requests against local resources like localhost and the 192.168.1.* address space.

Linked in that RFC is a wonderful and fun to read bug report where Tavis Ormandy of Google’s Project Zero found a similar vulnerability in TrendMicro’s Password Manager allowing remote code execution via the browser and the exfiltration of a user’s passwords from a password vault. That story is well worth the read.

When this same vulnerability was reported to the Mozilla Firefox team, they closed it as it wasn’t considered a vulnerability against Firefox. However, they soon reopened the report as a vulnerability against their internal infrastructure. As a result, I was invited into a call with the Zoom and Mozilla Firefox team to discuss the vulnerability on April 26th, 2019. During this call, they promised Mozilla and me that this vulnerability would be patched well before the end of the 90-day disclosure deadline. This turned out to be false.

Zoom’s Proposed Fixes

The fix proposed by the Zoom team was to digitally ‘sign’ the request made to the client. However, this simply means that an attacker would have to have a backend server that makes requests to the Zoom site first to gain a valid signature before forwarding the signature on to the client.

They also proposed locking the signature to the IP that made the request. This would mean that as long as the attacker’s server was behind the same NAT router as the victim, the attack would still work.

I described to the Zoom team how both of these solutions were not enough to fully protect their users. Unfortunately, this left the Zoom team with only 18 days before public disclosure to come up with some better solution.

Unfortunately, even after my warning, this was the solution they chose to go with. This new signature or token is embedded in a new parameter called confid. The simplest way to bypass this new confid check was to simply use the iframe workaround described above. Alternatively, if you and the victim are behind the same NAT router, you can make a request for the join page, extract the #lhs_launch_parames field from the HTML document and embed it in the HTML response from the malicious page.

Conclusion

As of 2015 Zoom had over 40 million users. Given that Macs are 10% of the PC market and Zoom has had significant growth since 2015 we can assume that at least 4 million of Zoom’s users are on Mac. Tools like Zoom, Google Meet or Skype for Business is a staple of today's modern office.

Any vulnerability in an application with this many users must be considered a serious threat to all those users. All of the vulnerabilities described in this report can be exploited via “drive-by attack” methodologies. Many times during my conversation with the Zoom security team they seemed to argue that the seriousness of this vulnerability was limited because it would require “user interaction” to exploit these. My response to this was finally “I would highly suggest that you not hang your hat on ‘user interaction required’ for protecting your users given that this ‘user interaction’ is simply clicking a link or visiting a webpage.”

I believe that in order to fully protect users, I truly believe that this localhost web server solution needs to be removed. Alternative methodologies like registering custom URI handlers (for example, a zoom:// URI handler) with the browsers is a more secure solution. When these URI handlers are triggered, the browser explicitly prompts the user for confirmation about opening the app. According to the Zoom team, the only reason this localhost server continues to exist is that Apple’s Safari doesn’t support URI handlers.

Consequences

This is essentially a Zero Day. Unfortunately, Zoom has not fixed this vulnerability in the allotted 90-day disclosure window I gave them, as is the industry standard. As such, the 4+ million users of Zoom on Mac are now vulnerable to an invasion of their privacy by using this service.

Additionally, due to a lack of sufficient auto-update capabilities, many users continue to run outdated versions of Zoom for months after new releases are shipped leaving them vulnerable to exploits like these.

Patch Yourself

If you want to patch this vulnerability for yourself you can do the following.
Disable the ability for Zoom to turn on your webcam when joining a meeting.

Alternatively, use this terminal command.

To shut down the web server, run lsof -i :19421 to get the PID of the process, then do kill -9 [process number]. Then you can delete the ~/.zoomus directory to remove the web server application files.

To prevent this server from being restored after updates you can execute the following in your terminal:

If you want a full description of how to resolve this on Windows and Mac see the Gist below.

Notes For Researchers

Given the massive install base for Zoom, I highly recommend that other researchers take the time to explore this Zoom web server to see what other vulnerabilities exist. This being said, I also recommend that any researcher that finds a vulnerability in Zoom’s software does not directly report the vulnerability to Zoom. Instead, I recommend that researchers report these vulnerabilities via the Zero Day Initiative (ZDI). The ZDI disclosure program gives vendors 120 days to resolve the vulnerability, the ZDI will pay researchers for their work, and researchers have the ability to publicly disclose their findings.

If you want to decompile the Zoom client application for yourself, it’s located in the ~/.zoomus directory on your computer.

The source code repository for my POC examples can be found on GitHub.

If you enjoyed this story, please click the 👏 button and share to help others find it. Feel free to leave a comment!

Did this research & writeup help you or your company? Consider sponsoring me by donating to my college loan repayment fund. Every bit helps.

Follow Infosec Write-ups for more such awesome write-ups.

InfoSec Write-ups

Zoom Zero Day: 4+ Million Webcams & maybe an RCE? Just get them to visit your website! was originally published in InfoSec Write-ups on Medium, where people are continuing the conversation by highlighting and responding to this story.