Is It Safe to Self-Host Apps Like Nextcloud or Plex on the Internet?

Yes, self-hosting Nextcloud, Plex and similar apps can be safe enough, if you maintain the server rather than set it up once. Keep it behind a VPN or an identity check, patch the app, its add-ons and its container image within days, keep tested backups out of the server's reach, and watch for files you did not create.

The servers that get broken into are rarely the cleverly configured ones. They are the ones nobody updated, running an add-on nobody remembered, published on a forwarded port.

Key takeaways

• Reduce exposure first. An app behind a VPN or a login at the proxy never sees most attack traffic.
• Patch three layers. The app, its add-ons, and the image or host all ship fixes on separate schedules.
• Know your container update model. Some images need a pull plus a recreate; others update the app on restart.
• Automate updates. Unattended host updates and scheduled image pulls remove most of the delay between a fix existing and running.
• Back up for a rebuild. After a compromise you rebuild, so backups must be off server and restore tested.
• Watch for new files. In October 2026, Nextcloud admins found intruders through an integrity check and failed sudo emails.
• Pick software with a visible security process. Advisories and honest release notes beat star counts.
• Managed hosting is a valid answer when nobody will patch within a week of an advisory.

Why so many people are asking this now

Two stories landed in the same fortnight in October 2026, and both hit the exact audience that self-hosts.

The first was a chain of four Plex Media Server flaws, collectively called Plex2Shell. TechCrunch reported on 21 October that attackers were exploiting the four already patched flaws. We covered the details, versions and timeline in our Plex2Shell post: the fixed build had been out since early August, yet tens of thousands of servers were still reachable and unpatched when exploitation started in mid October. An older Plex flaw is covered in our post on CVE-2020-5741.

The second involved Nextcloud. According to The Hacker News, attackers used a command injection flaw in the "Collabora Online, Built-in CODE Server" app (package name richdocumentscode), an optional add-on that runs an office document server inside Nextcloud, to plant PHP web shells. The Hacker News reports the first logged attack on 10 September 2026, a fix in version 26.4.303 released on 11 September, and a CVE record published on 14 October. Two details matter for everyone who self-hosts: the fixed release's notes did not call it a security fix, according to the same report, and the advisory said disabling the app was not enough; it had to be upgraded or removed.

Both punished the same habits: direct exposure, untracked add-ons and unread release notes.

What makes a self-hosted app risky once it faces the internet?

A self-hosted app on your LAN is mostly protected by the fact that nobody outside can reach it. The moment you forward a port or publish it through a proxy, internet wide scanners can find and test it. Four things then decide whether that matters.

Plugins, add-ons and integrations

Most popular self-hosted apps are platforms with app stores, plugins or integrations. Each add-on is code from a different team, often less reviewed than the core, running with the same permissions.

In the Collabora case the core Nextcloud server was not the problem. An optional app built a shell command from request text, and it ran as the web server account. The Hacker News reports that attackers searched one server for credential stores and cryptocurrency wallets, and that administrators were advised to treat everything the web server account could read as potentially exposed.

Slow or invisible updates

Many self-hosted apps do not update themselves. Some show a banner in an admin page nobody visits, some ship fixes under vague release notes, and some wait on an image maintainer to rebuild. In the Plex2Shell case the fix existed for more than two months before exploitation began, and many owners never heard that it mattered.

Default settings that assume a friendly network

Defaults favour easy setup: admin pages on the public hostname, automatic port mapping through UPnP, no login limits. Nextcloud's own hardening guide lists the changes you should make beyond the defaults: put the data directory outside the web root, keep debug set to false, restrict admin actions to trusted IP ranges, install on a dedicated subdomain, and isolate the instance in a segregated network because server side request forgery is outside Nextcloud's threat model.

The blast radius of the web server account

On a typical install, the app, its add-ons, its files and its configuration (including database passwords) are readable by one account, so code execution as that account exposes all of it. Running each app in its own container, with its own volumes and no access to the Docker socket, limits what one break in can reach.

