DEV Community: Daniele Michelin

Nextcloud: Collabora's built-in CODE server is being exploited. Check it today

Daniele Michelin — Sun, 25 Oct 2026 07:42:07 +0000

If you run Nextcloud with the built-in Collabora server, stop and check this today. CVE-2026-110447 is an OS command injection in the app Collabora Online - Built-in CODE Server (richdocumentscode). It needs no login and no user interaction, it is rated CVSS 4.0: 9.2, and attackers have been using it since September. CISA added it to its list of known exploited vulnerabilities on 23 October, with a deadline of 26 October for US federal agencies.

Who is affected

Affected: the app richdocumentscode in every version before 26.4.303, even when the app is disabled.
Not affected: a separate Collabora server (Docker, DEB/RPM packages), Nextcloud All-in-One, and Nextcloud Office (richdocuments) when it talks to a separate Collabora server. Those two apps have similar names, so check which one you actually have.
Nextcloud 29 and older: the newest app version you can install there is 26.4.104, which is vulnerable. You need to remove the app or upgrade Nextcloud.

How the attack works, in short

The app has a script, proxy.php, that starts the bundled Collabora server when a request arrives and nothing is listening. In the vulnerable versions the request path was put inside a double-quoted shell command. The shell expands $(...) there, so a command hidden in the path runs as the web server user. The attack works while the local CODE server is down, for example after a restart, an upgrade or a crash.

Attackers dropped a one-line PHP web shell into the app folder and then looked for password databases, password manager files and cryptocurrency wallets. The first logged attack was on 10 September, one day before the fixed version was released. The CVE and the advisory only came on 14 October, more than four weeks after the fix. That is the real lesson: waiting for a security alert would have been too late.

Check in five minutes

cd /var/www/nextcloud
sudo -u www-data php occ app:list | grep -i richdocuments
sudo -u www-data php occ integrity:check-app richdocumentscode
find apps/richdocumentscode -name 'shx*.php'
find apps/richdocumentscode -name '*.php' -exec sha256sum {} + | grep 4b9fbd0663fbfd60

The first line shows whether you have richdocumentscode (the built-in server, vulnerable) and which version. The second runs Nextcloud's integrity check for the app. The last two look for the web shells reported so far: files named shx….php and the hash of the one-line shell.

Then the logs, back to at least 10 September (rotated logs included):

zgrep -hE 'richdocumentscode/proxy\.php' /var/log/nginx/access.log* \
  | grep -E '\$\(|%24%28|IFS|base64|%2e%2e'
zgrep -hE '139\.28\.18\.122|89\.38\.98\.50' /var/log/nginx/access.log*

Every hit in the first command is a request that tried to inject something. The two IP addresses are those named in the public reports. Logs rotate, so no hit does not prove you were not attacked earlier.

Fix it

Update: sudo -u www-data php occ app:update richdocumentscode. Fixed versions are 26.4.303, 26.4.402 and 26.4.502 (Nextcloud 30 and newer). Some admins reported start problems with 26.4.402 in mid-October and went back to 26.4.303.
Or remove it if you do not use the built-in server: sudo -u www-data php occ app:remove richdocumentscode. Disabling is not enough, Collabora says so explicitly. For editing documents, a separate Collabora server is the cleaner setup anyway.
An update does not remove a web shell. Run the checks above after updating, not only before.

If you find a web shell

Treat it as a compromise. The web server user can read config.php, so the database password, the instance secret and any stored credentials must be considered exposed. My advice: take the server out of reach, restore from a clean backup if you are unsure how far it went, rotate the database password and the secrets in config.php, and have users change passwords and app passwords. In the reports no root access was seen, but that is no guarantee.

A few tips

Remove optional apps you do not use. Every app is attack surface, and this one runs a server process of its own.
Separate Collabora server or All-in-One keep the document server away from your Nextcloud files.
Update apps on a schedule, not when a headline appears. The fix existed for more than a month before the advisory.
Keep an inventory: which Nextcloud apps run where. It makes a day like today a five-minute job.

Sources: BleepingComputer, The Hacker News and eSecurityPlanet. More Nextcloud commands in the occ cheat sheet. For comparison: my post on the PHP emergency patch.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

Mitigating PHP2Shell when no update exists yet: php.ini settings for NAS, Plesk and your own servers

Daniele Michelin — Fri, 23 Oct 2026 21:54:29 +0000

Fixes for the PHP2Shell flaws (CVE-2026-109618 and CVE-2026-109619) have been available since 21 October 2026 in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. On many systems the packages arrive later, for example on NAS devices such as Synology, where PHP comes through the Package Center. The blog mariushosting describes a Synology stop-gap based on a few PHP settings. Here I put them in context and show how to set them on Plesk and ordinary servers too.

First, important: this is not a fix

According to the PHP advisory only the update protects completely. Settings like the following reduce individual attack paths. They are a plaster for the time until the package arrives, not a replacement. As soon as your vendor ships a patched version (8.2.35, 8.3.36, 8.4.27 or newer), install it and only roll the stop-gap back if your application needs that.

