Homelab Compromised: A Nextcloud RCE Incident and Lessons for Home Server Security

A homelab operator shared their full account of being compromised on Reddit. Their Nextcloud instance was breached via a remote code execution (RCE) vulnerability, with the attacker maintaining access as the web server user for roughly 16 hours. The incident exposed a specific technical flaw, but also raised a broader question: in an era of increasingly automated attacks, how safe are self-hosted home servers?

How the Vulnerability Was Exploited

The breach originated from CVE-2025-66208 — an OS command injection vulnerability in richdocumentscode, Nextcloud's built-in Collabora/CODE online document editing component. The attacker could achieve remote code execution without any authentication, running as www-data (the web server user).

What's notable is the attacker's behavioral pattern. Over roughly 16 hours of persistent access, the attacker executed only three distinct commands:

• Command 1: id was executed approximately every 3 minutes for several hours, simply to confirm the shell was still alive. This came from an IP with a generic bot User-Agent — clearly a fully automated mass-scanning bot loop.
• Commands 2 & 3: A real human operator logged in for about one minute, using HTTP/2 and a real browser User-Agent, running two reconnaissance commands looking for password manager databases (.kdbx files) and cryptocurrency wallet directories.

The manual reconnaissance turned up nothing — no database access, no config file reads, no data exfiltration tools, no second-stage payload downloads, and no persistence mechanisms were planted in the logs. The reason is straightforward: since the vulnerability itself could be re-exploited at any time, the attacker simply didn't need a backdoor.

This Was an Indiscriminate Automated Attack

Looking at the overall behavior, this looks more like an indiscriminate automated attack against a list of known vulnerable endpoints than a targeted intrusion after personal data. Even the single human session came away empty-handed.

The blog author confirmed via Unifi traffic logs that communication with the command-and-control (C&C) server was minimal, making it probabilistically likely that no data was exfiltrated. This serves as a reminder of the immense value of comprehensive traffic monitoring in post-incident forensics — without Unifi's logs, the author would have had no way to assess the scope of the damage.

The Overlooked Truth About the Patch

The most thought-provoking aspect of this incident is the problem with the patch itself.

The blog author had maintained good operational habits: updating Nextcloud whenever notified, and keeping the application current via a nightly cron job. According to the CVE advisory, this should have protected them — the advisory stated the vulnerability had been fixed 10 months earlier in version 25.4.703.

However, according to an analysis the author performed using an AI tool (Claude), the version they were running — 26.4.302 — was still vulnerable. The actual fix didn't arrive until 26.4.303, which was released just two days before the breach was discovered, and the changelog did not flag it as a security fix.

This means that even a diligent user strictly following official security guidance could be exposed to risk simply because the advisory information didn't reflect the actual state of the code. This kind of "patch advisory–actual fix mismatch" is an easily underestimated weakness in supply chain and vulnerability disclosure processes.

How the Incident Was Discovered

Ironically, the author discovered the breach entirely by chance. After receiving a Nextcloud notification and running an update, the code integrity checker flagged a malicious file. After some investigation and verification, they hit the "emergency button" and shut down the server.

This highlights the importance of built-in integrity verification mechanisms — it was the only link in the defense chain that actually worked. By contrast, the Unifi cyber-secure (WAF) feature they were using failed to block the attack.

Post-Incident Remediation

The author then took a series of containment and hardening steps:

• Stopped exposing Nextcloud directly to the internet: It's now only accessible via VPN.
• Rotated numerous credentials, including SSH keys.
• Rebuilt and hardened the web server (with assistance from Claude).

Retracting services behind a VPN is one of the most direct and effective ways to reduce a homelab's attack surface. For the vast majority of personal users, there's almost no reason to expose admin panels or document services directly to the public internet.

Open Questions

The author also raised several questions that remain unanswered, which are worth discussing:

Should this be reported to the vendor? They admitted to not knowing PHP and being unable to verify whether Claude's analysis was accurate. But if true, the community deserves to know and the CVE record needs to be corrected. This reflects a real limitation of AI-assisted analysis — it can provide leads, but expert human verification is still required.

Is running a homelab safe in the age of AI-driven attacks? This is an open question. Automated scanning bots can continuously sweep known vulnerable endpoints 24/7, and personal servers, once exposed, are easy targets.

What other tools are worth deploying? The author found that the WAF didn't perform as expected, and began questioning whether running Plex and mailinabox on DigitalOcean was wise.

Key Takeaways for Homelab Users

This incident offers several practical security insights:

• Don't expose services to the public internet by default: Put anything you can behind a VPN rather than exposing it directly — this is the highest-value defensive measure available.
• Don't blindly trust patch advisories: An official "fixed" designation doesn't necessarily mean you're actually safe. Maintain extra vigilance around high-risk components.
• Keep comprehensive traffic and access logs: Post-incident forensics and damage assessment depend heavily on them. It was precisely the Unifi logs that let the author confirm data was most likely not exfiltrated.
• Take built-in integrity checking seriously: Nextcloud's code integrity checker was the only alert source that actually worked in this case.
• WAFs are not a silver bullet: They can be one layer of defense-in-depth, but shouldn't be your only shield.

This incident is a vivid security lesson: even with good operational habits and timely updates, you can still be compromised due to flaws in the vulnerability disclosure process. For homelab enthusiasts, minimizing the attack surface, maintaining monitoring, and approaching official advisories with healthy skepticism may matter more than maximizing feature exposure.