Should you expose it at all, or put it behind a tunnel, VPN or identity-aware proxy?

The single biggest decision is how the app is reachable. Here are the common options, from most exposed to least.

A useful rule: if a service has no reason to accept requests from strangers, it should not. Share links and remote streaming are legitimate reasons. Admin pages almost never are.

What a reverse proxy does, and what it does not

A reverse proxy sits in front of your apps, terminates TLS and forwards requests to the right backend, giving you one place to manage certificates, headers and access rules.

Caddy's documentation shows the appeal: when Caddy knows the hostname it serves, it obtains certificates from ACME authorities (Let's Encrypt and ZeroSSL by default), redirects HTTP to HTTPS and renews on its own. It needs DNS pointing at your server and ports 80 and 443 reachable, unless you use the DNS challenge.

A reverse proxy does not make a vulnerable app safe. If it forwards every path, it forwards exploit requests too; both October flaws worked through ordinary HTTP requests. It helps only when you add rules: authentication in front, admin paths blocked from outside, or an allow list of paths clients need.

There is also a trap: behind a proxy, the app sees the proxy's address unless you tell it which proxy to trust. Nextcloud's reverse proxy guide asks you to define trusted_proxies explicitly and warns that a wrong forwarded_for_headers value "may allow clients to spoof their IP address." Brute force protection and admin IP limits both rely on that address being real.

VPN access

A VPN puts your devices on a private network with the server, so the app never listens on a public port. WireGuard's quick start shows how small the setup is: generate a private key with wg genkey, derive the public key with wg pubkey, configure peers by their keys, and let wg-quick handle bring up. The cost is that every device needs the VPN client, which is fine for an admin console and unworkable for a portal outsiders use.

Zero trust or identity-aware access

NIST's SP 800-207, Zero Trust Architecture, published in August 2020, sets out the core idea: there is "no implicit trust granted to assets or user accounts based solely on their physical or network location." Authentication and authorization happen before each session with a resource, and protection focuses on the resource rather than the network segment.

For self-hosters, the practical version is an identity-aware proxy that checks who you are, ideally with multi factor authentication, before forwarding anything. Run one yourself or use a hosted tunnel with an access policy. Either way, an unauthenticated scanner never reaches the vulnerable code, though an attacker with a valid account still can. More on the model in what zero trust security means.

How do you know when a self-hosted app needs patching?

You need a signal for each layer, because each layer has its own source of fixes.

The app itself

Subscribe to the project's security advisories, not just its release feed, and check the running version against the latest on a schedule. Treat a point release with vague notes as possibly important until you know otherwise.

Add-ons and plugins

This is the layer people forget. Nextcloud's app commands let you list every installed app and see pending updates without installing them:

# list enabled apps and their versions
sudo -E -u www-data php occ app:list --enabled

# show available app updates without installing
sudo -E -u www-data php occ app:update --showonly

# update every app
sudo -E -u www-data php occ app:update --all

Run --showonly weekly and read what it lists. Removal is a valid fix too: occ app:remove <app-id> disables and removes an app.

The container image and the host

A container image carries an operating system layer and libraries with their own fixes; on bare servers, the host's packages do. We cover why rebuilding beats patching inside a running container in apt upgrade inside a container or rebuild the image, and the tag versus digest question in which base image reference patches faster. To get alerts only for what you run, see how to subscribe to advisories for only the packages you use.

How do container images change the update story?

Containers make updates easier to apply and easier to misunderstand. There are three common models.

Model one: the image carries the app

Most images bake in a specific app version, so you pull the new image and recreate the container. Docker's documentation is explicit that docker compose pull only downloads images and does not start containers, so running containers stay on the old image until you recreate them. docker compose up does the recreate: when a service's image or configuration has changed, it "picks up the changes by stopping and recreating the containers," keeping mounted volumes.

cd /srv/nextcloud
docker compose pull          # download newer images for every service
docker compose up -d         # recreate any container whose image changed
docker image prune -f        # optional: remove dangling old images

