A new vulnerability has been issued for PHP. When will we expect a fix to come out that is packaged with Unraid? Or will it be where we need to update PHP ourselves?

thank you

Thanks, but this has already been reported here: https://product.unraid.net/b/cve-reports/p/cve-2026-109618-cve-2026-109619-severe-php-vulns

That's the current board to report/follow any security issues

the keyword PHP2Shell was missing

On 10/21/2026 at 7:22 PM, frankcreamcity said:

A new vulnerability has been issued for PHP. When will we expect a fix to come out that is packaged with Unraid? Or will it be where we need to update PHP ourselves?

thank you

For future reference: a post like this — “a new PHP vulnerability” with no CVE number, no source link — reads as fearmongering. JorgeB’s reply below shows how to do it properly: name the vulnerability and link the advisory. This one happened to be widely reported, but usually that’s not the case, and an unsourced warning leaves readers with nothing but uncertainty. See vagueposting.

Edited October 23Oct 23 by Samsonight
clarification

We should address the elephant in the room. While Lime Tech doesn't produce Community Applications, but it knows full well that most of its users install their apps through it, as the PHP2Shell CVE report itself shows.

Patching the OS's own PHP within a day (7.3.4 release notes) was good. Marking that report "Completed" (status) while CA keeps offering images built on the same vulnerable runtime is not. Pointing at template authors doesn't make a known problem go away. And this is only about images bundling end-of-life PHP, before we even get to every other vulnerability in them.

Example: ownCloud, the only ownCloud server in CA

https://ca.unraid.net/apps/owncloud-1pime4b13gmkef (image dlandon/owncloud)

• 418,354 downloads, 9,052 this month, first seen 2018-08-11, privileged, port 443 (all from the CA page)

• The other ownCloud server template, for the official owncloud:latest image, is already marked Deprecated, so anyone searching CA for ownCloud today gets this one

What the image contains, pulled 2026-10-23 (built 2026-09-11). You can check any line yourself with docker run --rm --entrypoint dpkg-query dlandon/owncloud -W php7.4-fpm nginx mariadb-server and docker history --no-trunc dlandon/owncloud:

• Base: Ubuntu 22.04.5, in standard support until 2027 (Ubuntu release cycle)

• PHP: 7.4.33 via php-fpm from the third-party ppa:ondrej/php. Ubuntu 22.04 itself ships PHP 8.1 (Ubuntu). PHP 7.4 has been end-of-life since 2022-11-28 (php.net)

• The build recipe explicitly pins PHP 8.4 out (Pin-Priority: -1 for php8.4*, visible in docker history)

