Two batches landed inside a month, and neither got the coverage either deserves.

On September 17, a High (7.4): CVE-2026-104190, an ImageMagick RCE reachable by requesting previews of corrupted files. On October 8, five more advisories published in one sitting: three Moderate (6.5) and two Low. Six CVEs total. This site wrote about Nextcloud's Hub release three weeks ago and still missed the September one — it belongs in the same reckoning, because it is the highest score of the six and it pairs with the upload-surface theme covered here before.

The High: your preview pipeline, version-independent to audit

CVE-2026-104190 chains into an RCE in Imagick before 6.9.13-48 and 7.1.2-24 — the attacker gets arbitrary file write, and written files then become ammunition against the rest of the box. The limits are honest and they matter: it only works through preview providers that are not enabled by default — the advisory names Font, HEIC, Illustrator, PDF, Photoshop, Postscript, SGI, TGA, and TIFF — and the attacker needs an account or a writable share link. CVSS puts attack vector as Adjacent (7.4).

That "not default" caveat is exactly why it is this site's pick for the most dangerous of the six. The default-restricted providers are the ones a civic or community instance with a photo archive turns on for convenience — TIFF for the scanned records binder, HEIC because volunteers send iPhone photos, PDF because "the minutes should preview." Nobody flips eight flags by accident, but flipping three of them happens in one support ticket. If any of those strings sit in your enabledPreviewProviders, the preview pipeline is your RCE path until the ImageMagick below it is current.

Three separate workarounds close it, each sufficient by itself:

  • uninstall imagick from PHP;
  • set enable_previews to false;
  • drop the named providers from enabledPreviewProviders.

And a config audit does not depend on any version pin, which is worth saying plainly: Nextcloud's advisory lists community fixes at 32.0.13 / 33.0.7 / 34.0.2 and a long Enterprise tail — but its patched-versions rows stop at 34.x entirely. There is no 35.x row in the advisory at all, even though 35.0.0 had already shipped when it was published. The workarounds, however, are just config: audit them on every version you run.

```console

is the renderer even there?

dpkg -l | grep -i imagemagick # or: rpm -qa | grep -i imagemagick

which providers are actually enabled?

occ config:system:get enabledPreviewProviders ```

If the provider list shows OC\Preview\HEIC, OC\Preview\PDF, OC\Preview\TIFF and siblings, and the system Imagick is older than the fixed releases, you are holding the exposed configuration — even with a fully patched Nextcloud.

A note on honesty in the score: the reporter is Yordan Ganchev of watchTowr, and the chain requires a valid account or writable link, so no anonymous internet edge. It is still the only write-primitive in the batch, and arbitrary file write inside your webroot is how the next bug becomes a full compromise.

Three Moderates that map to how small instances are actually run

The three 6.5s each trace a real workflow on a community server — volunteer write-shares, delegated folder administration, shared photo albums — which is precisely why they are worth more attention than their scores.

CVE-2026-77165 — a write-share collaborator can permanently lock a file the owner cannot unlock (Moderate, availability-High). Anyone holding a write share can place a TYPE_TOKEN lock that the owner has no UI path to remove; the advisory's workaround is remove the file_lock directly in the database. Recovery from a lock is a DB surgery session, not a click. On an instance where shares are handed out like library cards, that is a plain denial-of-service primitive — one volunteer fumbling with file locking and an organizer loses access to everything in a folder until someone with database access intervenes. The advisory's rows: server ≥ 34.0.0 fixed in 34.0.1 (Enterprise 32.0.6 / 33.0.6 / 34.0.1), and the files_lock app lines fixed in 32.0.6 / 33.0.6 — both components carry the bug, both need patching.

CVE-2026-77169 — Team Folders + workspace delegated-admin privilege escalation (Moderate, CVSS 6.5, and read the preconditions before you shrug). The Team Folders app (the groupfolders lineage — it was renamed in recent Hub releases) combined with the workspace app's API-only delegated-administration lets a delegated admin bypass folder-level authorization and grant access to folders they were never granted. CVSS honestly marks Privileges Required: High: this needs someone who already holds delegated admin rights. But that is the model community organizations reach for — hand a volunteer or a department lead an API key and delegate them folder management — so the trust boundary the CVE breaks is one you likely drew across a shared instance already. The affected window is long: ten major app versions, 13.x through 22.x, fixed in 13.1.8 / 14.0.12 / 15.3.13 / 16.0.16 / 17.0.16 / 18.1.14 / 19.1.19 / 20.1.15 / 21.0.8 / 22.0.1. The only listed workaround is disabling the app.