A common failure is running only the first command and assuming the update happened.

Model two: the container updates the app when it starts

Some images contain only a launcher, and the app is downloaded at start. The official Plex Media Server image works this way for its public and beta tags: on each start the container checks for an update, installs the latest version and launches the server. To update, you restart the container. The image's own operating system layer still only changes when you pull a new image, so you need both habits.

Model three: a manager container updates the rest

Nextcloud's All-in-One setup uses a mastercontainer that manages and updates the other containers. Its documentation says the daily backup flow can also update all containers, Nextcloud and its apps afterwards. You still have to turn it on.

Tags, digests and who rebuilds the image

A tag like latest moves when the maintainer pushes; a digest pins one exact image. Digests make deploys reproducible but you must bump them yourself. Floating tags update on pull but bring regressions too: The Hacker News notes a later Collabora app release broke startup for some admins, who reverted to the earlier fixed version. Either way, know who rebuilds the image and how quickly.

Automatic updates: what to switch on and what to watch

Automatic updates remove the human delay, which is the biggest risk for small teams. They occasionally break things, so aim for automation with visibility.

Host operating system. On Debian and Ubuntu, unattended-upgrades installs security updates on a schedule. The Debian wiki shows how to confirm it with sudo dpkg-reconfigure unattended-upgrades, recommends copying 50unattended-upgrades to a local file so changes survive upgrades, notes the default installs only security updates, and points to logs in /var/log/unattended-upgrades/. Set Unattended-Upgrade::Mail to hear what changed.

App and add-ons. Turn on update notifications; automate minor updates and keep major upgrades manual.

Container images. Schedule a pull and recreate right after a backup, and keep the last good image for rollback.

Reboots. Kernel and core library fixes need a reboot or restart.

The order that works: back up, update, check health, alert on failure.

Step by step: harden an internet-facing self-hosted app

This walkthrough uses a Docker based Nextcloud behind Caddy on a Debian host, but each step maps to other apps.

1. See what is actually exposed. On the host, list listening sockets and running containers.

sudo ss -tlnp                       # listening TCP ports and the processes behind them
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'

Anything bound to 0.0.0.0 that you did not mean to publish should be bound to 127.0.0.1 or removed. On the router, turn off UPnP and delete stale port forwards.

2. Put one reverse proxy in front. Only the proxy listens on ports 80 and 443. A minimal Caddyfile:

cloud.example.com {
    reverse_proxy 127.0.0.1:11000
    header Strict-Transport-Security "max-age=15552000; includeSubDomains"
}

The HSTS value matches Nextcloud's hardening guide. Test it in a browser before you add preload.

3. Tell the app which proxy to trust. In Nextcloud's config/config.php:

'trusted_proxies' => ['127.0.0.1'],
'overwriteprotocol' => 'https',
'allowed_admin_ranges' => ['10.8.0.0/24', '192.168.1.0/24'],

allowed_admin_ranges hides admin functions from anyone outside the listed ranges, per the hardening guide.

4. Put admin access and SSH behind the VPN. Generate WireGuard keys and bring up the interface as in the WireGuard quick start:

umask 077
wg genkey | tee privatekey | wg pubkey > publickey
sudo wg-quick up wg0
sudo wg show

Then close SSH on the router and allow it only on the WireGuard interface in your host firewall.

5. Limit login guessing. Nextcloud's hardening guide describes a fail2ban setup: set loglevel to 2 or lower so failed logins reach nextcloud.log, add a filter, and add a jail with maxretry = 3, bantime = 86400 and findtime = 43200. Check it with:

sudo fail2ban-client status nextcloud

Remember that this only works if trusted_proxies is right; otherwise every failure looks like it came from the proxy.

6. Turn on host security updates.

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure unattended-upgrades
sudo unattended-upgrade -d          # one manual debug run to see what it would do

7. Schedule app, add-on and image updates after a backup. A simple weekly script run from a systemd timer or cron:

