Why Your Web Server Account Should Not Read Your Secrets

When attackers exploit a web application, they usually land as the web server account, not as root. Everything that web server account can read is then exposed: database passwords, API keys, backups, user files and anything else an administrator left on the box. Keeping that account's reach small is what decides whether an exploited bug becomes a contained cleanup or a full breach, and it works even against flaws you have not patched yet.

Why does the web server account matter so much?

The web server account matters because it is the identity most web exploits inherit. Command injection, file upload bugs and web shells all run with that account's permissions, so its file access defines the blast radius.

The October 2026 Collabora CVE-2026-110447 attacks on Nextcloud are a clear example. No report showed the attackers reaching root. They did not need it. Using a web shell that ran as the web server user, one attacker searched the server for KeePass databases, wallet.dat files and keystore.json files. The reporter's guidance afterwards was to treat any data the web server account could access as potentially exposed.

What can a web server account usually read?

On a typical self-hosted application, the web server account can read the application's configuration (with database credentials and signing secrets), the application database through those credentials, all uploaded and synced user data, and often much more than intended.

The "more than intended" part is where breaches grow:

• Shared hosts. Several applications run as the same account, so one bug exposes all of them.
• Admin leftovers. Exported databases, password manager files, SSH keys and scripts copied into home or web directories with loose permissions.
• Mounted storage. Network shares and external storage mounted for the application, often with broad credentials.
• Cloud metadata and tokens. Instance credentials or API tokens reachable from the host.
• World-readable files. Anything readable by every local account is readable by the web server too.

A file sync platform such as Nextcloud is an extreme case, because the account is supposed to read every user's files. That is the price of the product, and it is why the rest of the box needs to be clean.

How do you reduce what the web server account can reach?

You reduce it by running each application under its own account, removing everything from the host that the application does not need, and storing secrets the application does need where only it can read them.

Practical measures:

1. One application, one account. Separate service accounts or containers per application, so a bug in one cannot read another's config.
2. Nothing personal on the server. No password databases, wallets, exports or personal keys on hosts that run internet-facing applications. Move them, then check file permissions on what remains.
3. Read-only code. Where the application supports it, make code directories unwritable by the web server account so it cannot drop new scripts. This blocks most web shells; see what a web shell is and how it gets onto a server.
4. Scoped database users. Give the application's database user rights to its own database only, never server-wide privileges.
5. Remove optional components. Bundled add-ons widen what the account executes. The Nextcloud Built-in CODE Server app ran a document server as the web server user on the same host; a separate Collabora server would not have been affected.
6. Limit outbound traffic. Web servers rarely need to reach arbitrary internet addresses. Blocking that stops callbacks like the webhook.site requests seen in the Nextcloud attacks.

Why is this better than relying on patching?

Patching only protects you after a fix exists and you have applied it. Limiting the web server account protects you during the gap, which is often weeks.

The Collabora fix shipped on September 11, 2026, but the CVE was not published until October 14, and attacks started on September 10. Teams waiting for a CVE or a scanner alert had no warning for a month. During that window, the only control that mattered was how little the compromised account could read. The same logic applies to every zero-day and every silently fixed bug.

What should you rotate after a web shell is found?

Rotate every secret the web server account could read, not just the ones the application uses. Start with the database password and the application's own secrets, then API keys, mounted storage credentials and any personal credentials found on the host.

This is why the cleanup scope is set by permissions rather than by evidence. Logs rarely show exactly which files a shell read, so the safe assumption is "everything it could reach." Our guide on how to check for Nextcloud web shells covers the full cleanup sequence, and why you rebuild before you rotate credentials explains the order to do it in.

How do you audit this before an incident?

Log in as the web server account in a test session, or check effective permissions, and list what it can read outside the application's own directories. Anything surprising is your blast radius today.

Repeat the audit after server migrations and after administrators copy files onto the host. Record the result alongside the application inventory so that, when the next exploited flaw lands, you already know what to rotate.