The 29 May 2026 issue of Self-Host Weekly landed in my inbox with two stories that, on the surface, have nothing to do with each other. The first was a 52-page Vatican document on artificial intelligence, written in a tone that is recognizably papal and that quotes Gandalf. The second was a CVE (Common Vulnerabilities and Exposures, the public catalogue of named software security flaws) in Gitea and Forgejo, the two self-hosted Git platforms, that exposed private container images from more than 30,000 instances for four years. Both stories made the digest. The digest author put them next to each other in the highlights section, and I think the placement was deliberate.
The theme that connects them is the gap between the people who build the tools and the people who run them. The Vatican document is, at heart, a critique of AI’s unregulated growth that the developers of AI systems have not reckoned with. The Gitea CVE is the opposite shape: a vulnerability that the developers of Gitea did not know about, exposed by a researcher, sitting in code that had been deployed for four years. The pattern in both cases is the same. The people who built the system had a model of who would use it and how, and the model turned out to be wrong, and the wrongness did not surface until something else forced it to.
I am going to spend this post on the Gitea CVE. It is the more actionable of the two for self-hosters, and the Vatican document is a longer read that I am still working through. The digest has the link, and Simon Willison’s highlights are a good companion if you want the short version.
The Gitea CVE is worse than it sounds
The CVE is CVE-2026-27771, and the technical name is NoScope. A security researcher found that the private container registry (a private server that stores Docker container images, the packaged bundles that run applications) built into Gitea and Forgejo had a misconfiguration that let anyone on the internet read any private image without authentication. The misconfiguration had been in the code for four years. The researcher enumerated roughly 30,000 publicly reachable Gitea and Forgejo instances and reported that thousands of them were exposing private images from organizations in healthcare, aerospace, and other regulated industries.
What makes this worse than it sounds is that a private container image is not just a piece of code. A container image is the packaged application plus everything it needs to run, including configuration, secrets, and sometimes source code or compiled binaries that the organization considers proprietary. If you can pull the image, you can extract the application code, the environment configuration, and any secrets that got baked into the build (a common practice that is hard to avoid in container builds, where credentials sometimes end up in layers). For a healthcare organization, the image might contain connections to internal systems that are not meant to be exposed. For a startup, the image might contain the entire backend of the product.
Patching means updating Gitea to a fixed version, or switching to Forgejo, which has shipped the fix. Both projects have released patches. The Self-Host Weekly digest has the link to the original disclosure.
What is interesting is how long this went unnoticed
Four years is a long time for a vulnerability of this severity to sit in production code. The reason it did is that the Gitea project, like most open source projects of its size, runs on volunteer labor and a small set of corporate sponsors. The project’s security team is not the same size as the security team at GitHub or GitLab. The kind of regular external security audit (a paid review of the code by a third-party security firm) that catches this kind of misconfiguration happens when a project has the funding to pay for it. Gitea has that funding now; it did not four years ago.
The reason this matters for anyone running Gitea or Forgejo is that the answer is not “switch to GitHub.” GitHub has its own security incidents, including the breach through a malicious VS Code extension that the previous digest covered. The answer is “patch your instance, and audit what is exposed.” The Self-Host Weekly digest also mentioned Homarr, the dashboard application, which reduced its unusually large memory footprint after public complaints a few months ago. The lesson there is similar. Self-hosted software is built by small teams, and small teams sometimes ship software with problems that larger teams would have caught in code review. That is not a reason not to self-host. It is a reason to read the release notes when you update.
What I actually did when the digest landed
I run a small Gitea instance for personal projects. It is not exposed to the public internet. I checked, and the NoScope misconfiguration required the registry endpoint to be reachable from outside the host, which mine is not. I was not affected.
That said, I still updated to the patched version the same day. The reason is that the vulnerability is the kind of thing that gets rediscovered. A patch today does not help if a future deployment accidentally re-enables the misconfiguration. Running the patched version means my deployment matches the secure default, and any future configuration drift (the slow divergence of your settings from the recommended defaults over time, often because of small ad-hoc changes) starts from a known-good baseline.
I also audited two other services I run that have private storage of any kind. One is Paperless-ngx, which stores scanned documents. The other is Syncthing, which syncs files between my devices. Neither was affected by NoScope specifically, but the audit took twenty minutes, and the cost of the audit is small relative to the cost of finding out about a similar issue in one of them six months from now.
The pattern I would tell other self-hosters to watch for
The NoScope vulnerability had three properties that should make any self-hosting operator pay attention. First, the bug was in code that was deployed by default. You did not have to turn on a feature to be exposed. Second, the bug was discoverable by an external scanner (a program that automatically probes many servers looking for known weaknesses) without authentication. Third, the bug was silent. There was no log entry, no alert, no sign in the Gitea admin interface that anything was wrong. All three properties together describe a class of vulnerability that is hard to find by running the software and easy to find by querying the software from outside.
Any self-hosted service you run should be checked against this pattern. For each service, ask three questions. First, is there a default deployment path that exposes something to the public internet without the operator explicitly opting in? Second, can an external scanner find that exposure without authentication? Third, would the service tell you, in its own logs or admin interface, if the exposure was being exploited? If the answer to all three is yes, you have a NoScope-shaped vulnerability waiting to be found.
The fix is not to avoid the service. The fix is to deploy it behind a reverse proxy (a server that sits in front of your application and handles public traffic, hiding the application from direct internet exposure) that requires authentication, to keep the service updated, and to subscribe to the project’s security advisory list so you hear about the next NoScope the day it is disclosed.
Trade-offs
Patching Gitea is not free in downtime. My instance took about four minutes to restart after the update, and I had one CI job (automated test run) that was running at the time and had to be re-triggered. For a small personal instance, this is invisible. For a team that runs Gitea in production with multiple users, an unplanned four-minute restart is real cost, and the sensible default is to schedule the update for a maintenance window, not to do it the morning the digest lands.
Running an audit on every self-hosted service is not free in time. My twenty-minute audit covered two services. A typical self-hoster has more than two services. Auditing ten services takes the better part of an afternoon, and the audit is not the kind of work that produces an obvious deliverable, which makes it easy to skip.
Following the pattern check on every new service is not free in attention. Most self-hosted services are fine. The pattern check is the kind of thing you do once per service and then forget. The discipline is in remembering to do it before the first deployment, not after the first CVE.
Anyone who runs services exposed to the public internet should run the three-question pattern check on each one. The check is five minutes per service. The cost of skipping it is the cost of being the next NoScope disclosure.
Bottom line
The Gitea CVE is the security story of the week for self-hosters. Patch your instance the same day. Audit your other services for the same shape of vulnerability. Subscribe to the security advisory list for the projects you depend on, and read it when it lands.
The Vatican document is the longer story, and I will write about it separately when I have finished reading. The digest author’s instinct to put the two stories next to each other was the right call. The self-hosting community is going to be dealing with the gap between “the people who built the tool” and “the people who run the tool” for years. The Gitea CVE is what that gap looks like when it is acute. The Vatican document is what it looks like when it is philosophical.
If I could send a message back to the version of me that first set up a self-hosted Gitea, I would say four things.
- Patch the same day the CVE drops. The cost of an unplanned restart is small. The cost of being in a disclosure is large.
- Audit your other services for the NoScope shape. External exposure, no authentication, no log entry. Twenty minutes per service.
- Subscribe to security advisories for everything you self-host. RSS or email, your choice, but pick one and keep it tidy.
- Read the digest. Self-Host Weekly is one of the few newsletters that consistently catches the things that matter before they hit the security press.