#!/bin/sh
set -e
/usr/local/bin/backup-nextcloud.sh                       # step 8
cd /srv/nextcloud && docker compose pull && docker compose up -d
docker compose exec -u www-data app php occ app:update --all
docker compose exec -u www-data app php occ status

Adjust the service name (app here) and send the output somewhere you will see failures.

8. Back up to somewhere the server cannot delete. With restic, back up data and the database dump to a remote repository, then verify:

restic -r sftp:backup@backuphost:/srv/restic backup /srv/nextcloud/data /srv/nextcloud/db-dump
restic -r sftp:backup@backuphost:/srv/restic check --read-data-subset=5%

restic's documentation notes that a plain check verifies structure, not every pack file; --read-data verifies everything and --read-data-subset verifies a slice per run. Prefer append only or pull based setups so a compromised server cannot erase its backups.

9. Scan the images you run for known vulnerabilities. Scan the exact images in your compose file, since the operating system layer carries its own fixes. With the Safeguard CLI that is safeguard scan --image <name>, with JSON results under ./output.

10. Record a baseline. Run the app's integrity check and save the output, and keep a list of files in the web root with their hashes. Any later investigation starts by comparing against this baseline.

Backups that still work after a compromise

Most home backups cover hardware failure and mistakes, not an attacker. For that, three properties matter:

• Separation. The server should not hold credentials that can delete or overwrite old backups. Pull based or append only backups are far harder to wipe.
• History. Keep enough snapshots to go back before the intrusion. In the Collabora case, the first logged attack came more than a month before the CVE was published; seven days of retention would not reach a clean state.
• Restore tests. Restore to a spare machine a few times a year and confirm the app starts and files open.

Nextcloud All-in-One's built-in backup is based on BorgBackup and can create, restore, check and repair backups, according to its documentation. The same page warns that data stored outside its managed locations "will not be covered by the built-in backup solution."

What signs suggest a web shell or compromise on a self-hosted server?

A web shell is a small script an attacker drops into a web accessible folder so they can run commands later through ordinary HTTP requests. The joint NSA and Australian Signals Directorate information sheet Detect and Prevent Web Shell Malware recommends comparing server files against a known good baseline and using file integrity monitoring to catch unauthorised changes. For a general primer, see our post on PHP web shells.

Signs worth checking:

• New script files in app folders. In the Nextcloud cases, one administrator found the intrusion because Nextcloud's integrity check flagged a new PHP file, according to The Hacker News. Nextcloud documents occ integrity:check-core and occ integrity:check-app --all, which compare code against its signature; apps without a signature.json file are skipped.
• Unexpected outbound connections. The Hacker News reports attackers trying to send system information to a webhook address.
• Failed privilege escalation. Another administrator learned of the break in from failed sudo emails.
• High CPU from unknown processes. The Plex2Shell exploitation reported in our earlier post dropped cryptocurrency miners and proxy software.
• Odd entries in access logs. Unused paths, encoded traversal sequences or shell syntax in URLs; The Hacker News lists the patterns seen against the Collabora add-on.
• New accounts, app passwords or admin users you did not create, and new scheduled tasks or cron entries.

Commands for a first look (they do not prove a server is clean, they only find the obvious):

# script files changed in the last 30 days under the web root
sudo find /var/www -name '*.php' -mtime -30 -printf '%TY-%Tm-%Td %p\n' | sort

# Nextcloud code integrity
sudo -E -u www-data php occ integrity:check-core
sudo -E -u www-data php occ integrity:check-app --all

# processes owned by the web server account and their network connections
ps -u www-data -o pid,etime,cmd
sudo ss -tnp | grep -i www-data

# sudo attempts by the web server account
sudo journalctl _COMM=sudo --since '30 days ago' | grep www-data

For containers, docker diff <container> lists files added or changed in a container's filesystem compared with its image, a quick way to spot a dropped script.

If you find something

Do not just delete the file. Assume the attacker read everything the account could read. Take the server offline, preserve logs, rebuild from a clean image or a fresh install, restore data from a backup taken before the first sign of intrusion, and rotate every credential the server held: database passwords, app passwords, API tokens, SMTP credentials and any keys in config files. Then patch, and only then reconnect. If personal data of other people was on the server, check your local breach notification duties.

