DK
TR
← Blog

October 31, 2026

Self-Hosting Security Risks: Built and Abandoned Systems

self-hosting · security · patch management · linux kernel · homelab · infrastructure · privacy

Over the past two years a clear behavioral shift has taken hold. People are setting up their own small servers instead of renting centralized cloud services, and running the same jobs on open source software: storage, media server, password vault, photos, automation, a wiki. The reason is not only money. It is privacy, control, predictability, and the fact that nobody can tell you “we are removing that feature.” 2026 data shows the trend is still growing: 3,530 cataloged self-hosted apps, $7,700–9,200 in yearly savings, real SaaS alternatives at both personal and small-business scale.

This behavior has a cost, and the cost is usually invisible: the system stays the way it was on the day it was built. The owner does not know how it works, only that it works. As long as it works, maintenance feels unnecessary. Maintenance is remembered when something breaks, or when an alert finally arrives.

This post puts numbers on that silence. The short version: a machine installed as “up to date” in May 2026 is now dozens of releases behind, and some of the flaws inside those releases are already being exploited in the wild.

What the Data Says

One note on method, for transparency: kernel numbers come from kernel.org ChangeLog listings (1 May – 31 October 2026), application numbers from GitHub API release lists over the same window. Projects that do not use GitHub releases (PostgreSQL, Caddy, Proxmox) are outside these counts.

Here is the frame for the bigger picture: NVD published 86,533 CVE records in the first ten months of 2026, against 48,151 in all of 2025. Roughly 65,000 of those records fall into the six-month window this post covers. The tables below are the part of that 65,000 that never reached your machine.

Column chart of CVE records published per month from April to October 2026, rising from 5,885 in April to 15,074 in September, with roughly 65,000 records inside the six-month window

The Kernel: 185 Point Releases in 26 Weeks

Branch Point releases in 6 months Machine installed in May → today
5.10 (longterm) 19 5.10.271 → 5.10.274
5.15 (longterm) 20 5.15.222 → 5.15.225
6.1 (longterm) 21 6.1.174 → 6.1.191
6.6 (longterm) 24 6.6.141 → 6.6.161
6.12 (longterm) 30 6.12.91 → 6.12.115
6.18 (longterm) 34 —
7.x (current stable) 37 7.0.x → 7.3.1 (7.0 is EOL)

Seven releases per week on average. 185 point releases in six months means a machine you called “current” is now 20 to 37 versions behind. A significant share of those releases are security fixes, and some batches are heavy on their own: in the week of 24 July 2026, a single release candidate absorbed more than 2,000 patches. Debian’s 3 August update closed 68 kernel CVEs at once, including one that granted local root through the Open vSwitch path.

Bar chart of kernel point releases per branch over six months, from 19 releases on the 5.10 branch to 37 on 7.x, leaving a machine installed in May 20 to 37 versions behind

Three details make the table dramatic:

  • One week, 763 kernel CVEs. A single week at the end of July published 763 records; the week of 4–10 October carried 220 on its own, two of them CRITICAL (CVSS 9.8).
  • Some holes never reach old branches. For CVE-2026-98365 (software RDMA rxe, CRITICAL), no fix is listed for 5.10, 5.15, or 6.1. Staying on an old branch can mean never receiving the fix at all.
  • An older branch means fewer backports. Of 140 fixes older than 6.6, 99 were backported to 6.6 and 120 to 6.12; 6.1 got 86, 5.15 got 67, 5.10 got 58. Both 5.10 and 5.15 reach end of life in December 2026.