• ownCloud 10 "Classic", which only supports PHP 7.4 (owncloud/core#40811). ownCloud 11, which requires PHP 8.3, has been out since 2026-07-30 (release)

• A fresh install downloads owncloud-complete-latest, which still resolves to ownCloud 10.16.0 from 2025-11 (download.owncloud.com), although 10.16.6 is current (ownCloud)

• MariaDB 10.6 (held), nginx 1.18, redis, exim4, sshd, ImageMagick 6, Tailscale

The published image carries the pre-fix PHP build (7.4.33-30). The PPA's fixed build (-31) appeared on 2026-10-21 (Launchpad), with a patch titled "Minimal mitigation for EOL version" (diff). A container picks it up only if it is restarted with the template's AUTO_OS_UPDATES=1 (template). Users cannot tell from CA which build they have. Even ownCloud's own official image needed Freexian's paid PHP 7.4 LTS to get the fix (ownCloud, Freexian).

To be fair, the OS layer is otherwise reasonably current: a Trivy scan (trivy image dlandon/owncloud, 2026-10-23) found 0 critical issues outside the kernel headers. The problem is not neglect of the OS. It is an application kept alive on a runtime that its upstream stopped supporting four years ago.

Timeline of promises and deprecations

• 2018-08-11: dlandon/owncloud first seen in CA (CA page)

• 2018-12-31: the official Docker "owncloud" image is deprecated "in favor of the official owncloud/server image" (Docker Hub). CA marks its template Deprecated (CA page)

• 2019-11-28: PHP 7.4.0 released (php.net)

• 2022-11-28: PHP 7.4 end of life, last release 7.4.33 (php.net)

• 2022-12-02: ownCloud: "For community users we will provide a docker image with maintained PHP 7.4 free of charge", relying on "Ubuntu 20.04 will provide maintenance for PHP 7.4 till at least April 2025." (ownCloud)

• 2023-05-24: the issue "PHP 7.4 is past end-of-life, yet 7.4 is the only version supported" is closed 21 minutes after opening (GitHub)

• 2025-05: Ubuntu 20.04 standard support ends, and with it the basis of the 2022 promise (Ubuntu)

• 2026-04-24: ownCloud: "PHP 7.4 reached end of life, and running a production system on an unsupported runtime is a compliance problem." PHP 8.3 support for Classic is announced as pre-alpha (ownCloud blog)

• 2026-07-30: ownCloud Classic 11.0.0 released: "PHP 8.3 is now the minimum supported version." The built-in updater app is removed (release, announcement)

• 2026-09-11: the CA image is rebuilt, six weeks later, still on PHP 7.4 and with PHP 8.4 explicitly pinned out (docker history --no-trunc dlandon/owncloud)

• 2026-10-21: PHP2Shell (CVE-2026-109618/-109619, CVSS 9.2). "PHP 8.1 and older no longer receive updates from the PHP project" (php.net)

• 2026-10-22: ownCloud: "These vulnerabilities do affect OwnCloud Classic." It fixes its own images: ownCloud 11 through Ubuntu 24.04's own PHP 8.3 package, ownCloud 10 only through Freexian's paid PHP 7.4 (ownCloud, image details)

• 2026-10-22: Unraid 7.3.4 patches the OS's PHP (release notes) and the CVE report is marked Completed, with nothing said about CA images (report)

• 2026-10-23: the CA template is unchanged and still promoted, with no warning to its roughly 9,000 monthly installers (CA page)

From the template's own support thread (all 19 pages read)

• 2020-10-22, maintainer: "Because ownCloud is exposed to the Internet, it is important to update for security reasons." (page 10)

• 2022-06-24, maintainer: "Don't do an auto update, it will fail." (page 14)

• 2022-11-28: PHP 7.4 reaches end of life (php.net). The thread never mentions it, then or since

• 2023-01 and 2024-05: users ask for an ownCloud Infinite Scale (oCIS) version and get no answer (page 16, page 17)

• 2024-07 to 2025-08: no maintainer posts for 13 months while users report failures (page 17, page 18)

• 2025-08-04, maintainer: "Because of the Mariadb EOL cycle, it has become very difficult to build a new container using older versions of Mariadb." The image moves to Jammy and MariaDB 10.6 and drops PHP 7.2 and 7.3, but keeps 7.4. A frozen :legacy tag gets "no more updates" (post)

• 2025-10-26, maintainer: "The built in update hasn't worked for me for a long time." (page 19)

• 2026-09-12, maintainer: "Tailscale support added" (page 19). This came six weeks after ownCloud 11 on PHP 8.3 was released, and the thread doesn't mention it

The end-of-life MariaDB got dealt with because it broke the build. The end-of-life PHP never broke the build, so it never got dealt with, even after a PHP 8.3 ownCloud became available, and new features keep landing on top of it. A check of the rebuild date cannot see this.

How other catalogs handle this

• Flathub refuses EOL runtimes: "Submissions using an end-of-life runtime, extension or baseapp will not be accepted." (Flathub)

• F-Droid labels publicly instead of hiding the problem, with the anti-feature "Known Vulnerability" (F-Droid)

• Homebrew deprecates formulae when "the software installed by the formula has outstanding CVEs": warning first, then install fails, then removal, all on published dates (Homebrew docs)

• Google Play hides outdated apps from new users and keeps them for existing ones: "Existing apps must target Android 15 (API level 35) or higher to remain available to new users" (Google)

• WordPress.org: "Security is the ultimate responsibility of the plugin developer … Should a plugin be found to have security issues, it will be closed until the situation is resolved." (WordPress)

• Docker Official Images separates an automatic rebuild ("as a result of its base image being updated") from maintenance (docker-library)

• CA itself already has Deprecated, Incompatible and Blacklisted states, and may remove apps that "lack ongoing support" (CA docs). What's missing is a definition of support that a scheduled rebuild on a free CI service cannot satisfy on its own.

What I'm asking for

1. Define support by the runtime, not the build date. An image that ships a runtime past upstream end-of-life is not "supported", however recently it was rebuilt.

2. Detect it automatically, and keep checking. Scan listed images on a schedule against an end-of-life table such as endoflife.date, instead of relying on a one-time check at listing.

3. Flag it publicly where people install. Show an "End-of-life runtime / known vulnerability" badge on the CA page and in the install dialog. Notify existing users through Fix Common Problems.

4. Apply staged, dated consequences: a warning, then hidden from new installs but kept for existing users, then Deprecated. Give longer grace periods for heavily used templates, and publish the dates.

5. Keep a public, permanent record of flagged and delisted templates, with reasons and dates, so nothing is quietly removed or quietly kept. Show download counts for flagged templates separately, so a big number is never the reason a template stays listed.

6. Ask template authors to re-confirm every N months that the runtime is supported. No answer starts the countdown in point 4.

7. Allow an exception when an author can show a maintained backport. ownCloud's own image does this with Freexian (ownCloud). Such a template gets a note instead of a delisting.

Scan: PHP in the 300 most-pulled CA images

Method: the 300 Docker repositories with the most pulls in the CA app feed (applicationFeed.json, updated 2026-10-20), latest tag each, scanned 2026-10-23 for any PHP binary or PHP web module and its version. Pull counts are Docker Hub totals for the repository, not CA installs. Fixed versions are 8.5.12, 8.4.27, 8.3.36 and 8.2.35 (php.net).

• 294 images scanned, 6 could not be pulled

• 31 contain PHP. 27 of them are already patched, including distro backports (Debian 8.2.35-1~deb12u1, Ubuntu 8.3.6-0ubuntu0.24.04.13)

• 4 still ship an unpatched or end-of-life PHP and are listed in CA as active:

1. wallabag (wallabag/wallabag): PHP 8.1.32, image built 2025-10-07. PHP 8.1 is past end of life (php.net)

2. NGINX---PHP-FPM (richarvey/nginx-php-fpm): PHP 8.2.7, image built 2023-06-10. Unpatched

3. Cachet (cachethq/docker): PHP 7.3.14, image built 2020-09-21

4. speedtest-tracker (henrywhitaker3/speedtest-tracker): PHP 7.4.15, image built 2021-05-04

Plus the ownCloud example above (CA page), which falls outside the top 300 by pulls. Two more images on old PHP are already marked Deprecated in CA, which shows the mechanism works when someone uses it: muximux (PHP 7.4.26) and speedtest (adolfintel/speedtest, PHP 7.4.28). Anyone can reproduce a line with docker run --rm --entrypoint php <image> -v.

How Lime Tech implements this is its call. It needs to be an ongoing process, not something checked once in 2018.

 Here's a quick script that can be used to scan all installed docker containers to see if they are vulnerable or not. This will at least let users know they have vulnerable packages installed and make informed decisions on what to do next - be it switching upstream sources, disabling that service or its external exposure, or looking for a maintained alternative.

#!/bin/bash
for c in $(docker ps --format "{{.Names}}"); do
if docker exec "$c" php -v >/dev/null 2>&1; then
echo "Container: $c"

# Grab full version string line 1 (e.g., "PHP 8.2.20 (cli)...")
ver_string=$(docker exec "$c" php -v | head -n 1)
echo " Version: $ver_string"

# Extract major.minor.patch cleanly using awk/sed
clean_ver=$(echo "$ver_string" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -n 1)

if [ -z "$clean_ver" ]; then
echo " Status:  Could not parse exact version number."
else
# Parse version components
major=$(echo "$clean_ver" | cut -d. -f1)
minor=$(echo "$clean_ver" | cut -d. -f2)
patch=$(echo "$clean_ver" | cut -d. -f3)

is_vulnerable=false

# Logic for vulnerability status based on official patch levels
if [ "$major" -lt 8 ] || { [ "$major" -eq 8 ] && [ "$minor" -lt 2 ]; }; then
is_vulnerable=true # EOL versions (< 8.2) are unpatched and vulnerable
elif [ "$major" -eq 8 ] && [ "$minor" -eq 2 ] && [ "$patch" -lt 35 ]; then
is_vulnerable=true
elif [ "$major" -eq 8 ] && [ "$minor" -eq 3 ] && [ "$patch" -lt 36 ]; then
is_vulnerable=true
elif [ "$major" -eq 8 ] && [ "$minor" -eq 4 ] && [ "$patch" -lt 27 ]; then
is_vulnerable=true
elif [ "$major" -eq 8 ] && [ "$minor" -eq 5 ] && [ "$patch" -lt 12 ]; then
is_vulnerable=true
fi

if [ "$is_vulnerable" = true ]; then
echo " Status:  VULNERABLE to CVE-2026-109618 / CVE-2026-109619"
else
echo " Status:  Patched / Not Affected"
fi
fi
echo "-----------------------------------"
fi
done

13 hours ago, Samsonight said:

Example: ownCloud, the only ownCloud server in CA

The PHP security issue has been addressed in the updated image posted today. The larger work is safely modernizing the rest of the stack without breaking existing installations.

ownCloud tightly couples its releases to specific PHP versions. Changing PHP to 8.x in the image would prevent older ownCloud versions that require PHP 7.4 from running. The ownCloud upgrade and PHP change need to be tested together, with users able to choose when to make that major-version move.

MariaDB also needs attention: the image’s MariaDB 10.6 line is now end-of-life. ownCloud’s 10.16 documentation recommends MariaDB, but its Ubuntu 22.04 example is 10.6.12 and it doesn’t name a currently maintained target. Upgrading an existing database requires preparation in ownCloud, a backup, and MariaDB’s upgrade procedure; it isn’t just a package-version change. ownCloud’s database upgrade guide describes those steps.

I’ll plan on the MariaDB upgrade while preserving the current ownCloud/PHP combination, then evaluate the ownCloud/PHP 8 migration separately. I don’t want a container rebuild to force existing users into a major ownCloud upgrade.

Edited October 24Oct 24 by dlandon

Thanks @dlandon on for the quick rebuild. I can confirm it: the dlandon/owncloud:latest image created 2026-10-23 ships php7.4-fpm 1:7.4.33-31, the PPA's fixed build (Launchpad). Anyone can check with docker run --rm --entrypoint dpkg-query dlandon/owncloud -W php7.4-fpm. Doing MariaDB first and then evaluating ownCloud/PHP 8 separately, without forcing anyone into a major ownCloud upgrade, sounds sensible to me. I'll also post a fix for the built-in updater's 504 in the support thread.

A note on @Xaero's script: php -v can't tell a patched distro build from an unpatched one. As ownCloud puts it: "php -v reports 8.3.6 or 7.4.33 before and after the fix. Only the package version tells you whether you have the fix." (ownCloud). On Debian or Ubuntu based images, check the package instead, for example docker exec <container> dpkg-query -W 'php*-fpm' 'libapache2-mod-php*', and on Alpine docker exec <container> apk info -v | grep php. Fixed builds are listed per distro by Ubuntu and per upstream version by php.net.

The same pattern beyond PHP

I ran a second pass over the same 300 images as in the first post for end-of-life base systems and runtimes: Debian, Ubuntu, Alpine, CentOS, Python, Node.js, Java, .NET and OpenSSL 1.x. Each was checked against the dates on endoflife.date. 293 images were scanned, and 45 contain at least one end-of-life component (counting Python 3.10, which ended 2026-10-01). An old library inside an image is not automatically exploitable, so these are the most typical cases, not an exploit list. Build dates are the image's own Created field. Each finding can be checked with docker run --rm --entrypoint cat <image> /etc/os-release.

1. Rebuilt in 2026, but on an end-of-life base or runtime (the ownCloud pattern):

• UptimeKuma (louislam/uptime-kuma:latest, built 2026-09-16, Docker Hub): Debian 10, EOL 2024-06-30 (endoflife.date). Node.js 18, EOL 2025-04-30 (endoflife.date). OpenSSL 1.1

• Docker-Github-Actions-Runner (myoung34/github-runner:latest, built 2026-10-23, Docker Hub): Ubuntu 20.04, standard support ended 2025-05-31 (endoflife.date). Node.js 20, EOL 2026-04-30. Python 3.8, EOL 2024-10-07 (endoflife.date)

• omada-controller (mbentley/omada-controller:latest, built 2026-08-31, Docker Hub): Ubuntu 20.04 (endoflife.date). OpenSSL 1.1

• Odoo17 (odoo:17, built 2026-09-09, Docker Hub): bundles Node.js 12, EOL 2022-04-30 (endoflife.date)

• Alpine 3.18, EOL 2025-05-09, and Alpine 3.20, EOL 2026-04-01 (endoflife.date), in images rebuilt in September and October 2026: autoheal (3.18), tvheadend and htpcmanager (linuxserver), HandBrake and FileBot (jlesage)

2. Templates pinned to an old tag, frozen for good:

• Postgres12.5 (postgres:12.5-alpine, built 2021-01-29, Docker Hub): PostgreSQL 12, EOL 2024-11-21 (endoflife.date). Alpine 3.13, EOL 2022-11-01

• GrafanaLoki (grafana/loki:master, built 2021-11-04, Docker Hub): Alpine 3.13

• elasticsearch (elasticsearch:6.6.2, built 2019-03-06): Elasticsearch 6, EOL 2022-02-10 (endoflife.date), on CentOS 7. kibana (kibana:7.12.0, built 2021-03-18): CentOS 8, Node.js 14. ElasticSearch-5 (elastic/elasticsearch:5.6.14, built 2018-12-11)

• seafile-10 (seafileltd/seafile-mc:10.0-latest): Ubuntu 20.04, Python 3.8. DockerRegistry (registry:2): Alpine 3.18

3. Images nobody has rebuilt in years, still listed:

• httpbin (built 2018-10-24): Ubuntu 18.04, Python 3.6

• UniFi-Video (built 2020-08-13): Ubuntu 18.04, Python 3.6, OpenSSL 1.0

• couchpotato (linuxserver, built 2022-03-01): Python 2.7, EOL 2020-01-01 (endoflife.date)

• statping, Varken, Shadowsocks (all built 2020) and coturn, CalibreWeb, hassConfigurator (all built 2021): Alpine 3.12/3.13, EOL 2022 (endoflife.date), OpenSSL 1.1

None of these templates is marked Deprecated in the CA feed today. All three groups pass a "does the image exist and get pulled" check, and none would pass a runtime check.

The ownCloud image was rebuilt within hours of being raised here, which is great. Most of the images above have nobody raising them. That's why the requests in my first post are about a scheduled runtime check, not a rebuild-date check.

10 hours ago, Samsonight said:

Thanks @dlandon on for the quick rebuild. I can confirm it: the dlandon/owncloud:latest image created 2026-10-23 ships php7.4-fpm 1:7.4.33-31, the PPA's fixed build (Launchpad). Anyone can check with docker run --rm --entrypoint dpkg-query dlandon/owncloud -W php7.4-fpm. Doing MariaDB first and then evaluating ownCloud/PHP 8 separately, without forcing anyone into a major ownCloud upgrade, sounds sensible to me. I'll also post a fix for the built-in updater's 504 in the support thread.

A note on @Xaero's script: php -v can't tell a patched distro build from an unpatched one. As ownCloud puts it: "php -v reports 8.3.6 or 7.4.33 before and after the fix. Only the package version tells you whether you have the fix." (ownCloud). On Debian or Ubuntu based images, check the package instead, for example docker exec <container> dpkg-query -W 'php*-fpm' 'libapache2-mod-php*', and on Alpine docker exec <container> apk info -v | grep php. Fixed builds are listed per distro by Ubuntu and per upstream version by php.net.

The same pattern beyond PHP

I ran a second pass over the same 300 images as in the first post for end-of-life base systems and runtimes: Debian, Ubuntu, Alpine, CentOS, Python, Node.js, Java, .NET and OpenSSL 1.x. Each was checked against the dates on endoflife.date. 293 images were scanned, and 45 contain at least one end-of-life component (counting Python 3.10, which ended 2026-10-01). An old library inside an image is not automatically exploitable, so these are the most typical cases, not an exploit list. Build dates are the image's own Created field. Each finding can be checked with docker run --rm --entrypoint cat <image> /etc/os-release.

1. Rebuilt in 2026, but on an end-of-life base or runtime (the ownCloud pattern):

• UptimeKuma (louislam/uptime-kuma:latest, built 2026-09-16, Docker Hub): Debian 10, EOL 2024-06-30 (endoflife.date). Node.js 18, EOL 2025-04-30 (endoflife.date). OpenSSL 1.1

• Docker-Github-Actions-Runner (myoung34/github-runner:latest, built 2026-10-23, Docker Hub): Ubuntu 20.04, standard support ended 2025-05-31 (endoflife.date). Node.js 20, EOL 2026-04-30. Python 3.8, EOL 2024-10-07 (endoflife.date)

• omada-controller (mbentley/omada-controller:latest, built 2026-08-31, Docker Hub): Ubuntu 20.04 (endoflife.date). OpenSSL 1.1

• Odoo17 (odoo:17, built 2026-09-09, Docker Hub): bundles Node.js 12, EOL 2022-04-30 (endoflife.date)

• Alpine 3.18, EOL 2025-05-09, and Alpine 3.20, EOL 2026-04-01 (endoflife.date), in images rebuilt in September and October 2026: autoheal (3.18), tvheadend and htpcmanager (linuxserver), HandBrake and FileBot (jlesage)

2. Templates pinned to an old tag, frozen for good:

• Postgres12.5 (postgres:12.5-alpine, built 2021-01-29, Docker Hub): PostgreSQL 12, EOL 2024-11-21 (endoflife.date). Alpine 3.13, EOL 2022-11-01

• GrafanaLoki (grafana/loki:master, built 2021-11-04, Docker Hub): Alpine 3.13

• elasticsearch (elasticsearch:6.6.2, built 2019-03-06): Elasticsearch 6, EOL 2022-02-10 (endoflife.date), on CentOS 7. kibana (kibana:7.12.0, built 2021-03-18): CentOS 8, Node.js 14. ElasticSearch-5 (elastic/elasticsearch:5.6.14, built 2018-12-11)

• seafile-10 (seafileltd/seafile-mc:10.0-latest): Ubuntu 20.04, Python 3.8. DockerRegistry (registry:2): Alpine 3.18

3. Images nobody has rebuilt in years, still listed:

• httpbin (built 2018-10-24): Ubuntu 18.04, Python 3.6

• UniFi-Video (built 2020-08-13): Ubuntu 18.04, Python 3.6, OpenSSL 1.0

• couchpotato (linuxserver, built 2022-03-01): Python 2.7, EOL 2020-01-01 (endoflife.date)

• statping, Varken, Shadowsocks (all built 2020) and coturn, CalibreWeb, hassConfigurator (all built 2021): Alpine 3.12/3.13, EOL 2022 (endoflife.date), OpenSSL 1.1

None of these templates is marked Deprecated in the CA feed today. All three groups pass a "does the image exist and get pulled" check, and none would pass a runtime check.

The ownCloud image was rebuilt within hours of being raised here, which is great. Most of the images above have nobody raising them. That's why the requests in my first post are about a scheduled runtime check, not a rebuild-date check.

Good callout. Instead of doing this for a single vulnerability/image/package -- I went ahead and vibe coded a plugin using claude that employs Trivy to scan for all CVEs in your docker environment, per-package-per-image-per-container. The numbers get quite alarming, but it does give good visibility to the landscape. I also added pagination and collapsible sections to the report view, a dashboard card, and rudimentary progress output. There's also the ability to toggle off CVEs which have no fix available to help filter out noise. This obviously doesn't address the concern you've raised about "who is managing these potential threat vectors" but it does provide an easy way for users to see what they are exposed to and make intelligent decisions based on that information.

I've attached it here and can provide source if there's interest. I don't have bandwidth to maintain something like this due to my day-to-day obligations.

trivy-scan.plg

On 10/24/2026 at 9:56 PM, Xaero said:

The numbers get quite alarming, but it does give good visibility to the landscape.

I've attached it here and can provide source if there's interest. I don't have bandwidth to maintain something like this due to my day-to-day obligations.

trivy-scan.plg

Ran it and regret doing so❤️ , one could loose (principal) sleep over this, here is a good example of when apps should be approved / frozen to the ca community repo... (correlated with Grype)

https://ca.unraid.net/apps/virtual-dsm-06xvzjd1or2zn9

• Put mildly, a scan of virtual-dsm lights up like New Year's Eve. I doubt there's a single up-to-date piece in it: Trivy finds 138 CVEs that already have a fix, plus another 328 with no fix yet.

• And that's only the container. On first start it downloads Synology's DSM and runs it in a VM, and no image scanner can see inside that. Synology patches DSM without bumping version numbers, and its release notes mostly just say "Fixed security

  vulnerabilities" without naming a single CVE.

• So I unpacked the DSM it installs and looked for myself. By default that's still 7.2.2 from 2024. It ships PHP 8.1.9 compiled in December 2022 and Python 3.8.15, which is end-of-life, compiled in November 2022. Whatever Synology backports, those

  binaries are two years older than the fixes.

• Underneath it all, Synology keeps its own fork of the Linux 4.4 kernel, a branch upstream stopped supporting in 2022. Matching DSM's component versions against the CVE database gives about 4,190 unique CVEs, 3,766 of them in the kernel. Plenty of

  that is noise: about 600 are for GPU, Wi-Fi and Bluetooth drivers the VM doesn't even ship, and a few are for io_uring, a feature that only appeared in Linux 5.1. But sorting the real ones from the noise has to be done by hand, one CVE at a time.

• What you can do today:

  • Set URL to the DSM 7.4.1 installer (https://global.synologydownload.com/download/DSM/release/7.4.1/90080/DSM_VirtualDSM_90080.pat) before the first start. It installs and boots fine, and comes with PHP 8.1.32 and OpenSSL 3.0.19, all built in

    2025–2026. That cuts the critical non-kernel matches from 31 to 22. Same 4.4 kernel though.

  • If you're already installed, run DSM's own updater. The base 7.2.2 is exposed to Synology's own SA-26:13 (remote, CVSS 9.8) until Update 9.

On the container side, an upstream PR (#1406) is pending that drops the fixable CVEs from 132 to 47 with one line.

Edited October 27Oct 27 by Samsonight
clarification

On 10/25/2026 at 5:56 AM, Xaero said:

Good callout. Instead of doing this for a single vulnerability/image/package -- I went ahead and vibe coded a plugin using claude that employs Trivy to scan for all CVEs in your docker environment, per-package-per-image-per-container. The numbers get quite alarming, but it does give good visibility to the landscape. I also added pagination and collapsible sections to the report view, a dashboard card, and rudimentary progress output. There's also the ability to toggle off CVEs which have no fix available to help filter out noise. This obviously doesn't address the concern you've raised about "who is managing these potential threat vectors" but it does provide an easy way for users to see what they are exposed to and make intelligent decisions based on that information.

I've attached it here and can provide source if there's interest. I don't have bandwidth to maintain something like this due to my day-to-day obligations.

trivy-scan.plg

Ha! this is great, i got claude to integrate trivy on my nixos server master and scanned my two prod unraid hosts which lit up! I'm just getting it to review the security issues log above to see how to log them all individually :-) I might look to see if in my hybrid env with nixos and unraid if it makes sense to deploy your plugin - assuming you'll keep it alive. I like stuff i can 'see' (in the unraid UI) than stuff claude as scripted behind the scenes

One thing I didn't do was employ a way to scan the base Unraid OS. That should also be possible to integrate and would let you know what's outstanding from the OS perspective. One thing that's important to understand though - even a critical CVE doesn't mean that you need to start panicking. There's a lot of clickbait content around this stuff right now and it's unfortunate. They are critical for a reason yes - but severity is mostly based on how much damage could be done and not how easy or widespread this is. That's a very important distinction. The attack surface also has to be exposed in order for the CVE to actually mean anything. Should you want it patched? yes. Should you look to keep it up to date and mitigate as much as possible? yes. Should you panic because there's a CVSS 9.2 vulnerability on your system? Maybe. Is the attack vector to exploit it exposed? Can you remove that exposure?

Still, it's good to have visibility to the landscape of what is out there, what you are exposed to and what risks you might be taking. I'll probably update the plugin to scan unraid as well and put it up on github. I don't plan on super actively maintaining it but if there interest is there, I see no reason not to. perhaps it could even be on CA. AI tools make maintaining something like this trivial compared to what it would have been before.

4 hours ago, Xaero said:

I'll probably update the plugin to scan unraid as well and put it up on github. I don't plan on super actively maintaining it but if there interest is there, I see no reason not to. perhaps it could even be on CA.

Thanks for sharing this! I like this a lot and would love to see it extended to the os and available via CA.

16 hours ago, Jorgen said:

Thanks for sharing this! I like this a lot and would love to see it extended to the os and available via CA.

@Xaero I took your plugin as the base and put it up here: https://github.com/luuvasara/unraid-trivy-scan

Install (Plugins, Install Plugin):

https://raw.githubusercontent.com/luuvasara/unraid-trivy-scan/main/unraid-trivy-scan.plg

don't trust random repos ❤️(which is funny as forking and pull requests do exactly that 😉)

Changes vs. your original:

- Trivy pinned by version and digest instead of :latest

- the container holding the Docker socket has no network; registry logins only go to a separate container without the socket

- settings are read as data and validated (the original sourced the cfg as shell)

- no scan at install/boot; Stop only removes the plugin's own containers

- images scanned by ID; failed images listed with the reason; each CVE counted once

New: Unraid OS scan (trivy rootfs, no network, only /usr /lib /lib64 /bin /sbin mounted read-only). It covers Go binaries (docker, containerd, rclone) and Node packages incl. the Unraid API, plus whatever plugins drop under /usr. Stock 7.3.4 release files: 227 CVEs. My live 7.3.4 box with a few plugins: 368 (13 critical, nearly all with a fix upstream), mostly rclone, the Docker/containerd binaries, and plugin binaries like ctop and unbalanced. Limitation: Trivy has no Slackware support, so the ~400 OS packages and the kernel are only listed, not CVE-matched.

Unraid 8 won't fix that by itself. The [announced](https://unraid.net/blog/unraid-8-announced) move to uCore means a Fedora CoreOS base, and Trivy supports Fedora CoreOS for SBOM only, not vulnerabilities ([docs](https://github.com/aquasecurity/trivy/blob/v0.76.1/docs/guide/coverage/os/coreos.md)). The "Support Fedora" request, [trivy#121](https://github.com/aquasecurity/trivy/issues/121), has been open since 2019 because Fedora has no machine-readable advisory feed. So the base OS stays the blind spot, and Lime Tech's own patch cadence is what covers it.

Tested on live 7.3.4 server, feedback welcome. I'd rather merge efforts than split: PRs either way or co-maintain, your call on CA. Mainly I do not have all that much time to devote towards this but at least its moving. Your original had no licence; mine is GPL-2.0 for now, so tell me if you'd prefer something else.

One small correction: the CVSS base score does include exploitability (attack vector, complexity, privileges, user interaction). What it doesn't measure is how likely exploitation is; that's EPSS and the CISA KEV list.

Edited October 31Oct 31 by Samsonight
clarification

22 hours ago, Samsonight said:

@Xaero I took your plugin as the base and put it up here: https://github.com/luuvasara/unraid-trivy-scan

Install (Plugins, Install Plugin):

https://raw.githubusercontent.com/luuvasara/unraid-trivy-scan/main/unraid-trivy-scan.plg

don't trust random repos ❤️(which is funny as forking and pull requests do exactly that 😉)

Changes vs. your original:

- Trivy pinned by version and digest instead of :latest

- the container holding the Docker socket has no network; registry logins only go to a separate container without the socket

- settings are read as data and validated (the original sourced the cfg as shell)

- no scan at install/boot; Stop only removes the plugin's own containers

- images scanned by ID; failed images listed with the reason; each CVE counted once

New: Unraid OS scan (trivy rootfs, no network, only /usr /lib /lib64 /bin /sbin mounted read-only). It covers Go binaries (docker, containerd, rclone) and Node packages incl. the Unraid API, plus whatever plugins drop under /usr. Stock 7.3.4 release files: 227 CVEs. My live 7.3.4 box with a few plugins: 368 (13 critical, nearly all with a fix upstream), mostly rclone, the Docker/containerd binaries, and plugin binaries like ctop and unbalanced. Limitation: Trivy has no Slackware support, so the ~400 OS packages and the kernel are only listed, not CVE-matched.

Unraid 8 won't fix that by itself. The [announced](https://unraid.net/blog/unraid-8-announced) move to uCore means a Fedora CoreOS base, and Trivy supports Fedora CoreOS for SBOM only, not vulnerabilities ([docs](https://github.com/aquasecurity/trivy/blob/v0.76.1/docs/guide/coverage/os/coreos.md)). The "Support Fedora" request, [trivy#121](https://github.com/aquasecurity/trivy/issues/121), has been open since 2019 because Fedora has no machine-readable advisory feed. So the base OS stays the blind spot, and Lime Tech's own patch cadence is what covers it.

Tested on live 7.3.4 server, feedback welcome. I'd rather merge efforts than split: PRs either way or co-maintain, your call on CA. Mainly I do not have all that much time to devote towards this but at least its moving. Your original had no licence; mine is GPL-2.0 for now, so tell me if you'd prefer something else.

One small correction: the CVSS base score does include exploitability (attack vector, complexity, privileges, user interaction). What it doesn't measure is how likely exploitation is; that's EPSS and the CISA KEV list.

plugin: installing: unraid-trivy-scan.plg

Executing hook script: pre_plugin_checks

plugin: downloading: unraid-trivy-scan.plg ... done

Executing hook script: pre_plugin_checks

plugin: run failed: '/bin/bash' returned 1

Executing hook script: post_plugin_checks

Edited November 1Nov 1 by Niklas

Thanks for the report @Niklas . Classic "works on my computers": every one of mine had already had the plugin, so none of them hit it. On a true first install the pre-install step exited with code 1 because no earlier package was on the flash, and Unraid aborted.

Fixed in 2026.11.01, please run the install again from the same URL.

33 minutes ago, Niklas said:

plugin: installing: unraid-trivy-scan.plg

Executing hook script: pre_plugin_checks

plugin: downloading: unraid-trivy-scan.plg ... done

Executing hook script: pre_plugin_checks

plugin: run failed: '/bin/bash' returned 1

Executing hook script: post_plugin_checks

12 minutes ago, Samsonight said:

Thanks for the report @Niklas . Classic "works on my computers": every one of mine had already had the plugin, so none of them hit it. On a true first install the pre-install step exited with code 1 because no earlier package was on the flash, and Unraid aborted.

Fixed in 2026.11.01, please run the install again from the same URL.

Thanks. Install worked but pressing "Scan now" I get this:

@Niklas thanks for the screenshot. That's a second bug, also on my side: the Scan now / Stop / Update DB buttons re-checked the CSRF token after Unraid had already checked it and removed it from the request, so they always refused. My tests ran without Unraid's request handler, so they never saw it. Fixed in 2026.11.01c (Plugins, Check for updates), then Scan now again. Scheduled scans were not affected.

Please mind Github cache expiration delays, in minutes. You can use the direct url https://raw.githubusercontent.com/luuvasara/unraid-trivy-scan/main/unraid-trivy-scan.plg on the Install Plugin page to override it (it will install whichever version is actually in the repo).

35 minutes ago, Niklas said:

Thanks. Install worked but pressing "Scan now" I get this:

Edited November 1Nov 1 by Samsonight
version

16 minutes ago, Samsonight said:

@Niklas thanks for the screenshot. That's a second bug, also on my side: the Scan now / Stop / Update DB buttons re-checked the CSRF token after Unraid had already checked it and removed it from the request, so they always refused. My tests ran without Unraid's request handler, so they never saw it. Fixed in 2026.11.01c (Plugins, Check for updates), then Scan now again. Scheduled scans were not affected.

Please mind Github cache expiration delays, in minutes. You can use the direct url https://raw.githubusercontent.com/luuvasara/unraid-trivy-scan/main/unraid-trivy-scan.plg on the Install Plugin page to override it (it will install whichever version is actually in the repo).

c works. Btw, the header tab shows as "TRIVYSCANTAB".

Thanks @Samsonight plugin works great!

I know not all of this is actually a problem for a LAN only server, but the results are still a bit unnerving...

On 11/1/2026 at 9:21 AM, Samsonight said:

@Niklas thanks for the screenshot. That's a second bug, also on my side: the Scan now / Stop / Update DB buttons re-checked the CSRF token after Unraid had already checked it and removed it from the request, so they always refused. My tests ran without Unraid's request handler, so they never saw it. Fixed in 2026.11.01c (Plugins, Check for updates), then Scan now again. Scheduled scans were not affected.

Please mind Github cache expiration delays, in minutes. You can use the direct url https://raw.githubusercontent.com/luuvasara/unraid-trivy-scan/main/unraid-trivy-scan.plg on the Install Plugin page to override it (it will install whichever version is actually in the repo).

I submitted a few PRs. Adding support for Grype to scan the OS packages both for Slackware and the eventual switch to a Fedora base. Including updates to the help text. A fix for the potential to go OOM with a large number of containers/packages when compiling the report. A little bit of layout adjustment for the OS package reporting to fit well, and fixing the above note about it being called "TrivyScanTab" when it now scans all vulnerabilities.

8 hours ago, Jorgen said:

I know not all of this is actually a problem for a LAN only server, but the results are still a bit unnerving...

Yeah, it definitely opens your eyes up the the current landscape on Docker. With how many services use docker I'm kind of shocked by the results, too.

14 hours ago, Xaero said:

I submitted a few PRs. Adding support for Grype to scan the OS packages both for Slackware and the eventual switch to a Fedora base. Including updates to the help text. A fix for the potential to go OOM with a large number of containers/packages when compiling the report. A little bit of layout adjustment for the OS package reporting to fit well, and fixing the above note about it being called "TrivyScanTab" when it now scans all vulnerabilities.

Four releases: 2026.11.03 with @Xaero 's work, 2026.11.04, which renames the plugin to CVE Lens for Unraid, and 2026.11.04a with new features.

2026.11.04b: CVE Lens now runs on Unraid 6.12 (6.12.0 or later). On 6.12 the OS scan failed before, because Docker older than version 25 doesn't know the mount option it used; that is fixed, and the dashboard tile now matches the stock tiles on 6.12, 7.0 and 7.1. Older releases (6.9 to 6.11) are not supported: their dashboard has no API for plugin tiles, and they are not tested.

Update through Plugins, check for updates (an older install goes straight to 2026.11.04b).

A new install uses:

https://raw.githubusercontent.com/luuvasara/unraid-cve-lens/main/unraid-cve-lens.plg

The rename. The plugin now checks more than Trivy's output (the OS packages are matched with Grype, see below), so the name changed. The repository moved with it: https://github.com/luuvasara/unraid-cve-lens. The old addresses keep working.

Updating the Trivy Scan entry installs CVE Lens and moves everything over by itself:

- settings, schedule and os-ignore.txt are copied;

- the data folder (databases and the last report) is moved, so nothing is downloaded again;

- the old log is added to the new one, older notifications open the new page, and the dashboard tile keeps its place;

- about a minute later the Trivy Scan entry removes itself, along with its folder on the flash drive.

The header tab is still "Vulnerabilities". The settings page is now Settings, CVE Lens, so a bookmark to /Settings/TrivyScan needs updating.

2026.11.03: Unraid OS packages are now checked for CVEs. Most of this is @Xaero 's work: six pull requests, all merged.

This was the big gap: Trivy has no advisory data for Slackware (or for the Fedora base of Unraid 8), so the ~400 OS packages were only listed. Now the package list is mapped to NVD product names and matched by upstream version with Grype, in a container with no network, no Docker socket and nothing of the host except that list. Settings, Unraid OS: "Match OS packages against NVD" (on) and "Include the kernel" (off).

NVD only knows upstream versions, so a fix that was backported into an Unraid release can still show up. Check a finding against the release notes; os-ignore.txt next to the settings file hides a CVE. NVD entries without a version range (they match every version) and disputed entries are listed as "not counted", with the reason. On the 7.3.4 release files that leaves 73 CVEs out of 160 raw matches. OS package matches never trigger the "new fixable critical" notification.

Also new in 2026.11.03:

- Settings, Databases: per database (Trivy, Java, Grype), keep it on disk between scans or download it for each scan and delete it afterwards, with its size shown. All are kept by default; the Grype database is about a 200 MB download and 3.1 GB on disk.

- Target filter in the report: everything, the Unraid OS, container images, or one image.

Fixes:

- With many images the report step could run out of memory and fail with an empty log line. It now has room for large runs, logs the real error, and keeps the scan results so the report can be rebuilt without scanning again.

- Locally built images (compose, docker build) are no longer sent to the registry check, which could only fail with "authentication required".

- @Niklas the header tab's page is now named Vulnerabilities, so the browser title matches the tab label. A bookmark to /TrivyScanTab needs updating.

Tested in a 7.3.4 and 6.12.15 VM: the update from Trivy Scan through "Check for updates", the update to 2026.11.04b, scans, a reboot, and the pages checked in a browser.

2026.11.04a: new features

- Exploit data: a "Known exploited" badge for CVEs on CISA's KEV list, an EPSS column (the estimated chance of exploitation in the next 30 days), an "Exploited / likely" filter and a count in the summary. A CVE that newly appears on the KEV list and affects a container image triggers a notification. Settings, "Exploit data" turns it off.

- End of life base: images whose base OS release no longer gets fixes are marked, so "no fix" findings there make sense.

- Ignore list: "Ignore..." in an expanded CVE row hides a finding for all images, one image or the OS, with a reason and an optional expiry date. Ignored findings are left out of counts and notifications; when an entry expires, the CVE counts again and notifies once.

- Container risk: a collapsed table with the settings of each container that matter for security (privileged, Docker socket, host network or PID, added capabilities, devices, runs as root, ports on all interfaces, no healthcheck, :latest). Environment values and command lines are never read.

- Export and history: CSV or JSON of the current view or the whole report, the CVEs that are new or gone since the last scan, and a small trend line.

- Progress panel: while a scan runs, each step with its time, the download and then the unpacking of each database with time left, images scanned, and the latest log lines. Afterwards it shows how long each step took.

- View log: one click on the report page, the settings page or the dashboard tile opens Unraid's live log window.

- Which scanner found what: a card each for Trivy, Grype (NVD) and the exploit data, with version, database date, what it covered and what it can't see, plus "Trivy" / "Grype · NVD" tags on every CVE and a "Found by" filter.

On a slower box the first scan takes a while. On a test VM limited to 2 cores, 4 GB and a hard-disk-speed array it took about 40 minutes, most of it unpacking the databases (the Grype one alone about 25 minutes); later scans reuse them. The progress panel shows where it is.

Thanks again @Xaero for the original plugin this grew from. Feedback and PRs welcome as before.

Ping for those who asked for a CVE / vulnerability scanner for Unraid over the years: @L0rdRaiden (the most active forum proponent towards this kind of functionality) @HelixX23 @caplam @nearcatch @Jclendineng @a_n_d_y @nametaken_thisonetoo @pish180.
And a wave to @mstrhakr maintainer of Compose Manager Plus and @primeval_god for the original Docker Compose Manager.

Edited November 4Nov 4 by Samsonight
v6 support

I got my bot to log a https://product.unraid.net/?bucket_id=18101 issue for each package released with Unraid base OS that has one or more CVEs associated with it. I might get my account banned as there was about 60! lol.

I recommend creating a plugin support thread for your plugin work vs working in here.

9 hours ago, johner said:

I got my bot to log a https://product.unraid.net/?bucket_id=18101 issue for each package released with Unraid base OS that has one or more CVEs associated with it. I might get my account banned as there was about 60! lol.

That is the kind of disrespectful behavior that has gotten many projects to just close their reporting system.

Everything has CVEs all the time and most of them are irrelevant to a particular context, it's completely pointless to just list them all.

If you wanted to be actually useful then instead of flooding the report system with the output of a tool they can run themselves you would assess how each of them apply to Unraid's usecase and only report those that are actually relevant and important, there might be one or 2 at most. Just dumping all without assessment only creates noise and unnecessary effort that would be better spent on what actually matters.

Edited November 5Nov 5 by Kilrah