How do you pick self-hosted software with a healthy security track record?

You cannot predict the next critical flaw, but you can pick projects that disclose clearly and fix fast. Look for:

• A security policy and a private reporting channel. A SECURITY.md file or a security page that says how to report a flaw and what happens next.
• A public advisory history. Publishing advisories is a sign of honesty, not weakness. No advisories at all for a large, popular app usually means nobody is looking or nobody is saying.
• Clear release notes. The Collabora fix shipped under notes that named only a bundled component version.
• Release cadence and support windows. Is your major version still getting security fixes?
• Healthy maintenance. The OpenSSF Scorecard project rates open source repositories from 0 to 10 on checks such as Maintained, Security-Policy, Vulnerabilities (unfixed known vulnerabilities, using OSV data), Code-Review, Signed-Releases and Pinned-Dependencies. You can view results at scorecard.dev/viewer/?uri=github.com/<owner>/<repo> or run scorecard --repo=github.com/<owner>/<repo>. Scorecard calls its checks heuristics, so treat scores as prompts, not verdicts.
• Plugin governance. Are add-ons reviewed or signed, and is each maintainer visible?
• Container image ownership. Is there an official image from the project, and how quickly is it rebuilt after a base image fix?

Check the libraries a project is built on too. Gold Open Source is free, needs no login, and shows known vulnerabilities, affected and fixed versions, and OpenSSF Scorecard health for packages across more than 20 ecosystems.

The minimum hardening checklist

If you only do ten things, do these.

When is a managed version the better choice?

Self-hosting trades a provider's operations work for control and privacy, and the work does not shrink with the user count.

Many projects offer a hosted edition themselves. For teams the question is attention more than skill: a managed provider is paid to watch advisories daily, and if your team cannot promise that, managed is usually safer even at a higher monthly cost.

Common mistakes

• Forwarding the app's port directly "just for a bit". Temporary forwards become permanent.
• Pulling a new image and never recreating the container. docker compose pull alone changes nothing that is running.
• Restarting a self updating container for months without pulling a new base image. The app updates; the operating system layer does not.
• Disabling a vulnerable add-on instead of removing or upgrading it. The Collabora advisory said disabling was not enough.
• Trusting every proxy header. A missing or wrong trusted_proxies setting breaks brute force protection and admin IP limits, and can let clients spoof addresses.
• Keeping backups on the same server or a share the server can write to.
• Deleting a web shell and calling it fixed. Assume credentials and readable files were taken; rebuild and rotate.
• Ignoring release notes that look routine.
• Running every app as the same user on one host.
• Leaving UPnP on. Apps can open router ports on their own; check the router's port mapping table.

Fix it without waiting for upstream

Self-hosted apps are built from open source libraries and container base images, and the same two gaps apply to them as to your own code: the wait for a fix to exist, and the wait for that fix to reach what you actually run.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

Where Safeguard fits, and where it does not

Safeguard helps with the "what is in it and is it vulnerable" part. You can scan the container images you run (safeguard scan --image <name>), the source of anything you build yourself (safeguard scan --dir .) or an SBOM file (safeguard scan --sbom <file>). Findings are matched against vulnerability databases and come with fixed versions where one exists, and the platform shows which projects contain a given component and version. Policies and gates can stop a known vulnerable image from being promoted. For apps you build yourself, autonomous remediation can open the upgrade pull request.

It does not sit in front of your app as a proxy or VPN, does not detect web shells or intrusions on a running server, and does not replace the app's own updater or add-on store. The exposure, monitoring, backup and incident steps above remain yours.

FAQ

Is it safe to expose Nextcloud to the internet?

It can be, if you keep Nextcloud core and every installed app updated, follow the official hardening guide, enforce multi factor authentication, set trusted_proxies correctly behind a proxy, and restrict admin functions with allowed_admin_ranges. Remove apps you do not use; the October 2026 web shell attacks came through an optional add-on.