Project Before 1 May (the moment it was installed) Releases in 6 months Today
Home Assistant 2026.5.0b0 71 2026.11.0b2
n8n — 277 stable
Traefik v3.7.0-rc3 43 v3.8.0-rc1
Nextcloud Server v33.0.x 62 v35.0.2
Redis / Valkey — 42 / 22 8.12-rc1 / 9.1.3
Syncthing v2.1.0-rc1 25 v2.1.7
Immich v2.7.5 25 v3.4.0-rc1
paperless-ngx v2.20.15 21 v3.4.1
Portainer — 16 2.45.3
Jellyfin v10.11.8 15 v12.4
nginx 1.30.0 15 1.31.8
Uptime Kuma 2.2.1 14 2.5.9
Gitea v1.26.1 11 1.27.x → 28.2.0
Docker Compose — 9 v5.6.1
FreshRSS 1.28.1 7 1.30.4
Vaultwarden 1.35.8 6 1.37.4
Umami 3.1.0 5 3.4.1
Pi-hole v6.4.2 2 v6.5
MinIO October 2025 0 still October 2025

The last row is a story by itself. MinIO’s GitHub release list has stood still for 379 days. A MinIO installed six months ago now sits on a line nobody publishes to. The most dangerous state is not being behind. It is having no one left to tell you that you are.

The Wall of Open Flaws That Piled Up

Releases moved forward on one side. On the other side, this is what accumulated inside them:

  • Nextcloud / Collabora: a critical OS command injection (CVE-2026-110447). Exploitation started in mid-September 2026; the advisory and CVE landed in October, roughly a month after the flaw was live in the field. Censys counted 19,454 hosts. The result: PHP web shells and backdoors. CISA due date 26 October. The PHP layer underneath was broken too. The PHP2Shell flaws let an attacker run code as the web server account, with memory disclosure that can leak passwords and API keys. PHP shipped fixes on 23 October 2026.
  • Plex Media Server: a chain of four CVEs (Plex2Shell). Discovered 27 July, patched 3 August in 1.43.3.10861, added to the CISA KEV catalog on 20 October. Throughout the gap, scanning bots swept port 32400 in bulk. A home media server, among the first targets of mass exploitation.
  • Gitea: repo write access plus diffpatch allowed adding a Git hook and running shell commands (CVE-2026-60004). It entered KEV on 25 August with a due date of 28 August: three days. July also brought 6 reviewed advisories (3 High, 1 Critical).
  • Home Assistant: unauthenticated path traversal in the onboarding screen allowing file writes to any directory (< 2026.6.0); mDNS SSRF (< 2026.2.3).
  • Jellyfin: advisory waves in June and September 2026, one Critical, memory exhaustion and SSRF through SVG, broken session remote-control access checks.
  • Vaultwarden: brute-force protection bypass (CVE-2026-43914), IDOR reading another user’s cipher details (CVE-2026-27898), 2FA bypass. Fixes in 1.35.4 and 1.36.0.
  • GitLab (self-managed): a max severity flaw affecting every release since 2014.
  • GitHub Enterprise Server (self-managed): remote code execution through a single git push (CVE-2026-3854, April 2026). Researchers found the large majority of internet-facing installations affected.

Each line on its own invites the same reaction: “we’ll get to it.” Side by side, they form a picture. Every layer of your stack used the word “urgent” at least once in the past six months.

The Real Problem: the Patch Exists, the Application Does Not

  • Verizon 2026 DBIR: 35% of KEV entries are still open on day 28 (from 31 million open instances in 2022 to 184 million today).
  • Edgescan’s measurements: real remediation takes ~74 days for critical application flaws and ~65 days for critical network and device flaws. Meanwhile Cyber Essentials v3.3 (effective 27 April 2026) automatically fails any critical patch older than 14 days; PCI DSS allows 30.
  • The attacker’s schedule runs the other way. Mandiant measures the median time from a CVE going public to the first exploitation attempt at under five days. Work that takes you two and a half months is finished by the other side in a weekend. Vulnerabilities that already had a patch published are the path used in roughly 60% of breaches, and 32% of vulnerabilities stay unpatched for more than 180 days.
  • OpenLogic 2026: patching is still the hardest topic in open source. 20% of organizations have no CVE process at all; 39% of large companies cannot meet their own SLAs; after software goes EOL, most teams lack the capacity to patch it themselves.
  • Sonatype 2026: 65% of open source CVEs never get a score in NVD, and the median time-to-score is 41 days. PoCs and maintainer patches appear within hours. The hole is known long before the official warning, but without a score the user cannot prioritize it.
  • KEV 2026: the catalog holds 1,665 entries, with 181 additions in its first 223 days (roughly 296 projected for the year, a record outside backfills).