The three settings

session.upload_progress.enabled = 0: turns off the upload progress feature that works through the session. That mechanism processes data already during the upload, so switching it off is the first measure.
session.use_only_cookies = 1 and session.use_cookies = 1: session IDs are only accepted via cookies, not via URL or form fields.
session.use_strict_mode = 1: PHP does not adopt a session ID it did not issue itself.

Side effect: applications that build an upload progress bar from PHP sessions will no longer show it. The upload itself keeps working.

How to set them

Synology Web Station: open Web Station, “Script Language Settings” on the left, choose the PHP profile, “Edit”, “Core” tab. Set session.upload_progress.enabled from 1 to 0 and the three session.use_* values to 1. Then check that your website really uses this profile (Web Service in the sidebar). The source blog states the effect for PHP 8.4, 8.3, 8.2, 8.0 and older.

Plesk: domain, “PHP Settings”, field “Additional directives”:

session.upload_progress.enabled=0
session.use_only_cookies=1
session.use_cookies=1
session.use_strict_mode=1

Your own server: create a file in the conf.d of the affected PHP version (for example 99-php2shell.ini) and restart PHP-FPM or Apache.

Containers: mount the file as an ini into the image (volume to /usr/local/etc/php/conf.d/) and restart the container.

Check that it works

php -i | grep -E "session.upload_progress.enabled|session.use_(cookies|only_cookies|strict_mode)"

That shows only the CLI values. For the website itself, briefly open a small page with phpinfo() and delete it afterwards, or check the domain's settings in Plesk. Important: restart PHP after the change.

Other measures that are mentioned

According to the report by The Hacker News, the PHP team additionally suggests for CVE-2026-109618 to set memory_limit=-1 (so applications cannot override it), keep post_max_size low and enforce size limits at the web server already. Read the advisory and test whether your applications can live with those values.

My recommendation

First check which PHP version really runs and whether a patched build exists.
If not: set the stop-gap, test the application, leave a dated note.
Check the Package Center or your host regularly and install the update as soon as it appears.
Where possible switch to a handler with timely updates, as I described in my post on the PHP emergency patch.

Source of the Synology guide: mariushosting.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

PHP emergency patch (PHP2Shell): how to check and patch your servers

Daniele Michelin — Fri, 23 Oct 2026 21:38:39 +0000

On 21 October 2026 the PHP team released emergency updates for two critical vulnerabilities (CVE-2026-109618 and CVE-2026-109619, together “PHP2Shell”, 9.2 each on CVSS 4.0). They sit in the runtime, not in an application: even a “Hello World” page on a vulnerable PHP version can be attacked, without any account. The fix is in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Researchers at Wiz, Calif and OpenAI found them.

Why updating the application is not enough

Updating WordPress, Laravel or Nextcloud changes nothing about the PHP version underneath. That comes from the server package, the host or the container image. According to the PHP advisory every way of running PHP is affected (PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, LiteSpeed). mod_php is the most dangerous: a single request can trigger the attack before any application code runs. In addition, memory of the PHP process can be read, and it may hold passwords, tokens and keys of other requests.

Step 1: find every PHP installation

A server rarely has just one PHP. Typical places:

The distribution package (php -v, php-fpm).
Panel-provided versions, for instance Plesk under /opt/plesk/php/*.
Containers: Nextcloud, WordPress and others ship their own PHP in the image (docker exec NAME php -v).
Extra handlers per website that sit on a different version than the rest.

php -v
ls /opt/plesk/php/ 2>/dev/null
for c in $(docker ps --format '{{.Names}}'); do echo -n "$c: "; docker exec $c php -v 2>/dev/null | head -1; echo; done

Compare each version with the table: below 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 is vulnerable. PHP 8.1 and older no longer get updates, there are only source backports for 7.4, 8.0 and 8.1; 8.2 ends on 31 December 2026.

Step 2: patch and restart

On Debian/Ubuntu the usual apt update && apt upgrade. Important: distributions often ship the fix under an “old” version number, so check the package changelog for the CVE number, not just the version string. Then restart PHP-FPM or Apache, including long-running PHP workers. Without a restart the old code keeps running.

Worked example: my server tonight

On my Plesk server I had three sources: the Ubuntu system package (8.3.6), Plesk PHP 8.5.11 and two Docker images with their own PHP. Result:

Plesk PHP 8.5 updated to 8.5.12 through the Plesk installer.
For the Ubuntu package there was no fix yet. Instead of waiting I installed Plesk PHP 8.3 (now 8.3.36) and moved the websites to that handler. Same minor version, so little compatibility risk. Then I tested each site individually.
The containers (Nextcloud AIO) still carry an older PHP. Only the new image helps there, once it is released.

Synology, Plesk, shared hosting, Docker: what to do?

Shared hosting (e.g. at STRATO or IONOS): PHP is run and updated by the provider. Check in the control panel which PHP version the site uses and switch to a supported one. Keep your own application (WordPress, Nextcloud, shop) up to date anyway. This is my professional view, not a statement by any provider.
Plesk: every PHP version is a separate package. Install the updates via the Plesk updater or the package manager, then check: /opt/plesk/php/8.3/bin/php -v (for each installed version) and plesk bin php_handler --list.
Synology: PHP comes with Web Station and the Package Center. Until Synology ships an update, the only option is the php.ini mitigation: guide for NAS, Plesk and your own servers.
Docker and containers: the fix is in the image. docker compose pull && docker compose up -d, then docker exec <container> php -v.

A few tips

Inventory first: write down where PHP runs (system, panel, containers). Next emergency you save the search.
Avoid mod_php: switch to PHP-FPM where you can. It reduces the attack surface and allows separate pools.
Test after every switch: home page, login, forms, cron jobs. A 200 on the home page is not enough.
Workarounds are not a fix: limits such as a small post_max_size only reduce individual attack paths. The update stays mandatory.
Plan for end of support: anyone on 8.1 or older needs a migration plan, not just this patch. 8.2 ends in two months.
Watch your secrets: because memory could be read, rotate tokens and keys if you see suspicious traces.

Sources: The Hacker News and the PHP security advisory.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.

Three critical NGINX flaws: less dramatic than PHP2Shell, but patch them quickly anyway

Daniele Michelin — Fri, 23 Oct 2026 21:38:34 +0000

A sysadmin never quite sleeps. PHP has barely been patched and F5 reports three critical flaws in NGINX Open Source and NGINX Plus, each rated CVSS 9.2. They can crash individual workers (DoS) and, under some conditions, lead to code execution. The good news: unlike PHP2Shell, not every installation is automatically exposed. It depends on specific directives. The bad news: there is no official interim mitigation, only the update.

The three flaws in one sentence each

CVE-2026-15176: heap overflow when alias meets rewrite plus a set or return that uses $request_filename. $request_filename in an access-log format is enough as well.
CVE-2026-97205: use-after-free when asynchronous file I/O (aio) is enabled and SSI pages with virtual includes are processed.
CVE-2026-93479: heap overflow with regular expressions in map when root or a log format uses capture variables before the map output.

All three affect the data plane only. Code execution additionally requires ASLR to be bypassed. No active attacks are known at the moment.

Which versions?

NGINX Open Source is fixed in 1.31.7 and 1.30.6. NGINX Plus in 37.1.0.1 and 37.0.5.1; R33 to R36 get no fix in their branch, only a migration helps. Older versions are partly affected too, back to very old releases.

Check in five minutes

nginx -v
nginx -T 2>/dev/null | grep -nE 'request_filename|^\s*aio\s|^\s*ssi\s+on'
nginx -T 2>/dev/null | grep -nE '^\s*map\s'
for c in $(docker ps --format '{{.Names}}'); do docker exec $c nginx -v 2>/dev/null && echo "  ^ $c"; done

The first line shows the version. The second searches the directives of the first two flaws in the complete, resolved configuration (including included files). The third lists every map block: look closely whether regular expressions with capture groups are used and whether those captures appear in root or a log_format. The last line finds NGINX inside containers, which are easy to forget.

Patch depending on where NGINX comes from

Distribution: apt update && apt upgrade and search the package changelog for the CVE numbers. Distributions often ship the fix under an old version number.
Panel (Plesk, cPanel): the panel brings its own NGINX. Don't replace it by hand; wait for the vendor's update and keep automatic updates on. Check the configuration until then.
Containers: move the image to nginx:1.30.6-alpine or newer. If you don't want to rebuild the app, swap only the runtime layer: new NGINX image as the base, copy the built files and templates from the old image, recreate the container.

Then nginx -t and a reload. For containers, recreate them, a restart is not enough.

What it looked like on my server

The NGINX in front of my websites comes from the panel and was on 1.30.5. No patched package was available there yet. Checking the complete configuration showed: no $request_filename, no aio, no SSI, and the map blocks use no captures. So not exploitable, and the update will arrive automatically once the vendor ships it. One container with its own NGINX was still on 1.29.8. I moved it to 1.30.6 right away, without rebuilding the app.

A few tips

No reason to panic, but no reason to leave it either. The configuration can change with the next deployment. What is not exploitable today may be tomorrow.
Check the resolved configuration (nginx -T), not just your own file. Many directives come from panel or package includes.
Don't forget containers: front ends, admin interfaces and office services often bring their own NGINX.
Avoid floating tags: FROM nginx:alpine is convenient, but you never know which version is running. Pin a concrete version and raise it on purpose.
Keep a small inventory: where NGINX runs, where PHP runs, which image is where. After PHP2Shell two days ago it has already paid off twice for me.

Sources: NGINX security advisories and the Cyber Security Agency of Singapore. For comparison: my post on the PHP emergency patch.

Originally published at daniele-michelin.com. More guides, free checks (SPF, TLS, headers) and an error-message lexicon: daniele-michelin.com/en/.