Is it safe to open Plex to the internet with port forwarding?

Only if you update Plex Media Server promptly and accept that the server is directly reachable. The Plex2Shell exploitation in October 2026 hit servers that were still on builds older than the fix released in August. If you do not need remote streaming, turn remote access off.

Is a reverse proxy enough to secure a self-hosted app?

No. It handles TLS and routing but forwards malicious requests too. It becomes a security control when you add an authentication step in front, block admin paths from outside, or limit which paths are reachable.

VPN or reverse proxy for self-hosting: which is safer?

A VPN is safer because the app is not reachable at all without a VPN key. A proxy with an identity check in front is a close second; a proxy with no authentication step is the least safe.

How often should I update self-hosted Docker containers?

Weekly is a reasonable default, with critical security fixes applied within a few days of release. Run docker compose pull followed by docker compose up -d, after a backup, and keep the previous image so you can roll back.

How do I know if my self-hosted server has been hacked?

Look for new script files in web folders, failed integrity checks, unknown processes using high CPU, outbound connections to unfamiliar hosts, sudo attempts by the web server account, and new admin accounts or app passwords. Their absence does not prove a clean server.

Should I turn on automatic container image updates?

Automatic image updates reduce the delay between a fix and a running fix, which is the main risk for most self-hosters. A bad release can break the app, so run them right after a scheduled backup, with notifications, and keep major versions manual.

Is self-hosting safer than using a cloud service for privacy?

It keeps data on hardware you control, which is a real privacy benefit. It is only safer overall if you maintain it as carefully as a provider would.

What is the safest way to share files from a home server with people outside?

Keep the server behind a VPN or an identity-aware proxy for normal use, and expose only the public share link paths if your app supports that, with expiry dates and passwords on shared links.

Do I need a firewall if my app is in a container?

Yes, and you also need to check how each port is published. A container port published without a specific address can be reachable from anywhere the host is reachable, so bind internal services to 127.0.0.1 in your compose file, publish only the reverse proxy, and confirm the result with ss -tlnp and a scan from outside your network.

See how Safeguard would help

The first demo is a real Safeguard CLI session: install, run safeguard to open the interactive terminal and ask it to "fix the lodash CVE in this repo". It reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing, then shows /permissions, /model and /scan .. The same flow applies when you build images for self-hosted tools and need a dependency upgraded before redeploying.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with its device code, and then runs scans from the terminal. For a home lab or small office, that is a weekly routine: scan your compose file's images on the machine that runs them, before and after pulling updates.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It lets an assistant look up findings for your scanned images without more access than it needs.

Click through it at your own pace, or open it full screen.

To try it on your own images, download Safeguard and follow the CLI documentation.

Related reading: Redis exposed to the internet, set up a safe home lab for web application testing and container image supply chain incidents in 2026.

Quick check

Sources

• TechCrunch: The internet is having a very bad cybersecurity day (21 October 2026)
• The Hacker News: Hackers backdoor Nextcloud servers (14 October 2026)
• The Hacker News: Weekly recap (October 2026)
• Safeguard: Plex2Shell, Plex Media Server flaws exploited
• Nextcloud Admin Manual: Hardening and security guidance
• Nextcloud Admin Manual: Reverse proxy configuration
• Nextcloud Admin Manual: Apps commands
• Nextcloud Admin Manual: Files and integrity check commands
• Nextcloud All-in-One on GitHub
• Plex Media Server official Docker image
• Docker Docs: docker compose pull
• Docker Docs: docker compose up
• Debian Wiki: UnattendedUpgrades
• WireGuard: Quick start
• Caddy: Automatic HTTPS
• NIST SP 800-207: Zero Trust Architecture
• restic: Working with repositories
• OpenSSF Scorecard
• NSA and ASD: Detect and Prevent Web Shell Malware

Last reviewed: 23 October 2026. Self-hosted apps and their add-ons change quickly; check each project's own documentation and advisories for current versions and settings.