Comparison of the five-day median time to first exploitation against the 14-day Cyber Essentials patch limit and the 65 to 74 day measured remediation times

And a neat paradox: 100% of the self-hosting community uses pinned tags, and 98.4% use restart: unless-stopped. Good habits for reliability, and also the technical definition of staying exactly as installed. A pinned tag is a frozen system until someone touches it. In 315 guides, 33 mount /var/run/docker.sock: root-equivalent access on top of a host that never gets updated.

Missing Knowledge Becomes Missing Security

A machine installed six months ago is not merely “37 releases behind.” The real difference is here:

  • An installation is an event; running one is a relationship. The person who followed a guide does not know why each part is there, so an update feels like a risk. They cannot size the risk, so they postpone it. First contact happens during a failure, and on failure day the backlog is six months deep.
  • The window you miss is the attacker’s working day. The gap between a CVE going public and you learning about it is, in practice, the duration of active exploitation.
  • A postponed patch turns maintenance into a project. Jellyfin 10.11 → 12.4, Nextcloud 33 → 35, paperless-ngx 2 → 3, Gitea 1.x → 28.x. A major bump means schema migrations and application compatibility. A week of work becomes a six-month project. Planning the update path across a scattered fleet is a job of its own; how a thousand devices get their update path is something I have written about before.
  • What gets abandoned is not only software. Sometimes it is a credential. In the Internet Archive’s 2025 breach, 31 million records were stolen through an auth token left exposed in a code repository for nearly two years. There was no elaborate attack. A forgotten credential kept working because nobody ever reviewed it.
  • On the kernel side the information loss is even quieter. uname -r prints “6.12.91”. It does not print which CVEs that number is missing, which branch you are on, or when that branch dies.

Agentic setups close part of this gap: Home Assistant 2026.10 brings one-click MCP connections, and Watchtower is among the lightest tools around at 15 MB. But an agent can break a system it does not understand. Without an inventory that tells the agent what is, not what to do, automation only makes mistakes faster. The first results of that wave are already measured: in a May 2026 scan, 31% of reachable Ollama inference servers answered unauthenticated requests, and a separate pass counted more than a million exposed AI services on the open internet. Easy installation without maintenance culture turns directly into attack surface.

The Same Machine, Two States

kernel       6.12.91     → today 6.12.115     (30 releases, mostly security)
jellyfin     10.11.8     → 12.4               (2 majors, June + September advisory waves)
nextcloud    33.0.x      → 35.0.2             (+ Collabora RCE, exploited in the wild)
gitea        1.26.1      → 28.2.0             (+ KEV-listed code injection)
vaultwarden  1.35.8      → 1.37.4             (+ brute-force oracle, IDOR)
plex         1.43.2      → 1.43.3.10861       (4 CVEs, mass scanning, KEV)
php          8.3.35      → 8.3.36             (PHP2Shell, password exposure risk)
minio        Oct 2025    → Oct 2025           (0 releases in 6 months)
knowledge    "it works"  → still "it works"

A system left as built is not neutral. Something changes every week. If the system does not change, the world around it does, and the difference compounds against you.

How to Keep Self-Hosted Services Updated: The 30-Minute Audit

