# 🚨 Weekly Self-Hosted Security Summary (October 15 – October 21, 2026) **URL:** \ **Category:** 🚨→Security Advisory→🚨\ **Tags:** self-hosted, cve, weekly-security, security\ **Created:** [October 21, 2026, 3:13pm UTC](https://forum.hhf.technology/t/weekly-self-hosted-security-summary-october-15-october-21-2026/4512 "2026-10-21T15:13:38Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![hhf.technoloy](https://forum.hhf.technology/user_avatar/forum.hhf.technology/hhf.technoloy/32/68_2.png) [@hhf.technoloy](https://forum.hhf.technology/u/hhf.technoloy)\ **Post date:** [October 21, 2026, 3:13pm UTC](https://forum.hhf.technology/t/weekly-self-hosted-security-summary-october-15-october-21-2026/4512/1 "2026-10-21T15:13:38Z")
**Weekly Self-Hosted Security Summary (October 15 – October 21, 2026)** Here’s a roundup of **12 critical/high security issues** disclosed this week affecting popular open-source self-hosted projects, plus **5 earlier advisories for Nginx, Nginx UI, Tinyauth, Podman and n8n** we hadn’t covered yet (see _Missed Earlier_). Patch quickly: PHP has two unauthenticated RCEs, and there’s a public KVM guest-to-host escape. * * * ### **1. PHP Request-Lifecycle Bugs → Unauthenticated Remote Code Execution** **CVE-2026-109618, CVE-2026-109619** | Disclosed: October 21, 2026 **Project** : PHP (affects Nextcloud, Roundcube, WordPress, BookStack, FreshRSS and any PHP-based app) **Technical Details** : Two separate memory-safety bugs. In the first, PHP uses `longjmp()` to bail out on out-of-memory errors, which can leave request memory in an invalid state that request shutdown then reads. Crafted multipart requests (no usable content length, unlimited part headers, empty file fields) can force that OOM while staying inside PHP’s apparent limits. In the second, global error, session and extension state can outlive the request that owns it, so the next request on the same worker uses freed memory (for example through session upload progress). [PHP says](https://www.php.net/) every PHP install that serves web requests is at risk, including PHP-FPM, Apache `mod_php`, php-cgi, FrankenPHP and LiteSpeed. It rates `mod_php` the highest risk, because a demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs. - **Severity** : Critical (CVSS v4.0 9.2, both) - **Affected** : All supported branches before 8.2.35, 8.3.36, 8.4.27, 8.5.12 - **Fixed** : 8.5.12, 8.4.27, 8.3.36, 8.2.35 (released October 21, 2026). PHP 8.1 and older get no official fix: use your distro or LTS vendor’s backport, or upgrade. - **Workaround** : Upgrade. PHP says no config change is a complete fix. In the meantime, set `session.upload_progress.enabled=0`, set `fatal_error_backtraces=0` on 8.5, and restart all workers. Don’t use `RLIMIT_AS`/`RLIMIT_DATA` as a memory cap, because it triggers the vulnerable path. Pull rebuilt app images once upstream ships them. - **Government warning** : The NSA’s cybersecurity account [told organisations on October 21](https://x.com/NSACyber/status/2112903220209098897) to be ready to update PHP for two critical vulnerabilities and, if an immediate update isn’t feasible, to take the system offline until it can be fully mitigated. The NSA said it will follow up with more specific guidance, but none had appeared as of October 21 (20:33 IST), and the two CVEs were not in CISA’s Known Exploited Vulnerabilities catalog at that time. The post doesn’t name CVEs, but it came the same day PHP shipped fixes for these two 9.2-rated bugs. **Reference** : [PHP Security Advisory GHSA-w8hw-w9fx-j79w](https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w) / [GHSA-6wmf-4rv5-p3rp](https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp) ### **2. Linux Kernel “PwnEscape” → KVM Guest-to-Host Escape** **CVE-2026-99999** | Disclosed: October 15, 2026 **Project** : Linux kernel (Proxmox VE, KVM/libvirt, Firecracker hosts) **Technical Details** : Guest-controlled checksum metadata from virtio-net/TUN (`virtio_net_hdr`) can make `skb_checksum_help` rewrite an IPv4 header after the host kernel has already validated it. The researchers turned this into a repeatable host-memory leak and say it leads to a full guest-to-host escape, with part two of the write-up still to come. The upstream fix adds a `csum_start` check before checksum completion. Every kernel since 2.6.27 is in range. - **Severity** : Critical (CVSS 9.3, [kernel.org](http://kernel.org) CNA) - **Affected** : Kernels before the stable fixes below - **Fixed** : 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11, 7.3. Proxmox VE 9: `proxmox-kernel-7.0.14-24-pve` (PSA-2026-00068-1) - **Workaround** : Patch and **reboot the host**. Updating guests does nothing. Check `uname -r` on every node. Proxmox VE 8 kernels are EOL and won’t get a fix, so plan the move to PVE 9. Until then, don’t run untrusted guests on unpatched hosts. **Reference** : [NVD — CVE-2026-99999](https://nvd.nist.gov/vuln/detail/CVE-2026-99999) / [Proxmox forum — fix in 7.0.14-24](https://forum.proxmox.com/threads/cve-2026-99999-or-the-vercel-kvm-zero-day.187089/) ### **3. Frigate Viewer → Root RCE via go2rtc** **GHSA-93xj-hg88-ffg7, GHSA-qjjw-3v66-279f** (no CVE assigned yet) | Disclosed: October 15, 2026 **Project** : Frigate NVR **Technical Details** : Three websocket/WebRTC routes (`/live/mse/api/ws`, `/live/webrtc/api/ws`, `/api/go2rtc/webrtc`) are proxied straight to go2rtc and skip Frigate’s restricted-source filter. The default config treats the built-in `viewer` role as unrestricted, so any logged-in viewer can open a stream with `src=ffmpeg:...` and run commands as root in the container. A second bug lets an admin get the same result because the source denylist blocks `exec:`, `echo:` and `expr:` but not `ffmpeg:`, which go2rtc expands into `exec:`. - **Severity** : Critical (CVSS 9.9 viewer path; 9.1 admin path) - **Affected** : 0.18.0 – 0.18.1 - **Fixed** : 0.18.2 - **Workaround** : Upgrade the image. Until then, remove or disable non-admin accounts and keep Frigate behind VPN/SSO. Don’t expose port 8971 or go2rtc’s 1984 publicly. **Reference** : [Frigate Security Advisory GHSA-93xj-hg88-ffg7](https://github.com/blakeblackshear/frigate/security/advisories/GHSA-93xj-hg88-ffg7) ### **4. eMudhra Intermediate CA Key Compromise → Python Trust Stores (certifi, uv)** **GHSA-6q48-6c7w-9gw2, GHSA-hq85-5cpj-mr62** (no CVE assigned) | Disclosed: October 20, 2026 **Project** : certifi / uv (bundled CA stores used by `requests`, `urllib3`, `pip` and most Python-based self-hosted apps) **Technical Details** : The private keys for 8 eMudhra intermediate certificates (6 TLS, 2 code-signing) were compromised. They chain to roots trusted by all major root programs. eMudhra and Sectigo revoked them on October 18–19, but clients that don’t check revocation or that fail open will still trust certificates issued from them. An on-path attacker with one of those keys can MITM TLS for any hostname. Browsers are already covered (OneCRL/CRLSets). Bundled stores like certifi and uv’s vendored webpki roots aren’t. - **Severity** : Critical (GitHub advisory rating; no CVSS published) - **Affected** : certifi 2019.03.09 to before 2026.10.19; uv before 0.13.4 - **Fixed** : certifi 2026.10.19 (2026.10.18 removed all emSign roots; .19 put the unaffected ones back); uv 0.13.4 - **Workaround** : Update certifi/uv and **rebuild container images** that vendor them (Home Assistant, Paperless-ngx, other Python apps). Also check your distro’s `ca-certificates` updates. **Reference** : [certifi Security Advisory GHSA-6q48-6c7w-9gw2](https://github.com/certifi/python-certifi/security/advisories/GHSA-6q48-6c7w-9gw2) / [Mozilla Security Blog](https://blog.mozilla.org/security/2026/10/20/protecting-firefox-users-following-the-compromise-of-emudhra-intermediate-certificates/) ### **5. Traefik ForwardAuth Identity Leak + Two More v3.7 Fixes (follow-up to last week)** **GHSA-hrpp-p4fc-wwf8, GHSA-p8wx-ph99-xgcr, GHSA-ww7c-q3mv-xx22** (no CVEs assigned yet) | Disclosed: October 16 & 21, 2026 **Project** : Traefik **Technical Details** : ForwardAuth sends its auth subrequests through a connection pool shared by all clients. If the auth server uses a connection-bound scheme (NTLM or Kerberos “Negotiate”, e.g. IIS Windows Auth), an unauthenticated client can reuse a connection a different user already authenticated. It then gets that user’s identity forwarded to the backend via `authResponseHeaders`. In v3.7 the same applies to Ingress-NGINX `auth-url`. Separately, Ingress-NGINX `auth-tls-secret` mTLS is silently turned off for a host when another Ingress on the same host lacks the same annotation. That’s a new variant of last week’s mTLS issue. Experimental FastProxy can also be crashed remotely after WebSocket upgrades. - **Severity** : High (all three) - **Affected** : ForwardAuth: v2 ≤ v2.11.59 and v3.0.0 – v3.7.15. mTLS: v3.7.0 – v3.7.14. FastProxy: v3.2.0 – v3.7.14 (only with `experimental.fastProxy`) - **Fixed** : v3.7.16 (covers all three) / v2.11.60. v3.0–v3.6 are EOL and won’t be patched. - **Workaround** : Upgrade to v3.7.16. Last week’s v3.7.11 target isn’t enough anymore. Enable `core.strictTLSOptions` so TLS option conflicts fail closed, and turn off `experimental.fastProxy` if you don’t need it. **Reference** : [Traefik Security Advisory GHSA-hrpp-p4fc-wwf8](https://github.com/traefik/traefik/security/advisories/GHSA-hrpp-p4fc-wwf8) ### **6. ZITADEL Login V2 → One-Click Account Takeover** **GHSA-qj3q-235g-qr6w, GHSA-mchc-246r-6m76, GHSA-84fg-x5h4-w8xv** (no CVEs assigned yet) | Disclosed: October 15, 2026 **Project** : ZITADEL **Technical Details** : Three account-takeover paths in the hosted Login V2 UI: - A signed-in user who opens one attacker link approves the attacker’s Device Code request without entering the code or seeing a consent screen. The attacker then gets the user’s tokens, and the API path also skipped project access settings. - Password-reset, invite and verification emails were built from client-supplied host headers (`x-zitadel-public-host`, `x-zitadel-forward-host`, `x-forwarded-host`), so real single-use codes could be sent to an attacker’s domain. - The `verificationCheck` cookie had no server secret, so anyone could forge it and set the first credential on users who don’t have one yet. - **Severity** : High (CVSS 8.1 / 8.1 / 7.4) - **Affected** : 4.0.0 – 4.19.4 (Device Code issue also 3.0.0 – 3.4.15) - **Fixed** : 4.19.5. 3.x is EOL and won’t get a fix. - **Workaround** : Upgrade. If you don’t use Device Authorization, remove the Device Code grant from all apps. Have your reverse proxy strip `x-zitadel-public-host`/`x-zitadel-forward-host` and set `X-Forwarded-Host` itself. **Reference** : [ZITADEL Security Advisory GHSA-qj3q-235g-qr6w](https://github.com/zitadel/zitadel/security/advisories/GHSA-qj3q-235g-qr6w) ### **7. Gitea OpenID Linking → Account Takeover (plus 10 more fixes)** **CVE-2026-104627** | Disclosed: October 18, 2026 **Project** : Gitea **Technical Details** : Gitea accepted an OpenID 2.0 assertion at the security-settings callback without checking that the current session started a linking flow. Because OpenID 2.0 allows unsolicited assertions, an attacker running their own provider can get their identity linked to a signed-in victim with one click. They can then log in as the victim through OpenID, skipping local TOTP/WebAuthn. Fresh installs enable OpenID sign-in by default. The same release fixes **CVE-2026-109553** (High, 7.5): SSH certificate principals can map onto other users’ keys when a trusted user CA is configured. It also fixes ten medium/low issues, including private-repo metadata leaks and an Actions artifact memory-exhaustion DoS. - **Severity** : High (CVSS 8.1) - **Affected** : 28.1.0 and earlier - **Fixed** : 28.2.0 - **Workaround** : Disable OpenID sign-in and registration (`[openid]` `ENABLE_OPENID_SIGNIN = false`, `ENABLE_OPENID_SIGNUP = false`) until upgraded, and review linked OpenID identities on admin accounts. **Reference** : [Gitea Security Advisory GHSA-mf69-7pqq-86vx](https://github.com/go-gitea/gitea/security/advisories/GHSA-mf69-7pqq-86vx) ### **8. Immich Album Editor → Owner Escalation; Unauthenticated ML Service Path Injection** **CVE-2026-77439** | Disclosed: October 19, 2026 **Project** : Immich **Technical Details** : `PATCH /api/albums/:id/user/:userId` checks only the share permission an Editor already has, and never blocks `role: owner`. Editors can promote themselves to Owner and remove the other owners, taking over the whole album. In a separate advisory, the machine-learning service has no authentication, listens on all interfaces (`3003`), and passes a request-supplied `cache_dir` to the model loader. Anyone who can reach that port can write to a chosen directory or recursively delete one. - **Severity** : High (CVSS 8.8); ML service issue rated Medium (6.5) by the project - **Affected** : Album issue: 3.0.0 and earlier. ML issue: 3.0.3 and earlier - **Fixed** : Album issue v3.0.3; ML issue v3.3.0 (current release is v3.3.4) - **Workaround** : Upgrade to the latest 3.3.x. Never publish `3003:3003`, and keep `immich-machine-learning` on an internal Docker network only. **Reference** : [Immich Security Advisory GHSA-c9mf-h82r-8p4j](https://github.com/immich-app/immich/security/advisories/GHSA-c9mf-h82r-8p4j) / [GHSA-72rm-x7xr-v679](https://github.com/immich-app/immich/security/advisories/GHSA-72rm-x7xr-v679) ### **9. Roundcube IMAP Command Injection + 19 Other Fixes** **CVE-2026-113386** | Disclosed: October 19, 2026 **Project** : Roundcube Webmail **Technical Details** : CRLF in the `_uid` parameter of `mail/headers` and `mail/viewsource` (and in `_flag` of `mail/mark`) is injected into IMAP commands, letting a logged-in user run arbitrary IMAP commands. The same release fixes a lot of other problems: - mail-header injection in several actions - an object-injection primitive in `rcube_session::unserialize()` - an SSRF filter bypass via NAT64 (`64:ff9b::/96`) - remote-content-blocking bypasses - unsafe attachments passed to ImageMagick - a CSRF bypass on mark-as-junk - a Modoboa password driver bug that changed other accounts’ passwords - **Severity** : High (CVSS 7.1) - **Affected** : Before 1.6.20 and 1.7.x before 1.7.5 - **Fixed** : 1.6.20 (LTS), 1.7.5 - **Workaround** : Upgrade. Roundcube runs on PHP, so apply item #1 at the same time. **Reference** : [Roundcube Security Updates 1.6.20 and 1.7.5](https://roundcube.net/news/2026/10/19/security-updates-1.6.20-and-1.7.5) ### **10. Apache Tomcat JNDI Realm Auth Bypass and Cross-User Response Mix-ups** **CVE-2026-101296, CVE-2026-101356, CVE-2026-103119** | Disclosed: October 20, 2026 **Project** : Apache Tomcat (under Guacamole’s web app, Jenkins/Java app containers and more) **Technical Details** : With the JNDI realm set to a non-GSSAPI SASL mechanism, users could log in without the right password. Separately, object recycling in HTTP/2 async servlets can mix up requests and responses between users. A large non-blocking write can also split a response body into the next request on the same connection, which can leak data to another user. - **Severity** : Critical (CVE-2026-101296 rated critical, no CVSS yet; CVE-2026-101356 and CVE-2026-103119 CVSS 9.1) - **Affected** : Auth bypass: 11.0.0-M1 – 11.0.26, 10.1.0-M1 – 10.1.60, 9.0.0.M1 – 9.0.122 (EOL 8.5/7.0 also). HTTP/2 mix-up: 11.0.22 – 11.0.26, 10.1.55 – 10.1.60, 9.0.118 – 9.0.122. Response split: 11.0.0-M25 – 11.0.26 - **Fixed** : 11.0.27, 10.1.61, 9.0.123 - **Workaround** : Upgrade, or rebuild images on a fixed Tomcat base. If you use JNDI realm with SASL, switch to GSSAPI or simple bind until patched. **Reference** : [Apache Tomcat 11 Security Advisories](https://tomcat.apache.org/security-11.html) / [NVD — CVE-2026-101296](https://nvd.nist.gov/vuln/detail/CVE-2026-101296) ### **11. Homepage Auth Gate Bypass via Next.js Revalidation Header** **GHSA-qxcr-4rv3-v23r** (no CVE assigned yet) | Disclosed: October 17, 2026 **Project** : Homepage (gethomepage) **Technical Details** : With built-in auth on (`HOMEPAGE_AUTH_ENABLED=true`), Next.js skips middleware entirely for “on-demand revalidation” requests that carry a header matching the build’s preview key. That key is the same for everyone running the same official image tag. Unauthenticated attackers can view the dashboard, `/api/services` and `/api/bookmarks`, and Kubernetes status. They can also use the widget proxy to make Homepage call your backends and return the responses. It also bypasses `HOMEPAGE_ALLOWED_HOSTS`. - **Severity** : High (CVSS 7.5) - **Affected** : 2.0.0 – 2.5.0 - **Fixed** : 2.6.0 - **Workaround** : Have your reverse proxy strip or reject the `x-prerender-revalidate` header, and don’t rely on Homepage’s own auth for public exposure. Put it behind Pangolin/SSO. **Reference** : [Homepage Security Advisory GHSA-qxcr-4rv3-v23r](https://github.com/gethomepage/homepage/security/advisories/GHSA-qxcr-4rv3-v23r) ### **12. Pi-hole `pihole` User → Root (Four Local Privilege Escalations)** **GHSA-cf36-4hhc-8398, GHSA-xch2-4qxw-g5vj, GHSA-j8vh-6fp9-cjcx, GHSA-mff6-cjc4-5wq9** (no CVEs assigned yet) | Disclosed: October 17, 2026 **Project** : Pi-hole **Technical Details** : Four ways to go from the `pihole` service user to root: - The fix for CVE-2026-41489 only rejects PID values that start with a non-digit. A PID file like `1+a[$(cmd)]` then runs through bash arithmetic as root on the next root-run `pihole` command. - The root `updatechecker` cron runs `truncate`/`chmod` on `/etc/pihole/versions`, following symlinks. This was introduced in 6.4.2. - `pihole-FTL` keeps an ambient `CAP_CHOWN`. - `gravity.sh` chowns a config-controlled path. These need code execution as `pihole` first, but they turn any web/FTL bug into full root. - **Severity** : High (CVSS 7.8 / 7.8 / 7.8 / 7.3) - **Affected** : Pi-hole core 6.4.3 and earlier (CAP\_CHOWN issue from 5.4) - **Fixed** : Core v6.5; Docker image 2026.10.0 - **Workaround** : Run `pihole -up` or pull `pihole/pihole:2026.10.0`. Make sure the web UI isn’t exposed to the internet. **Reference** : [Pi-hole v6.5 Release Notes](https://github.com/pi-hole/pi-hole/releases/tag/v6.5) * * * ## **Key Takeaways This Week** - **PHP and the kernel come first** : PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 fix two unauthenticated RCEs that affect every PHP app. If you can’t patch a PHP app today, take it offline until you can, as the NSA advises. PwnEscape needs a patched host kernel **and a reboot** (Proxmox VE 9: 7.0.14-24-pve or newer). - **Rebuild your images, not just your apps** : PHP, Tomcat and the certifi/uv CA bundles all live inside container images. Pull fresh upstream tags or rebuild locally. - **“Viewer” and “Editor” roles are real attack surface** : Frigate viewers get root, Immich editors take over albums, and n8n members can reach owner credentials. Audit who has accounts. - **Identity providers are a top target** : ZITADEL and Gitea both had one-click account takeovers, and Traefik ForwardAuth leaked identities across clients. Upgrade the IdP and the proxy in front of it. - **Your reverse proxy should strip headers the app shouldn’t trust** : `x-prerender-revalidate` (Homepage), `x-zitadel-*` / `X-Forwarded-Host` (ZITADEL) and `X-Original-URL` (Tinyauth on Nginx/NPM) are this week’s examples. Your Traefik/Pangolin/Nginx config should set or drop them. - **Update the proxy itself** : nginx 1.30.6 / 1.31.7 fix five worker memory bugs, and Traefik needs v3.7.16. If you use Nginx Proxy Manager or another OpenResty image, check that it has been rebuilt on the fixed nginx. - **Don’t trust what an image or workflow tells your runtime** : Podman before 5.8.8 / 6.1.3 lets an image annotation strip `--cap-drop` and other sandbox flags, and n8n before 2.42.1 / 2.41.4 / 1.123.83 lets unauthenticated webhook calls run other projects’ workflows. Patch both. - **Auth add-ons and admin panels are part of your perimeter** : Tinyauth v5.2.0 closes two forward-auth bypasses, and Nginx UI v2.9.0 closes a run of token-scope escalations. Keep panels like Nginx UI off the internet. **Recommendation** : Review your self-hosted stack this weekend and prioritize upgrades for any of the above projects you’re running. Stay secure! _Questions or need config help? Post in Help ._ * * * _The **Missed Earlier** advisories (Nginx, Nginx UI, Tinyauth, Podman, n8n) are in the first reply below, because the forum limits how long a single post can be._ ---
**Author:** ![hhf.technoloy](https://forum.hhf.technology/user_avatar/forum.hhf.technology/hhf.technoloy/32/68_2.png) [@hhf.technoloy](https://forum.hhf.technology/u/hhf.technoloy)\ **Post date:** [October 21, 2026, 3:13pm UTC](https://forum.hhf.technology/t/weekly-self-hosted-security-summary-october-15-october-21-2026/4512/2 "2026-10-21T15:13:46Z")
## **Missed Earlier** These came out before this week and weren’t in an earlier summary. We’re listing them because they sit right in the reverse-proxy/auth layer, container runtime and automation tools most of you run. ### **13. Nginx 1.30.6 / 1.31.7: Five Worker-Process Memory Bugs (alias + rewrite, variables, HTTP/3, TLS tickets, AIO)** **CVE-2026-15176, CVE-2026-93479, CVE-2026-95101, CVE-2026-97629, CVE-2026-97205** | Disclosed: October 14, 2026 **Project** : nginx (also bundled in OpenResty-based tools such as Nginx Proxy Manager, and in many app images) **Technical Details** : One release fixes five bugs: - A buffer overflow in a worker when `alias` is used and the URI was changed by `rewrite` before being mapped to a file path (CVE-2026-15176). - A buffer overflow while evaluating string expressions with variables, which affects document root calculation and request logging in http and stream (CVE-2026-93479). - With HTTP/3, part of an unknown frame can be treated as the request body, bypassing `client_max_body_size` or injecting data into the proxied request (CVE-2026-95101). - With TLS session ticket key rotation, one key is left uninitialized, which can allow session forgery (CVE-2026-97629). - A use-after-free with AIO when an SSI page uses `include virtual` (CVE-2026-97205). njs 1.0.2 shipped the same day with two XML fixes (CVE-2026-101025, memory exhaustion; CVE-2026-101019, inconsistent attribute values in signed-XML validation). - **Severity** : nginx rates all five Medium. F5’s CVSS: 9.2 (v4.0) / 8.1 (v3.1) for CVE-2026-15176, CVE-2026-93479 and CVE-2026-97205; 8.3 / 6.5 for CVE-2026-97629; 6.9 / 5.3 for CVE-2026-95101 - **Affected** : CVE-2026-15176: 0.1.29 – 1.31.6. CVE-2026-93479: 1.30.0 – 1.30.5 and 1.31.2 – 1.31.6. CVE-2026-95101: 1.25.0 – 1.31.6. CVE-2026-97629: 1.23.2 – 1.31.6. CVE-2026-97205: 0.8.11 – 1.31.6 - **Fixed** : 1.30.6 (stable), 1.31.7 (mainline); njs 1.0.2. Official Docker tags `nginx:1.30.6` and `nginx:1.31.7` are published - **Workaround** : Upgrade and restart. Until then, check for `alias` locations that are also hit by `rewrite`, turn off HTTP/3 (`listen ... quic`) if you don’t need it, and avoid `aio` on SSI locations. If you run Nginx Proxy Manager or another OpenResty-based image, watch for a rebuilt release. NPM’s latest release (v2.16.0, September 24) predates these fixes. If you skipped September’s 1.30.5 / 1.31.6, that update also fixed an HTTP/3 heap overflow (CVE-2026-90439, OpenSSL 3.5.0 and earlier). **Reference** : [nginx security advisories](https://nginx.org/en/security_advisories.html) / [nginx CHANGES](https://nginx.org/en/CHANGES) / [NVD: CVE-2026-15176](https://nvd.nist.gov/vuln/detail/CVE-2026-15176) ### **14. Nginx UI: Service Tokens and Short Tokens Reach Admin Actions (Sept 30 batch)** **GHSA-rg7q-q2cr-372q, GHSA-gp79-j356-rr7m, GHSA-x2x3-p8j2-63mx** (no CVEs assigned), **CVE-2026-107805, CVE-2026-107804** | Disclosed: September 30, 2026 **Project** : Nginx UI (0xJacky/nginx-ui) **Technical Details** : Eight advisories published together. The main ones: - Service tokens with `api:write` scope could create, modify or recover users, which turns an automation token into a persistent admin account (GHSA-rg7q-q2cr-372q). - WebSocket short tokens were accepted on normal management APIs. Standalone short tokens survived logout and could be re-minted with any non-empty `_nginx_ui_secure_session` cookie (GHSA-gp79-j356-rr7m). - The MCP endpoint did its authorization check with a separate JSON parse. Appending trailing data let a read-scoped token or a session without step-up call write tools that change nginx config (GHSA-x2x3-p8j2-63mx). - Read-scoped tokens could pull stored DNS-provider, ACME EAB and S3 credentials (GHSA-pw4f-pq6v-x57r, Medium 6.5). - An unauthenticated client could fill temp storage through the signed-request path (CVE-2026-107805). - Behind the bundled proxy, every request looked like it came from loopback, which bypassed IP allowlists and let one attacker trigger the login ban for everyone (CVE-2026-107804, Medium 5.3). All of these except the two CVE items need a valid token or session first. - **Severity** : High (CVSS 8.8 / 8.8 / 7.1; CVE-2026-107805 7.5) - **Affected** : MCP parser: 2.4.1 – 2.6.1. Service-token user/credential issues: 2.5.3 – 2.6.1. Short tokens: 2.1.10 – 2.6.3. CVE-2026-107805: 2.5.x. CVE-2026-107804: 2.2.0 – 2.5.x - **Fixed** : 2.6.2 (token/MCP/credential issues), 2.6.0 (the two CVEs), 2.7.0 (short tokens). Current release is v2.9.0 (October 17), whose notes also list “harden config file validation and privileged authorization” with no separate advisory - **Workaround** : Upgrade to v2.9.0. Revoke and reissue all service tokens, then rotate any DNS/ACME/S3 credentials stored in Nginx UI. Keep the panel off the internet and put it behind Pangolin/SSO or a VPN. Nginx UI has had several authenticated-RCE advisories this year (July–August: config directive injection, backup restore), so treat any account on it as root-equivalent. **Reference** : [Nginx UI Security Advisories](https://github.com/0xJacky/nginx-ui/security/advisories) / [GHSA-rg7q-q2cr-372q](https://github.com/0xJacky/nginx-ui/security/advisories/GHSA-rg7q-q2cr-372q) / [v2.9.0 release](https://github.com/0xJacky/nginx-ui/releases/tag/v2.9.0) ### **15. Tinyauth Forward-Auth Bypasses (Nginx `X-Original-URL` spoofing, path-rule regex)** **GHSA-vx8c-f5hh-c8pf** (no CVE assigned) | Disclosed: September 7, 2026 **CVE-2026-97736** | Disclosed: July 30, 2026 **Project** : Tinyauth **Technical Details** : Two ways past the login wall: - Tinyauth’s Nginx endpoint `/api/auth/nginx` trusts a client-supplied `X-Original-URL` header to decide which app’s rules apply. An unauthenticated attacker can point it at another app’s public path and get through. A logged-in user can point it at an app they’re allowed to use and reach one they aren’t. This affects Nginx and Nginx Proxy Manager setups that don’t overwrite or drop that header. Traefik ForwardAuth isn’t named in the advisory. - In CVE-2026-97736, `path.allow` / `path.block` rules are unanchored regexes matched against the full URI, including the query string. Putting a public pattern such as `/health` anywhere in the URL bypasses auth on protected paths. This affects all proxies that use those labels. The July 15 batch also fixed CVE-2026-77560 (High 8.1), an authorization bypass via case-sensitive hostname matching. - **Severity** : Critical (CVSS 9.1) for GHSA-vx8c-f5hh-c8pf; High (CVSS 8.1) for CVE-2026-97736 - **Affected** : X-Original-URL: 5.0.5 – 5.1.3. Path rules: 5.1.2 and earlier - **Fixed** : v5.2.0 (September 7) fixes both; it’s the current stable release - **Workaround** : Upgrade to v5.2.0. On Nginx/NPM, add `proxy_set_header X-Original-URL "";` in the location that handles the Tinyauth auth request, and keep sending `X-Forwarded-Host`, `X-Forwarded-Proto` and `X-Forwarded-Uri`. Stop using `path.allow`/`path.block` to exempt endpoints on older versions, and handle public paths in the proxy instead. **Reference** : [Tinyauth Security Advisory GHSA-vx8c-f5hh-c8pf](https://github.com/tinyauthapp/tinyauth/security/advisories/GHSA-vx8c-f5hh-c8pf) / [GHSA-r27r-rr9v-vv37](https://github.com/tinyauthapp/tinyauth/security/advisories/GHSA-r27r-rr9v-vv37) / [v5.2.0 release](https://github.com/tinyauthapp/tinyauth/releases/tag/v5.2.0) ### **16. Podman: Checkpoint Image Annotation Silently Disables Container Sandboxing** **CVE-2026-94603** (GHSA-2cvf-wqm6-wr9g) | Disclosed: October 13, 2026 **Project** : Podman **Technical Details** : Since v4.4.0, `podman run` can restore container checkpoints pulled from an OCI registry. Podman decides an image is a checkpoint purely from the `io.podman.annotations.checkpoint.runtime.name` annotation, and when it sees one it silently ignores the flags you passed, so `--cap-drop=ALL` and similar restrictions are dropped and the image’s own settings (which can include all capabilities) are used instead. Any image you pull can therefore choose how loosely it is sandboxed. The maintainers removed the feature rather than patch it. - **Severity** : Critical (CVSS v3.1 10.0) - **Affected** : Podman 4.4.0 to before 5.8.8, and 6.0.0 to before 6.1.3. Rootless containers are not affected, because they don’t support checkpoint/restore. - **Fixed** : 5.8.8, 6.1.3 - **Workaround** : Upgrade. Until then, scan pulled images for the `io.podman.annotations.checkpoint.runtime.name` annotation and reject any that carry it (Podman can’t do this automatically), and prefer rootless Podman for untrusted images. **Reference** : [Podman Security Advisory GHSA-2cvf-wqm6-wr9g](https://github.com/podman-container-tools/podman/security/advisories/GHSA-2cvf-wqm6-wr9g) / [v5.8.8 release](https://github.com/podman-container-tools/podman/releases/tag/v5.8.8) / [v6.1.3 release](https://github.com/podman-container-tools/podman/releases/tag/v6.1.3) ### **17. n8n: 14 Fixes for SQL Injection, Unauthenticated Webhook Execution, Credential Theft and Stored XSS** **CVE-2026-110840 – CVE-2026-110853** | Disclosed: September 30, 2026 (GitHub advisories); published to NVD October 15, 2026 **Project** : n8n **Technical Details** : A batch of 14 advisories, mostly reachable by any signed-in member and in a few cases by outsiders. The ones to care about: - **Unauthenticated:** CVE-2026-110852: dynamic-path webhook, form and MCP routes matched on the path alone and ignored the unguessable ID, so outsiders could run workflows in other projects with those projects’ credentials. CVE-2026-110840: SQL injection in v1 of the Microsoft SQL node whenever untrusted input (like webhook fields) feeds the Query field. CVE-2026-110843: the OAuth authorize endpoint can be spammed to create unlimited client records until the disk fills. - **Member to owner or credential theft:** CVE-2026-110842: prototype pollution in the MCP workflow-validation tool lets a `workflow:read` member pass permission checks and take over owner accounts without MFA. CVE-2026-110844, 110850 and 110853 let editors use or exfiltrate credentials they shouldn’t be able to see via inline sub-workflows, agent nodes, or a spoofed workflow identity. CVE-2026-110845: the Git node’s Log operation runs programs as the n8n user via a repo’s local git config. - **Session hijack:** CVE-2026-110847 (Chat Trigger `customCss`) and CVE-2026-110849 (file preview) are stored XSS bugs that act with the session of whoever views the page, usually the owner. - **Other:** CVE-2026-110846 (Send-and-Wait signature bypass), CVE-2026-110841 and 110851 (agent access across projects), and CVE-2026-110848 (prototype pollution that knocks the instance over until restart). - **Severity** : High for 10 (CVSS v4.0 7.0 – 8.2), Medium for 4 (6.0 – 6.3), scored by VulnCheck - **Affected** : Varies by CVE. Most affect n8n before 2.41.4 and 2.42.x before 2.42.1, and several also affect 1.x before 1.123.83. - **Fixed** : 1.123.83, 2.41.4, 2.42.1 - **Workaround** : Upgrade. Until then, don’t feed untrusted webhook input into the v1 Microsoft SQL node’s Query field, keep the editor off the public internet, turn on MFA for the owner account, and review who has editor or member access. **Reference** : [n8n Security Advisories](https://github.com/n8n-io/n8n/security/advisories) / [GHSA-4c7j-qff5-r9cx (CVE-2026-110852)](https://github.com/n8n-io/n8n/security/advisories/GHSA-4c7j-qff5-r9cx) / [GHSA-5qpp-pqww-h7fp (CVE-2026-110840)](https://github.com/n8n-io/n8n/security/advisories/GHSA-5qpp-pqww-h7fp) / [n8n@2.42.1 release](https://github.com/n8n-io/n8n/releases/tag/n8n%402.42.1)