CVE-2026-82985 — shared smart albums leak metadata the owner never offered (Moderate, confidentiality-High). The Photos app builds filter-based "smart albums" from the viewer's own folder configuration rather than the album owner's — so when an owner shares a smart album with you, your own photosSourceFolders decides which of their files the album searches. What leaks is metadata — file names, file IDs — of files outside the folders the owner meant to share. Reported by Root1856; the listed workaround is to not share filter-based smart albums until upgraded, and the advisory pins community fixes at 32.0.6 or later with the fix in the photos app.

The two Lows — what they are, and what they are for

CVE-2026-68493 (Low, 3.1): the circles app returns team membership to any logged-in user who can guess a circle's identifier — a 62-character-alphabet, 15-character ID, about a 2^89 search space. No realistic online brute force, which is why Low is the right grade, and the fix shipped in 32.0.12 / 33.0.6 / 34.0.1 with disable circles as the workaround. The lesson is worth keeping anyway: identifying an object was never the same as authorizing its access, and "unguessable ID" is a convenience, not a control.

CVE-2026-77166 (Low, 2.4): unsanitized emoji input in the Collectives page-emoji endpoint breaks the sidebar layout and can hide items; fixed in Collectives 4.4.1, no workaround listed. Read that again: Nextcloud publishes a rendering bug with a CVE number. Contrast it with the tag-message accounting this site had to document for Keycloak — where CVE counts were understated — and you get two projects at opposite ends of the same honesty axis. Over-reporting a sidebar layout bug as CVE-2026-77166 costs operators attention; under-reporting twenty fixes costs them patch decisions. They are not equivalent. But note which pattern makes a "we fixed five CVEs" changelog line mean exactly what it says.

What to actually do

  1. Land core on the October 15 maintenance points. 35.0.2 / 34.0.5 / 33.0.10 shipped the same morning, one per maintained branch. The 35.0.2 notes carry no CVE tags — they are the monthly maintenance round — but they include quiet auth-hardening worth having regardless: remember-me cookies now keep pointing at a live session token, session IDs only regenerate after a valid remember-me cookie, and password-reset links are checked against interactive-login timestamps. Those three fix real login weirdness even with no advisory attached. On the 32 community line, the last advisory-cited stop is 32.0.13 (the ImageMagick fix; the Enterprise line continues from there).
  2. Then update the apps — this is the half a core upgrade leaves behind. Of six advisories, four involve app fixes that a server-only upgrade does not touch: files_lock (32.0.6 / 33.0.6), Team Folders/groupfolders (the ten-version list above), photos, circles, Collectives 4.4.1. occ app:update --all after the core upgrade, then occ app:list and compare against the rows in each advisory. If you only update the server, CVE-2026-77169 and CVE-2026-77166 remain open on a fully-current install.
  3. Audit the preview configuration regardless of version. The providers named in the High — Font, HEIC, Illustrator, PDF, Photoshop, Postscript, SGI, TGA, TIFF — are the reachability switch. occ config:system:get enabledPreviewProviders and know why each of the named ones is there. If it is "the scanned records archive needs TIFF previews," that is a decision, and now it has a price attached.
  4. If you cannot upgrade this week: disable Team Folders, do not share filter-based smart albums, and drop the named preview providers. Each is a listed workaround; none requires downtime.

The pattern to carry away is the split, not any single CVE. Six advisories, one version series each fix — but two distinct patch surfaces. Core updates are nagged at you (admin dashboard, updater). Apps are not, not really; nothing stops a year of occ app:update --all being skipped while the dashboard shows your Nextcloud as current. The app store is the part of the inventory that silently rots, and this month's advisories are a demonstration: your occ app:list output is half of the risk register.

Sources: GHSA-7hwf-8pcj-33h4 / CVE-2026-104190 (Sep 17); GHSA-22w9-gpgv-pcgc / CVE-2026-77165, GHSA-9mjh-89xm-hcqw / CVE-2026-77169, GHSA-5gv7-hw69-w6px / CVE-2026-82985, GHSA-f99w-3pm7-v4cv / CVE-2026-68493, GHSA-4vpp-fp9q-9g23 / CVE-2026-77166 (all published Oct 8); Nextcloud 35.0.2 release notes, 35.0.2 / 34.0.5 / 33.0.10 all shipped Oct 15; nextcloud/security-advisories repo.