Whether these numbers apply to your own machine takes half an hour to find out:

  1. Inventory. Write the output of docker ps, or your NAS app list, somewhere permanent. Anything you cannot name goes to the top.
  2. Version and support status. For each service, note the running version and whether upstream still maintains it. End-of-life software is worse than being behind, because there is no patch to install. Nextcloud’s public security scan grades a reachable instance in seconds.
  3. Exposure. From a phone on mobile data, not your home Wi-Fi, try to reach every service. Every response is a finding. A simple port scan of your public IP confirms the same list.
  4. Patches and backups. When did the OS last receive security updates? Is your backup newer than your worst-case scenario, and has a restore ever been tested?
  5. Logs. A week of system errors and reverse proxy access records. Repeated login attempts are noise and normal. Silence from a service that logs nothing is not normal.

Write the result down, ugly or not. “Internet reachable and unpatched” sorted to the top is your work list for the month.

Conclusion: Owning Means Accepting Maintenance

What makes self-hosting valuable is control, privacy, and predictability. All three are things maintenance names. Control is yours only as far as you can patch. Privacy lives not in a system you cannot explain but in one you inspect and keep updated. A server you built and walked away from is not yours: over time it becomes a machine you no longer recognize. If the owner cannot explain how the system works, the system is no longer working. It has simply not broken yet.

The right question is not “which is better?” but “who is the ops team?” In the cloud the ops team is the provider, and maintenance is a contract made invisible. In self-hosting the ops team is you, and when you are not there the system runs in a gap nobody has accepted responsibility for.

  • Self-host what you can maintain.
  • Use a managed or commercial solution for what you cannot. This is not retreat, it is an honest boundary. Opening a system to the internet that you cannot patch within 14 days is not control. It is owning the lack of control.
  • The healthy 2026 profile is hybrid: your own hardware for non-critical loads, managed services where your endurance runs out. What matters is knowing which layer belongs to you.

If you want to run this audit on your own machine and talk through where to start, let’s talk hardware.

Two Kinds of Maintenance

Physical: dust, airflow, fans, temperature, power and UPS, disk health (SMART), a spare disk, cabling and labeling. A machine that stays silent on the software side for six months ages silently on the hardware side too.

System: uname -r and the package list, the GHSA/KEV feed, the patch window, migration notes, restore tests.

Cadence Work
Weekly Patch check, KEV/advisory alert, one minute of looking
Monthly Physical check: dust, temperature, fans, SMART, UPS. One backup test
Quarterly Major version and migration plan, restore drill, EOL branch check
Yearly Hardware review, spare disk replacement, “why is this part here?” inventory

The simplest rule: a tool you cannot maintain is not a tool, it is a liability. You clean and oil a drill once a year. Give your self-hosted stack the same seriousness and six months from now it will not be a machine you no longer recognize.

Do not build and walk away. Own what you tend, and know what you own. The beauty of self-hosting equals the volume of your knowledge, and that knowledge is born from a few minutes a week.

Frequently Asked Questions

How often should I update my self-hosted server? OS security updates weekly, containers and apps every two to four weeks, a full audit monthly. The kernel alone ships weekly stable releases and batches can be heavy; any rhythm slower than monthly leaves a measurable gap.

Is self-hosting safer than the cloud? Not automatically. You gain control over where your data lives, and you inherit patch management, backups, and exposure monitoring. Without that second half, a self-hosted setup can end up riskier than the cloud it replaced.

Do I have to expose my services to the internet? Usually no. VPN-first access through WireGuard or Tailscale keeps services off the public web while staying reachable from your phone. Reserve public hostnames for services that genuinely need them, behind a reverse proxy with HTTPS.

I set up my server with an AI assistant. Is that a problem? No, but the configuration is unowned until you document it. Write down what each service does and why each port is open. If you cannot explain a line in your compose file, learn it or remove it.

How do I tell whether my server has already been compromised? Start with the audit above, then look for the specific signs: unknown processes or containers, CPU load you cannot explain such as cryptomining, unexpected new admin accounts, unusual outbound traffic, and modified startup files. If a service you run has a known exploited flaw and an old version, treat compromise as possible, patch, and restore from a clean backup.

Sources