From f6586b480dcaf408f9b765270e8da6e7ba7f8974 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= <323649642+oc-tmueller@users.noreply.github.com> Date: Fri, 25 Sep 2026 14:27:44 +0200 Subject: [PATCH 1/5] docs: add release notes for ownCloud Classic 10.16.5 and 11.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both were tagged on 2026-09-25 and the release notes stopped at 11.0.0 and 10.16.4, so administrators had no entry for either. Both are security releases. Entries are grouped by the prefix core's own changelog entry carries - Security, Change, Bugfix - rather than re-classified here, and follow the existing patch-release template: the "Dear ownCloud administrator" paragraph, an IMPORTANT admonition, then discrete Security Fixes / Changes / Notable Bugfixes sections. 11.0.1 has 15 entries (3/3/9), 10.16.5 has 12 (4/1/7). Each is cited with the PR the changelog entry itself cites, which for the 10.16 line is the pair of master PR and 10.16 backport. Two items got more than a bullet because they change what an administrator will observe: The Imagick coder pinning (#41834) changes which files get a thumbnail at all. Media types come from the file name extension, so a file whose extension does not match its content now falls back to a media type icon instead of being rendered. That is in a NOTE with the affected extension list, which of those providers are registered on a stock install, and the font extensions that behave differently. It is the one part of either release that can look like a regression. The release tarball repackaging (#41824) matters to anyone who runs `occ integrity:check-app` or an anti-virus gate over the tarball, since `files_antivirus` was shipping its EICAR acceptance data. No Known Issues subsection: no patch-release section since 10.15.0 has one. Verified against the tags rather than transcribed by eye: the package lists and CVE list were diffed programmatically against changelog/10.16.5_2026-09-25/ and changelog/11.0.1_2026-09-25/ in owncloud/core and match exactly (26, 22 and 17 items). All 36 cited core PR/issue numbers were resolved through the API and exist. Worth noting for a future reader: #41676 really is the checkPropFind priority fix even though its title reads "chore(deps): update PHP dependencies" - that PR bundled both, which is why the citation looks wrong and is not. Rendered and checked in the built site: both sections appear in the right descending order, the toc picks them up (53 entries), the NOTE and IMPORTANT admonitions render as admonitions, and no attribute reference or list continuation was left unresolved. Co-Authored-By: Claude Opus 5 (1M context) Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com> --- .../ROOT/pages/server_release_notes.adoc | 150 ++++++++++++++++++ 1 file changed, 150 insertions(+) diff --git a/content/main/modules/ROOT/pages/server_release_notes.adoc b/content/main/modules/ROOT/pages/server_release_notes.adoc index b77eae4..e9ef009 100644 --- a/content/main/modules/ROOT/pages/server_release_notes.adoc +++ b/content/main/modules/ROOT/pages/server_release_notes.adoc @@ -17,6 +17,83 @@ next@docs::server_release_notes.adoc, next@docs_main::server_release_notes.adoc toc::[] +== Changes in 11.0.1 + +Dear ownCloud administrator, find below the changes and known issues in ownCloud Classic 11.0.1 that need your attention. You can also read the {oc-changelog-url}[full ownCloud Classic changelog] for further details on what has changed. + +IMPORTANT: This is a security release containing three security fixes. Upgrading is strongly recommended for all installations. Two of them change how previews are generated, which also changes *which* files get a thumbnail, so please read the note below before upgrading. + +[discrete] +=== Security Fixes + +* Prevent path traversal via appconfig `public_`/`remote_` keys: https://github.com/owncloud/core/pull/41856[#41856] + +An authenticated administrator could set such a key on the `core` app to a traversal value which `public.php` later included, leading to remote code execution. An included handler must now resolve to a PHP file inside the app's own directory, and the app-id guard can no longer be bypassed by a mangled spelling such as a trailing space. + +Note for integrators: the appconfig endpoints now refuse to *read* a `core` `public_`/`remote_` key as well as to write one, and refuse any key on `core` outside `[a-zA-Z0-9_.-]{1,64}`. Scripts which need a handler path should read it with `occ config:app:get`. Requesting a service which is not registered now answers 404 on both `public.php` and `remote.php`, and `remote.php` answers 503 for its own refusals instead of sending a malformed status line. +* Reject SVG and script content before it reaches ImageMagick bitmap previews: https://github.com/owncloud/core/pull/41827[#41827] + +Bitmap previews (PDF, Font and others) sanitized SVG content before decoding it, but fell back to the original, unsanitized bytes whenever the sanitizer could not parse the input — which happened for any malformed SVG or non-XML payload, not only for genuinely broken SVG files. A crafted malformed SVG or a raw MVG script could therefore reach ImageMagick unsanitized and trigger an MSL script that reads or writes arbitrary files as the web server user. Such content is now rejected outright, and bitmap previews decode through the same hardened Imagick options the dedicated SVG preview provider already used. +* Pin the Imagick coder for each preview provider: https://github.com/owncloud/core/pull/41834[#41834] + +Bitmap and SVG previews decoded content with no format hint, so ImageMagick's own content sniffing — independent of the mime-type check that decides whether a preview is attempted at all — could pick a different coder than the one a provider actually serves. PostScript-looking content, which that check must allow through for the PDF and PostScript providers, could therefore still reach the Ghostscript delegate through any other bitmap provider. Each provider now pins the exact coder it expects. The pin is applied in memory and introduces no temporary file of its own. + +NOTE: The coder pinning changes which files get a thumbnail. Media types are derived from the file name extension, so a file whose extension does not match its content now falls back to a media type icon instead of being rendered: a JPEG saved as `photo.tif` is routed to the TIFF provider, pinned to the TIFF coder, and no longer previews. The affected extensions are `ai`, `bw`, `eps`, `heic`, `heif`, `int`, `inta`, `pdf`, `ps`, `psd`, `rgb`, `rgba`, `sgi`, `tif` and `tiff`. Of those providers only SGI and Heic are registered by default, so on a stock install this is visible for `bw`, `int`, `inta`, `rgb`, `rgba`, `sgi`, `heic` and `heif`; the rest need their provider enabled in `enabledPreviewProviders`. The font extensions `otf`, `pfb` and `ttf` behave differently — the font coder accepts any bytes, so a mismatched file still produces a thumbnail, just one drawn by the font coder rather than reflecting the file's real content, and real `.otf` files gain previews they did not have before. + +[discrete] +=== Changes + +* Restore Oracle database support in the command line installer: https://github.com/owncloud/core/pull/41808[#41808] + +The Oracle database layer had always remained in the code base, but the setup class that makes it reachable had been removed, so an instance could no longer be installed against Oracle at all. `maintenance:install` accepts `--database=oci` again, together with the `--database-connection-string` option needed to reach a schema inside an Oracle pluggable database. The web installer is unchanged: Oracle is not offered there, because the default `supportedDatabases` config still lists only sqlite, mysql and pgsql. This restores test coverage for Oracle-specific code paths; it is not a statement about production support for Oracle. +* Require `rhukster/dom-sanitizer` as a tagged release: https://github.com/owncloud/core/pull/41785[#41785] + +The package was required as `dev-main`, a branch pin, which carries no version number. Vulnerability scanners match installed versions against advisory version ranges, so an unversioned dependency can never match any range and scanners silently reported nothing at all for it. It is now required as `^1.0.10`. The shipped code is equivalent, so this is a packaging and auditability change, not a functional one. +* Update PHP dependencies: https://github.com/owncloud/core/pull/41775[#41775] https://github.com/owncloud/core/pull/41791[#41791] https://github.com/owncloud/core/pull/41797[#41797] https://github.com/owncloud/core/pull/41809[#41809] https://github.com/owncloud/core/pull/41829[#41829] https://github.com/owncloud/core/pull/41839[#41839] https://github.com/owncloud/core/pull/41842[#41842] https://github.com/owncloud/core/pull/41864[#41864] + +The following have been updated: +** composer/semver (3.4.4 to 3.5.0) +** doctrine/lexer (3.0.1 to 3.0.2) +** firebase/php-jwt (v7.1.0 to v7.2.0) +** google/apiclient (v2.19.4 to v2.20.0) +** google/apiclient-services (v0.452.0 to v0.460.0) +** google/auth (v1.53.0 to v1.55.0) +** guzzlehttp/guzzle (7.15.2 to 7.15.5) +** guzzlehttp/promises (2.5.1 to 2.5.3) +** guzzlehttp/psr7 (2.13.0 to 2.13.1) +** laravel/serializable-closure (2.0.15 to 2.1.0) +** monolog/monolog (3.10.0 to 3.12.0) +** nikic/php-parser (v5.8.0 to v5.9.0) +** pear/archive_tar (1.6.0 to 1.6.1) +** phpseclib/phpseclib (3.0.55 to 3.0.57) +** punic/punic (3.8.1 to 3.8.2) +** rhukster/dom-sanitizer (1.0.14 to 1.0.17) +** sabre/event (5.1.8 to 5.1.9) +** symfony/console (v7.4.14 to v7.4.19) +** symfony/event-dispatcher (v7.4.14 to v7.4.17) +** symfony/mailer (v7.4.14 to v7.4.19) +** symfony/mime (v7.4.13 to v7.4.19) +** symfony/process (v7.4.13 to v7.4.19) +** symfony/routing (v7.4.13 to v7.4.18) +** symfony/service-contracts (v3.7.1 to v3.7.3) +** symfony/string (v7.4.13 to v7.4.19) +** symfony/translation (v7.4.14 to v7.4.17) + +[discrete] +=== Notable Bugfixes + +* Do not echo secrets when setting config values via `occ`: https://github.com/owncloud/core/pull/41780[#41780] + +`config:system:set` and `config:app:set` printed the value that had just been written back to stdout, so every secret configured through `occ` ended up in the terminal scrollback, the container log or the CI log of whoever ran the command — WOPI signing keys and app JWT secrets leaked out of Docker deployments that configure them from a startup hook. Both commands now print a placeholder instead. Recognition reuses the list of sensitive keys in `OC\SystemConfig` and falls back to matching the key name against the patterns `credential`, `key`, `passwd`, `password`, `pwd`, `salt`, `secret` and `token`, which covers app keys core does not know such as `wopi.token.key` or `jwt_secret`. Boolean values keep being shown. Only the confirmation output changed; the stored value is written as before. +* Ship only the app payload in the release tarballs: https://github.com/owncloud/core/issues/41824[#41824] + +The release bundles contained 13 bundled apps as the working tree they had been built in rather than as the app's release artifact, carrying `.git/`, `.github/`, `tests/`, `vendor-bin/` and `build/artifacts/` — 101.94 MB of the 441.8 MB uncompressed complete tarball, in 16 shipped git repositories. Three consequences: `files_antivirus` shipped its anti-virus acceptance data, so a ClamAV scan of the tarball or of an image built from it reported `Eicar-Test-Signature FOUND`; the development files were covered by the app's `appinfo/signature.json`, so they could not be deleted without breaking `occ integrity:check-app`; and the shipped `.git/` carried the release engineer's clone metadata. The affected app releases have been repackaged, and the release tooling now refuses to build a bundle containing a build working tree. The standard tarball was affected as well, through `notifications`. +* Restrict federated address book sync to the trusted server: https://github.com/owncloud/core/pull/41869[#41869] + +The federated system address book sync could request resources that do not belong to the trusted server it was syncing with, and could follow redirects away from that server. Requests which would leave the trusted server are now refused, and resource references which do not belong to it are skipped and logged. +* Show federated users in the share dialog when local users also match: https://github.com/owncloud/core/pull/41807[#41807] + +The share dialog only offered federated users when the search returned no local users and no local groups, so a single local match hid every federated result, including exact federated cloud id matches. The server-generated suggestion that made this filtering necessary — any search term containing an `@` was offered as a federated cloud id, even when it was the email address of an existing local account — is now skipped whenever the search matched a local user or group exactly. +* Restore index usage for filecache writes on Oracle: https://github.com/owncloud/core/pull/41818[#41818] + +On Oracle every compare column of an upsert was wrapped in `to_char()`. That cast is only needed for text and binary columns, and `to_char(column)` cannot use an index on that column — so file cache writes, which compare `storage` and `path_hash`, could no longer use the unique index `fs_storage_path_hash` and uploads, renames and file scans became very slow on large installations. Only text and binary compare columns are cast now. +* Avoid a deprecation notice when hashing the file cache path on Oracle: https://github.com/owncloud/core/pull/41808[#41808] + +Oracle cannot store empty strings, so the file cache converts them to null before writing a row. For the storage root, whose path is the empty string, that left `md5()` being called with null, which PHP 8 reports as a deprecated implicit null to string conversion. The stored `path_hash` was never wrong; the value is now cast to a string before hashing. +* Release the file handle when a bitmap preview cannot be decoded: https://github.com/owncloud/core/pull/41835[#41835] + +Bitmap previews closed the file they had opened only when decoding succeeded, so every file that could not be decoded leaked a file handle for the lifetime of the process. Generating previews for a directory of files ImageMagick has no decoder for could therefore exhaust the available file handles. A file that cannot be opened at all now reports no preview instead of failing the whole request. +* Show a media type icon when a preview file cannot be opened: https://github.com/owncloud/core/pull/41855[#41855] + +Generating an SVG preview read the file without checking that it had been opened, so a file the storage could not open — or one whose name the filesystem rejects — made the request fail with a server error instead of falling back to a media type icon. The bitmap providers shared that gap for one of the two values an unsuccessful open can return. The SVG provider also held the file handle and its lock until the request ended when the file opened but then failed to be read, an encrypted file with a missing or damaged key for instance. +* Reduce the priority of the `checkPropFind` event: https://github.com/owncloud/core/pull/41676[#41676] + +The `checkPropFind` event that triggers during an HTTP PROPFIND request must happen before the Sabre DAV `httpPropFind` event. That had been happening only because it sorts alphabetically first; it is now ordered explicitly, so it always executes first regardless of any other sort order. + == Changes in 11.0.0 Dear ownCloud administrator, find below the changes and known issues in ownCloud Classic 11.0.0 that need your attention. You can also read the {oc-changelog-url}[full ownCloud Classic changelog] for further details on what has changed. @@ -88,6 +165,79 @@ Files whose names end in extensions such as `.jpg`, `.png`, `.svg` or `.json` co * Reject non-numeric avatar crop coordinates and fix the avatar cropper: https://github.com/owncloud/core/issues/41723[#41723] * Add missing space to mail footer signature delimiter: https://github.com/owncloud/core/issues/41364[#41364] +== Changes in 10.16.5 + +Dear ownCloud administrator, find below the changes and known issues in ownCloud Classic 10.16.5 that need your attention. You can also read the {oc-changelog-url}[full ownCloud Classic changelog] for further details on what has changed. + +IMPORTANT: This is a security release closing, among others, sixteen published dependency advisories. Upgrading is strongly recommended for all installations. Two of the fixes change how previews are generated, which also changes *which* files get a thumbnail, so please read the note below before upgrading. + +[discrete] +=== Security Fixes + +* Prevent path traversal via appconfig `public_`/`remote_` keys: https://github.com/owncloud/core/pull/41803[#41803] + +An authenticated administrator could set such a key on the `core` app to a traversal value which `public.php` later included, leading to remote code execution. An included handler must now resolve to a PHP file inside the app's own directory, and the app-id guard can no longer be bypassed by a mangled spelling such as a trailing space. + +Note for integrators: the appconfig endpoints now refuse to *read* a `core` `public_`/`remote_` key as well as to write one. `getValue`/`hasKey` on the legacy `core/ajax/appconfig` endpoint had no such guard at all and returned the stored handler path; `GET /settings/appconfig/core/...` refused the exact lowercase prefix already, and now refuses a mangled spelling of it too, as well as any key on `core` outside `[a-zA-Z0-9_.-]{1,64}`. Scripts which need a handler path should read it with `occ config:app:get`. Requesting a service which is not registered now answers 404 on both `public.php` and `remote.php`, and `remote.php` answers 503 for its own refusals instead of sending a malformed status line. +* Reject SVG and script content before it reaches ImageMagick bitmap previews: https://github.com/owncloud/core/pull/41827[#41827] https://github.com/owncloud/core/pull/41863[#41863] + +Bitmap previews (PDF, Font and others) sanitized SVG content before decoding it, but fell back to the original, unsanitized bytes whenever the sanitizer could not parse the input — which happened for any malformed SVG or non-XML payload, not only for genuinely broken SVG files. A crafted malformed SVG or a raw MVG script could therefore reach ImageMagick unsanitized and trigger an MSL script that reads or writes arbitrary files as the web server user. Such content is now rejected outright, and bitmap previews decode through the same hardened Imagick options the dedicated SVG preview provider already used. Media type detection from file content now always reports a media type; it previously passed an unusable value on to its caller when the magic database behind it could not be loaded, which left the new check with nothing to test the content against. +* Pin the Imagick coder for each preview provider: https://github.com/owncloud/core/pull/41834[#41834] https://github.com/owncloud/core/pull/41863[#41863] + +Bitmap and SVG previews decoded content with no format hint, so ImageMagick's own content sniffing — independent of the mime-type check that decides whether a preview is attempted at all — could pick a different coder than the one a provider actually serves. PostScript-looking content, which that check must allow through for the PDF and PostScript providers, could therefore still reach the Ghostscript delegate through any other bitmap provider. Each provider now pins the exact coder it expects. The pin is applied in memory and introduces no temporary file of its own. +* Update PHP dependencies to close published advisories: https://github.com/owncloud/core/pull/41784[#41784] + +The 10.16 branch had not seen a dependency update since 10.16.4 and several bundled packages were carrying published advisories. They have been updated to versions that are not affected: +** guzzlehttp/guzzle (7.10.0 to 7.15.3) +** guzzlehttp/promises (2.3.0 to 2.5.2) +** guzzlehttp/psr7 (2.8.0 to 2.13.0) +** phpseclib/phpseclib (3.0.52 to 3.0.56) +** rhukster/dom-sanitizer (dev-main to 1.0.14) +** symfony/polyfill-php80 (v1.33.0 to v1.37.0) +** symfony/routing (v5.4.52 to v5.4.53) ++ +This closes sixteen advisories: CVE-2026-69246, CVE-2026-69245, CVE-2026-67354, CVE-2026-67355, CVE-2026-67353, CVE-2026-67339, CVE-2026-59883, CVE-2026-55767 and CVE-2026-55568 in guzzlehttp/guzzle; CVE-2026-59882, CVE-2026-55766, CVE-2026-48998 and CVE-2026-49214 in guzzlehttp/psr7; CVE-2026-55599 in phpseclib/phpseclib; CVE-2026-48784 in symfony/routing; and CVE-2026-40301 in rhukster/dom-sanitizer. ++ +`rhukster/dom-sanitizer` was required as `dev-main`, an unversioned branch pin. Such a pin carries no version number, so vulnerability scanners cannot match it against advisory ranges and silently report nothing for the package. It is now required as a tagged release, which both applies the CVE-2026-40301 fix and makes the dependency visible to scanners. ++ +`firebase/php-jwt` remains at 6.10.0 and is still affected by CVE-2025-45769 (low, weak encryption). The advisory is only fixed in 7.0.0, and every 7.x release requires PHP 8.0 or later, so it cannot be applied to the 10.16 line, which supports PHP 7.4. + +NOTE: The coder pinning changes which files get a thumbnail. Media types are derived from the file name extension, so a file whose extension does not match its content now falls back to a media type icon instead of being rendered: a JPEG saved as `photo.tif` is routed to the TIFF provider, pinned to the TIFF coder, and no longer previews. The affected extensions are `ai`, `bw`, `eps`, `heic`, `heif`, `int`, `inta`, `pdf`, `ps`, `psd`, `rgb`, `rgba`, `sgi`, `tif` and `tiff`. Of those providers only SGI and Heic are registered by default, so on a stock install this is visible for `bw`, `int`, `inta`, `rgb`, `rgba`, `sgi`, `heic` and `heif`; the rest need their provider enabled in `enabledPreviewProviders`. The font extensions `otf`, `pfb` and `ttf` behave differently — the font coder accepts any bytes, so a mismatched file still produces a thumbnail, just one drawn by the font coder rather than reflecting the file's real content, and real `.otf` files gain previews they did not have before. + +[discrete] +=== Changes + +* Update PHP dependencies: https://github.com/owncloud/core/pull/41787[#41787] https://github.com/owncloud/core/pull/41788[#41788] https://github.com/owncloud/core/pull/41793[#41793] https://github.com/owncloud/core/pull/41810[#41810] https://github.com/owncloud/core/pull/41830[#41830] https://github.com/owncloud/core/pull/41843[#41843] + +The following have been updated: +** deepdiver/zipstreamer (2.0.3 to 3.0.1) +** dg/composer-cleaner (v2.2.1 to v2.2.2) +** guzzlehttp/guzzle (7.15.3 to 7.15.5) +** guzzlehttp/promises (2.5.2 to 2.5.3) +** guzzlehttp/psr7 (2.13.0 to 2.13.1) +** monolog/monolog (2.11.0 to 2.11.1) +** nikic/php-parser (v5.7.0 to v5.9.0) +** pear/archive_tar (1.6.0 to 1.6.1) +** phpseclib/phpseclib (3.0.56 to 3.0.57) +** pimple/pimple (v3.6.1 to v3.6.2) +** punic/punic (3.8.1 to 3.8.2) +** rhukster/dom-sanitizer (1.0.14 to 1.0.17) +** sabre/dav (4.7.0 to 4.7.1) +** sabre/event (5.1.7 to 5.1.9) +** sabre/vobject (4.5.8 to 4.6.1) + +[discrete] +=== Notable Bugfixes + +* Restrict federated address book sync to the trusted server: https://github.com/owncloud/core/pull/41869[#41869] https://github.com/owncloud/core/pull/41870[#41870] + +The federated system address book sync could request resources that do not belong to the trusted server it was syncing with, and could follow redirects away from that server. Requests which would leave the trusted server are now refused, and resource references which do not belong to it are skipped and logged. +* Show federated users in the share dialog when local users also match: https://github.com/owncloud/core/pull/41814[#41814] + +The share dialog only offered federated users when the search returned no local users and no local groups, so a single local match hid every federated result, including exact federated cloud id matches. The server-generated suggestion that made this filtering necessary — any search term containing an `@` was offered as a federated cloud id, even when it was the email address of an existing local account — is now skipped whenever the search matched a local user or group exactly. +* Restore index usage for filecache writes on Oracle: https://github.com/owncloud/core/pull/41783[#41783] + +On Oracle every compare column of an upsert was wrapped in `to_char()`. That cast is only needed for text and binary columns, and `to_char(column)` cannot use an index on that column — so file cache writes, which compare `storage` and `path_hash`, could no longer use the unique index `fs_storage_path_hash` and uploads, renames and file scans became very slow on large installations. Only text and binary compare columns are cast now. +* Speed up Oracle schema introspection: https://github.com/owncloud/core/pull/41815[#41815] https://github.com/owncloud/core/pull/41819[#41819] + +Installing and upgrading on Oracle took an unreasonably long time: a fresh `occ maintenance:install` needed over 40 minutes. The bundled doctrine/dbal 2.13 describes a schema one table at a time — four queries per table, each inlining the table name as a literal, so Oracle hard parses every one of them — and the migration code asks for the full schema once per applied migration. Oracle schema introspection now reads the whole data dictionary with a fixed number of queries instead: reading a 48 table schema went from 194 queries to 6, and `occ maintenance:install` on PHP 7.4 from 43 minutes to 30 seconds. The resulting schema is unchanged and is compared against the previous implementation in the test suite. doctrine/dbal does this natively from version 3.4 onwards, which is why the 11.x line was never affected; upgrading it on the 10.16 branch is not an option, because its 3.x line changes public API that third-party apps use. +* Avoid a deprecation notice when hashing the file cache path on Oracle: https://github.com/owncloud/core/pull/41808[#41808] https://github.com/owncloud/core/pull/41815[#41815] + +Oracle cannot store empty strings, so the file cache converts them to null before writing a row. For the storage root, whose path is the empty string, that left `md5()` being called with null, which PHP 8 reports as a deprecated implicit null to string conversion. The stored `path_hash` was never wrong; the value is now cast to a string before hashing. +* Release the file handle when a bitmap preview cannot be decoded: https://github.com/owncloud/core/pull/41835[#41835] https://github.com/owncloud/core/pull/41837[#41837] + +Bitmap previews closed the file they had opened only when decoding succeeded, so every file that could not be decoded leaked a file handle for the lifetime of the process. Generating previews for a directory of files ImageMagick has no decoder for could therefore exhaust the available file handles. A file that cannot be opened at all is now reported as having no preview right away, instead of travelling on until ImageMagick rejects the empty content and an unrelated warning plus a misleading decoder error have been logged. +* Report a preview file that cannot be opened without logging noise: https://github.com/owncloud/core/pull/41855[#41855] https://github.com/owncloud/core/pull/41863[#41863] + +Generating an SVG preview read the file without checking that it had been opened. A file the storage could not open, or one whose name the filesystem rejects, still fell back to a media type icon, but only after warning about the read and then logging ImageMagick's complaint about content it had never received. The bitmap providers shared that gap for one of the two values an unsuccessful open can return. The SVG provider also held the file handle and its lock until the request ended when the file opened but then failed to be read, an encrypted file with a missing or damaged key for instance. + == Changes in 10.16.4 Dear ownCloud administrator, find below the changes and known issues in ownCloud Classic 10.16.4 that need your attention. You can also read the {oc-changelog-url}[full ownCloud Classic changelog] for further details on what has changed. From f0e3b749fa6c431e118cce2a93f504b1aa0a9d6c Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= <323649642+oc-tmueller@users.noreply.github.com> Date: Fri, 25 Sep 2026 14:27:44 +0200 Subject: [PATCH 2/5] docs: pin the docker examples to 10.16.5 and 11.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The two attributes that carry a full version into the docker install pages: `latest-server-download-version` in global-attributes.yml, which the 11.0 page uses for the image tag in four places, and the page-local `:docker-image-version:` on the 10.16 page. Both pages tell the reader to pin a full version rather than use `latest`, so the version they name has to move with the release or the advice points at the previous one. Caveat, deliberate: `owncloud/server` on Docker Hub has no 10.16.5 or 11.0.1 tag yet. Its newest are 11.0.0 and 10.16.4 from 2026-09-21. Both bumps are in flight in owncloud-docker/server and the tags appear when those merge, so this documents a tag that is queued rather than one that resolves today. Holding the release notes for it seemed worse than a short window where the docker snippet is ahead. Note that nothing in the test suite guards either attribute: static-files.test.js cross-checks only `latest-*-version`, so `latest-server-download-version` going stale is invisible to CI. That gap is now written down in README.md by #144. Co-Authored-By: Claude Opus 5 (1M context) Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com> --- .../modules/admin_manual/pages/installation/docker/index.adoc | 2 +- global-attributes.yml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/content/server/10.16/modules/admin_manual/pages/installation/docker/index.adoc b/content/server/10.16/modules/admin_manual/pages/installation/docker/index.adoc index 488e365..013855b 100644 --- a/content/server/10.16/modules/admin_manual/pages/installation/docker/index.adoc +++ b/content/server/10.16/modules/admin_manual/pages/installation/docker/index.adoc @@ -8,7 +8,7 @@ // the image version documented on this branch. this is intentionally a literal // and not an attribute, because the global -version attributes track the latest // release of the product and not this branch. -:docker-image-version: 10.16.4 +:docker-image-version: 10.16.5 == Introduction diff --git a/global-attributes.yml b/global-attributes.yml index a1f5c53..1c232bf 100644 --- a/global-attributes.yml +++ b/global-attributes.yml @@ -28,7 +28,7 @@ previous-docs-version: 'next' # server latest-server-version: '11.0' - latest-server-download-version: '11.0.0' + latest-server-download-version: '11.0.1' previous-server-version: '10.16' current-server-version: '11.0' oc-changelog-url: 'https://owncloud.com/changelog/server/' From 354f7ea15f83c0fdfce8cc1cb95cfcdc28a4fbae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= <323649642+oc-tmueller@users.noreply.github.com> Date: Fri, 25 Sep 2026 14:48:37 +0200 Subject: [PATCH 3/5] docs: fix three accuracy defects in the new release notes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Review follow-up on the 10.16.5 and 11.0.1 sections. The three closing paragraphs of 10.16.5's dependency security bullet rendered *inside* the last package row. A `+` continuation after a `**` item attaches to that item, not to its parent, so "This closes sixteen advisories…", the dom-sanitizer paragraph and the php-jwt paragraph all appeared indented under `symfony/routing (v5.4.52 to v5.4.53)` - reading as if sixteen CVEs, the branch pin and the php-jwt exception were all about symfony/routing. The prose now precedes the nested list, which is the shape the 10.16.2 bullet already uses. Verified in the built page: the nested list is exactly the seven package rows and nothing else. The `checkPropFind` bullet linked #41676, which is **closed and was never merged** (`merged: false`, head `sabre-update-20260711`). The change shipped via #41797, merge commit 23ccb865d6 on 2026-08-30, which carried `changelog/unreleased/41676` and so kept the abandoned PR's number as the entry's filename. Core's changelog cites the dead number; reproducing it faithfully would have sent every reader to an unrelated closed PR, so the link is #41797 now. This also corrects the previous commit message, which argued #41676 was right on the strength of its file list alone - the files matched because that PR authored the fix, but it is not how the fix landed. 10.16.5's Oracle path-hash bullet said the notice is what "PHP 8 reports", in a section whose release line supports PHP 7.4 only - so it described a symptom no 10.16 installation can see. It now says that outright, and that the stored hash was never wrong either way because `md5(null)` coerces to `md5('')`. The 11.0.1 wording is untouched, where PHP 8 is the runtime and the original sentence is correct. Rebuilt: 51 pass, 1 skip, 0 fail. #41676 no longer appears anywhere in the page. Co-Authored-By: Claude Opus 5 (1M context) Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com> --- .../modules/ROOT/pages/server_release_notes.adoc | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/content/main/modules/ROOT/pages/server_release_notes.adoc b/content/main/modules/ROOT/pages/server_release_notes.adoc index e9ef009..64772b5 100644 --- a/content/main/modules/ROOT/pages/server_release_notes.adoc +++ b/content/main/modules/ROOT/pages/server_release_notes.adoc @@ -91,7 +91,7 @@ Oracle cannot store empty strings, so the file cache converts them to null befor Bitmap previews closed the file they had opened only when decoding succeeded, so every file that could not be decoded leaked a file handle for the lifetime of the process. Generating previews for a directory of files ImageMagick has no decoder for could therefore exhaust the available file handles. A file that cannot be opened at all now reports no preview instead of failing the whole request. * Show a media type icon when a preview file cannot be opened: https://github.com/owncloud/core/pull/41855[#41855] + Generating an SVG preview read the file without checking that it had been opened, so a file the storage could not open — or one whose name the filesystem rejects — made the request fail with a server error instead of falling back to a media type icon. The bitmap providers shared that gap for one of the two values an unsuccessful open can return. The SVG provider also held the file handle and its lock until the request ended when the file opened but then failed to be read, an encrypted file with a missing or damaged key for instance. -* Reduce the priority of the `checkPropFind` event: https://github.com/owncloud/core/pull/41676[#41676] + +* Reduce the priority of the `checkPropFind` event: https://github.com/owncloud/core/pull/41797[#41797] + The `checkPropFind` event that triggers during an HTTP PROPFIND request must happen before the Sabre DAV `httpPropFind` event. That had been happening only because it sorts alphabetically first; it is now ordered explicitly, so it always executes first regardless of any other sort order. == Changes in 11.0.0 @@ -182,7 +182,10 @@ Bitmap previews (PDF, Font and others) sanitized SVG content before decoding it, * Pin the Imagick coder for each preview provider: https://github.com/owncloud/core/pull/41834[#41834] https://github.com/owncloud/core/pull/41863[#41863] + Bitmap and SVG previews decoded content with no format hint, so ImageMagick's own content sniffing — independent of the mime-type check that decides whether a preview is attempted at all — could pick a different coder than the one a provider actually serves. PostScript-looking content, which that check must allow through for the PDF and PostScript providers, could therefore still reach the Ghostscript delegate through any other bitmap provider. Each provider now pins the exact coder it expects. The pin is applied in memory and introduces no temporary file of its own. * Update PHP dependencies to close published advisories: https://github.com/owncloud/core/pull/41784[#41784] + -The 10.16 branch had not seen a dependency update since 10.16.4 and several bundled packages were carrying published advisories. They have been updated to versions that are not affected: +The 10.16 branch had not seen a dependency update since 10.16.4 and several bundled packages were carrying published advisories. This closes sixteen of them: CVE-2026-69246, CVE-2026-69245, CVE-2026-67354, CVE-2026-67355, CVE-2026-67353, CVE-2026-67339, CVE-2026-59883, CVE-2026-55767 and CVE-2026-55568 in guzzlehttp/guzzle; CVE-2026-59882, CVE-2026-55766, CVE-2026-48998 and CVE-2026-49214 in guzzlehttp/psr7; CVE-2026-55599 in phpseclib/phpseclib; CVE-2026-48784 in symfony/routing; and CVE-2026-40301 in rhukster/dom-sanitizer. + +`rhukster/dom-sanitizer` was required as `dev-main`, an unversioned branch pin. Such a pin carries no version number, so vulnerability scanners cannot match it against advisory ranges and silently report nothing for the package. It is now required as a tagged release, which both applies the CVE-2026-40301 fix and makes the dependency visible to scanners. + +`firebase/php-jwt` remains at 6.10.0 and is still affected by CVE-2025-45769 (low, weak encryption). The advisory is only fixed in 7.0.0, and every 7.x release requires PHP 8.0 or later, so it cannot be applied to the 10.16 line, which supports PHP 7.4. + +The following have been updated to versions that are not affected: ** guzzlehttp/guzzle (7.10.0 to 7.15.3) ** guzzlehttp/promises (2.3.0 to 2.5.2) ** guzzlehttp/psr7 (2.8.0 to 2.13.0) @@ -190,12 +193,6 @@ The 10.16 branch had not seen a dependency update since 10.16.4 and several bund ** rhukster/dom-sanitizer (dev-main to 1.0.14) ** symfony/polyfill-php80 (v1.33.0 to v1.37.0) ** symfony/routing (v5.4.52 to v5.4.53) -+ -This closes sixteen advisories: CVE-2026-69246, CVE-2026-69245, CVE-2026-67354, CVE-2026-67355, CVE-2026-67353, CVE-2026-67339, CVE-2026-59883, CVE-2026-55767 and CVE-2026-55568 in guzzlehttp/guzzle; CVE-2026-59882, CVE-2026-55766, CVE-2026-48998 and CVE-2026-49214 in guzzlehttp/psr7; CVE-2026-55599 in phpseclib/phpseclib; CVE-2026-48784 in symfony/routing; and CVE-2026-40301 in rhukster/dom-sanitizer. -+ -`rhukster/dom-sanitizer` was required as `dev-main`, an unversioned branch pin. Such a pin carries no version number, so vulnerability scanners cannot match it against advisory ranges and silently report nothing for the package. It is now required as a tagged release, which both applies the CVE-2026-40301 fix and makes the dependency visible to scanners. -+ -`firebase/php-jwt` remains at 6.10.0 and is still affected by CVE-2025-45769 (low, weak encryption). The advisory is only fixed in 7.0.0, and every 7.x release requires PHP 8.0 or later, so it cannot be applied to the 10.16 line, which supports PHP 7.4. NOTE: The coder pinning changes which files get a thumbnail. Media types are derived from the file name extension, so a file whose extension does not match its content now falls back to a media type icon instead of being rendered: a JPEG saved as `photo.tif` is routed to the TIFF provider, pinned to the TIFF coder, and no longer previews. The affected extensions are `ai`, `bw`, `eps`, `heic`, `heif`, `int`, `inta`, `pdf`, `ps`, `psd`, `rgb`, `rgba`, `sgi`, `tif` and `tiff`. Of those providers only SGI and Heic are registered by default, so on a stock install this is visible for `bw`, `int`, `inta`, `rgb`, `rgba`, `sgi`, `heic` and `heif`; the rest need their provider enabled in `enabledPreviewProviders`. The font extensions `otf`, `pfb` and `ttf` behave differently — the font coder accepts any bytes, so a mismatched file still produces a thumbnail, just one drawn by the font coder rather than reflecting the file's real content, and real `.otf` files gain previews they did not have before. @@ -232,7 +229,7 @@ On Oracle every compare column of an upsert was wrapped in `to_char()`. That cas * Speed up Oracle schema introspection: https://github.com/owncloud/core/pull/41815[#41815] https://github.com/owncloud/core/pull/41819[#41819] + Installing and upgrading on Oracle took an unreasonably long time: a fresh `occ maintenance:install` needed over 40 minutes. The bundled doctrine/dbal 2.13 describes a schema one table at a time — four queries per table, each inlining the table name as a literal, so Oracle hard parses every one of them — and the migration code asks for the full schema once per applied migration. Oracle schema introspection now reads the whole data dictionary with a fixed number of queries instead: reading a 48 table schema went from 194 queries to 6, and `occ maintenance:install` on PHP 7.4 from 43 minutes to 30 seconds. The resulting schema is unchanged and is compared against the previous implementation in the test suite. doctrine/dbal does this natively from version 3.4 onwards, which is why the 11.x line was never affected; upgrading it on the 10.16 branch is not an option, because its 3.x line changes public API that third-party apps use. * Avoid a deprecation notice when hashing the file cache path on Oracle: https://github.com/owncloud/core/pull/41808[#41808] https://github.com/owncloud/core/pull/41815[#41815] + -Oracle cannot store empty strings, so the file cache converts them to null before writing a row. For the storage root, whose path is the empty string, that left `md5()` being called with null, which PHP 8 reports as a deprecated implicit null to string conversion. The stored `path_hash` was never wrong; the value is now cast to a string before hashing. +Oracle cannot store empty strings, so the file cache converts them to null before writing a row. For the storage root, whose path is the empty string, that left `md5()` being called with null. PHP 7.4, the only version this release line supports, does not complain about that, so an ownCloud 10.16 installation sees no symptom: the notice appears on PHP 8 and under the test suite's strict error handling, which is where it was found. The stored `path_hash` was never wrong either way, because `md5(null)` coerces to `md5('')`; the value is now cast to a string before hashing. * Release the file handle when a bitmap preview cannot be decoded: https://github.com/owncloud/core/pull/41835[#41835] https://github.com/owncloud/core/pull/41837[#41837] + Bitmap previews closed the file they had opened only when decoding succeeded, so every file that could not be decoded leaked a file handle for the lifetime of the process. Generating previews for a directory of files ImageMagick has no decoder for could therefore exhaust the available file handles. A file that cannot be opened at all is now reported as having no preview right away, instead of travelling on until ImageMagick rejects the empty content and an unrelated warning plus a misleading decoder error have been logged. * Report a preview file that cannot be opened without logging noise: https://github.com/owncloud/core/pull/41855[#41855] https://github.com/owncloud/core/pull/41863[#41863] + From ccf63e704f4a67be3d9db3a9f5be9da306d7a339 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= <323649642+oc-tmueller@users.noreply.github.com> Date: Fri, 25 Sep 2026 15:00:31 +0200 Subject: [PATCH 4/5] docs: tighten two version claims and credit the closed #41676 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Round-2 review follow-up, both prose only. The Oracle path-hash deprecation is PHP **8.1**'s - the RFC deprecating null for non-nullable internal parameters - so PHP 8.0 is silent too and "appears on PHP 8" over-claimed in a sentence whose whole point is runtime precision. It also read as though the 10.16 test suite surfaces it, but that suite pins 7.4 on this branch and 7.4 raises nothing; it was found on the 11.x line under PHP 8.3. Both are now stated as such. The `checkPropFind` bullet now names #41676 as well. It is closed and unmerged, so it cannot be the citation, but core's changelog cites it and a reader cross-referencing the two sources otherwise finds nothing that matches - and #41797 is a dependency-bump PR cited twice in the same section. The bullet says which PR authored the change and which one shipped it. Also corrected: the fix ordered `checkPropFind` ahead of listeners of *equal priority*, not "alphabetically" - sabre/event compares priority and nothing else. Rebuilt: 51 pass, 1 skip, 0 fail, no unresolved attribute references. Co-Authored-By: Claude Opus 5 (1M context) Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com> --- content/main/modules/ROOT/pages/server_release_notes.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/main/modules/ROOT/pages/server_release_notes.adoc b/content/main/modules/ROOT/pages/server_release_notes.adoc index 64772b5..43c9ad9 100644 --- a/content/main/modules/ROOT/pages/server_release_notes.adoc +++ b/content/main/modules/ROOT/pages/server_release_notes.adoc @@ -92,7 +92,7 @@ Bitmap previews closed the file they had opened only when decoding succeeded, so * Show a media type icon when a preview file cannot be opened: https://github.com/owncloud/core/pull/41855[#41855] + Generating an SVG preview read the file without checking that it had been opened, so a file the storage could not open — or one whose name the filesystem rejects — made the request fail with a server error instead of falling back to a media type icon. The bitmap providers shared that gap for one of the two values an unsuccessful open can return. The SVG provider also held the file handle and its lock until the request ended when the file opened but then failed to be read, an encrypted file with a missing or damaged key for instance. * Reduce the priority of the `checkPropFind` event: https://github.com/owncloud/core/pull/41797[#41797] + -The `checkPropFind` event that triggers during an HTTP PROPFIND request must happen before the Sabre DAV `httpPropFind` event. That had been happening only because it sorts alphabetically first; it is now ordered explicitly, so it always executes first regardless of any other sort order. +The `checkPropFind` event that triggers during an HTTP PROPFIND request must happen before the Sabre DAV `httpPropFind` event. That had been happening only because it sorted first among listeners of equal priority; it is now ordered explicitly, so it always executes first regardless of any other sort order. The change was authored in https://github.com/owncloud/core/pull/41676[#41676], which was closed without being merged, and shipped in #41797 alongside that dependency update — core's changelog still cites the closed number. == Changes in 11.0.0 @@ -229,7 +229,7 @@ On Oracle every compare column of an upsert was wrapped in `to_char()`. That cas * Speed up Oracle schema introspection: https://github.com/owncloud/core/pull/41815[#41815] https://github.com/owncloud/core/pull/41819[#41819] + Installing and upgrading on Oracle took an unreasonably long time: a fresh `occ maintenance:install` needed over 40 minutes. The bundled doctrine/dbal 2.13 describes a schema one table at a time — four queries per table, each inlining the table name as a literal, so Oracle hard parses every one of them — and the migration code asks for the full schema once per applied migration. Oracle schema introspection now reads the whole data dictionary with a fixed number of queries instead: reading a 48 table schema went from 194 queries to 6, and `occ maintenance:install` on PHP 7.4 from 43 minutes to 30 seconds. The resulting schema is unchanged and is compared against the previous implementation in the test suite. doctrine/dbal does this natively from version 3.4 onwards, which is why the 11.x line was never affected; upgrading it on the 10.16 branch is not an option, because its 3.x line changes public API that third-party apps use. * Avoid a deprecation notice when hashing the file cache path on Oracle: https://github.com/owncloud/core/pull/41808[#41808] https://github.com/owncloud/core/pull/41815[#41815] + -Oracle cannot store empty strings, so the file cache converts them to null before writing a row. For the storage root, whose path is the empty string, that left `md5()` being called with null. PHP 7.4, the only version this release line supports, does not complain about that, so an ownCloud 10.16 installation sees no symptom: the notice appears on PHP 8 and under the test suite's strict error handling, which is where it was found. The stored `path_hash` was never wrong either way, because `md5(null)` coerces to `md5('')`; the value is now cast to a string before hashing. +Oracle cannot store empty strings, so the file cache converts them to null before writing a row. For the storage root, whose path is the empty string, that left `md5()` being called with null. The deprecation is PHP 8.1's, for passing null to a non-nullable internal parameter, so PHP 7.4 — the only version this release line supports — is silent and an ownCloud 10.16 installation sees no symptom. It was found on the 11.x line, whose test suite runs PHP 8.3 and turns the notice into an error. The stored `path_hash` was never wrong either way, because `md5(null)` coerces to `md5('')`; the value is now cast to a string before hashing. * Release the file handle when a bitmap preview cannot be decoded: https://github.com/owncloud/core/pull/41835[#41835] https://github.com/owncloud/core/pull/41837[#41837] + Bitmap previews closed the file they had opened only when decoding succeeded, so every file that could not be decoded leaked a file handle for the lifetime of the process. Generating previews for a directory of files ImageMagick has no decoder for could therefore exhaust the available file handles. A file that cannot be opened at all is now reported as having no preview right away, instead of travelling on until ImageMagick rejects the empty content and an unrelated warning plus a misleading decoder error have been logged. * Report a preview file that cannot be opened without logging noise: https://github.com/owncloud/core/pull/41855[#41855] https://github.com/owncloud/core/pull/41863[#41863] + From 32fb7747d8203522ae9a930b2f9e16b17343ce9f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Thomas=20M=C3=BCller?= <323649642+oc-tmueller@users.noreply.github.com> Date: Fri, 25 Sep 2026 15:15:33 +0200 Subject: [PATCH 5/5] docs: cut the per-entry breakdown from the 10.16.5 and 11.0.1 notes MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Both sections are now the heading, the standard "Dear ownCloud administrator" paragraph pointing at the changelog, and a one-line security-release notice matching the wording 10.16.4 already uses. The enumerated Security Fixes / Changes / Notable Bugfixes blocks are gone: they restated the changelog at length, and counting the security fixes in the banner made these releases read as far more alarming than the ones either side of them. The changelog is where that detail belongs and the intro paragraph already links it. That also drops the preview-behaviour NOTE and the dependency and CVE tables. 77 lines become 6 for 11.0.1, 70 become 6 for 10.16.5. Rebuilt: 51 pass, 1 skip, 0 fail. Both sections still appear in the toc, and neither now renders a sub-heading, list or admonition other than the one IMPORTANT. Co-Authored-By: Claude Opus 5 (1M context) Signed-off-by: Thomas Müller <323649642+oc-tmueller@users.noreply.github.com> --- .../ROOT/pages/server_release_notes.adoc | 139 +----------------- 1 file changed, 2 insertions(+), 137 deletions(-) diff --git a/content/main/modules/ROOT/pages/server_release_notes.adoc b/content/main/modules/ROOT/pages/server_release_notes.adoc index 43c9ad9..13c0e5f 100644 --- a/content/main/modules/ROOT/pages/server_release_notes.adoc +++ b/content/main/modules/ROOT/pages/server_release_notes.adoc @@ -21,78 +21,7 @@ toc::[] Dear ownCloud administrator, find below the changes and known issues in ownCloud Classic 11.0.1 that need your attention. You can also read the {oc-changelog-url}[full ownCloud Classic changelog] for further details on what has changed. -IMPORTANT: This is a security release containing three security fixes. Upgrading is strongly recommended for all installations. Two of them change how previews are generated, which also changes *which* files get a thumbnail, so please read the note below before upgrading. - -[discrete] -=== Security Fixes - -* Prevent path traversal via appconfig `public_`/`remote_` keys: https://github.com/owncloud/core/pull/41856[#41856] + -An authenticated administrator could set such a key on the `core` app to a traversal value which `public.php` later included, leading to remote code execution. An included handler must now resolve to a PHP file inside the app's own directory, and the app-id guard can no longer be bypassed by a mangled spelling such as a trailing space. + -Note for integrators: the appconfig endpoints now refuse to *read* a `core` `public_`/`remote_` key as well as to write one, and refuse any key on `core` outside `[a-zA-Z0-9_.-]{1,64}`. Scripts which need a handler path should read it with `occ config:app:get`. Requesting a service which is not registered now answers 404 on both `public.php` and `remote.php`, and `remote.php` answers 503 for its own refusals instead of sending a malformed status line. -* Reject SVG and script content before it reaches ImageMagick bitmap previews: https://github.com/owncloud/core/pull/41827[#41827] + -Bitmap previews (PDF, Font and others) sanitized SVG content before decoding it, but fell back to the original, unsanitized bytes whenever the sanitizer could not parse the input — which happened for any malformed SVG or non-XML payload, not only for genuinely broken SVG files. A crafted malformed SVG or a raw MVG script could therefore reach ImageMagick unsanitized and trigger an MSL script that reads or writes arbitrary files as the web server user. Such content is now rejected outright, and bitmap previews decode through the same hardened Imagick options the dedicated SVG preview provider already used. -* Pin the Imagick coder for each preview provider: https://github.com/owncloud/core/pull/41834[#41834] + -Bitmap and SVG previews decoded content with no format hint, so ImageMagick's own content sniffing — independent of the mime-type check that decides whether a preview is attempted at all — could pick a different coder than the one a provider actually serves. PostScript-looking content, which that check must allow through for the PDF and PostScript providers, could therefore still reach the Ghostscript delegate through any other bitmap provider. Each provider now pins the exact coder it expects. The pin is applied in memory and introduces no temporary file of its own. - -NOTE: The coder pinning changes which files get a thumbnail. Media types are derived from the file name extension, so a file whose extension does not match its content now falls back to a media type icon instead of being rendered: a JPEG saved as `photo.tif` is routed to the TIFF provider, pinned to the TIFF coder, and no longer previews. The affected extensions are `ai`, `bw`, `eps`, `heic`, `heif`, `int`, `inta`, `pdf`, `ps`, `psd`, `rgb`, `rgba`, `sgi`, `tif` and `tiff`. Of those providers only SGI and Heic are registered by default, so on a stock install this is visible for `bw`, `int`, `inta`, `rgb`, `rgba`, `sgi`, `heic` and `heif`; the rest need their provider enabled in `enabledPreviewProviders`. The font extensions `otf`, `pfb` and `ttf` behave differently — the font coder accepts any bytes, so a mismatched file still produces a thumbnail, just one drawn by the font coder rather than reflecting the file's real content, and real `.otf` files gain previews they did not have before. - -[discrete] -=== Changes - -* Restore Oracle database support in the command line installer: https://github.com/owncloud/core/pull/41808[#41808] + -The Oracle database layer had always remained in the code base, but the setup class that makes it reachable had been removed, so an instance could no longer be installed against Oracle at all. `maintenance:install` accepts `--database=oci` again, together with the `--database-connection-string` option needed to reach a schema inside an Oracle pluggable database. The web installer is unchanged: Oracle is not offered there, because the default `supportedDatabases` config still lists only sqlite, mysql and pgsql. This restores test coverage for Oracle-specific code paths; it is not a statement about production support for Oracle. -* Require `rhukster/dom-sanitizer` as a tagged release: https://github.com/owncloud/core/pull/41785[#41785] + -The package was required as `dev-main`, a branch pin, which carries no version number. Vulnerability scanners match installed versions against advisory version ranges, so an unversioned dependency can never match any range and scanners silently reported nothing at all for it. It is now required as `^1.0.10`. The shipped code is equivalent, so this is a packaging and auditability change, not a functional one. -* Update PHP dependencies: https://github.com/owncloud/core/pull/41775[#41775] https://github.com/owncloud/core/pull/41791[#41791] https://github.com/owncloud/core/pull/41797[#41797] https://github.com/owncloud/core/pull/41809[#41809] https://github.com/owncloud/core/pull/41829[#41829] https://github.com/owncloud/core/pull/41839[#41839] https://github.com/owncloud/core/pull/41842[#41842] https://github.com/owncloud/core/pull/41864[#41864] + -The following have been updated: -** composer/semver (3.4.4 to 3.5.0) -** doctrine/lexer (3.0.1 to 3.0.2) -** firebase/php-jwt (v7.1.0 to v7.2.0) -** google/apiclient (v2.19.4 to v2.20.0) -** google/apiclient-services (v0.452.0 to v0.460.0) -** google/auth (v1.53.0 to v1.55.0) -** guzzlehttp/guzzle (7.15.2 to 7.15.5) -** guzzlehttp/promises (2.5.1 to 2.5.3) -** guzzlehttp/psr7 (2.13.0 to 2.13.1) -** laravel/serializable-closure (2.0.15 to 2.1.0) -** monolog/monolog (3.10.0 to 3.12.0) -** nikic/php-parser (v5.8.0 to v5.9.0) -** pear/archive_tar (1.6.0 to 1.6.1) -** phpseclib/phpseclib (3.0.55 to 3.0.57) -** punic/punic (3.8.1 to 3.8.2) -** rhukster/dom-sanitizer (1.0.14 to 1.0.17) -** sabre/event (5.1.8 to 5.1.9) -** symfony/console (v7.4.14 to v7.4.19) -** symfony/event-dispatcher (v7.4.14 to v7.4.17) -** symfony/mailer (v7.4.14 to v7.4.19) -** symfony/mime (v7.4.13 to v7.4.19) -** symfony/process (v7.4.13 to v7.4.19) -** symfony/routing (v7.4.13 to v7.4.18) -** symfony/service-contracts (v3.7.1 to v3.7.3) -** symfony/string (v7.4.13 to v7.4.19) -** symfony/translation (v7.4.14 to v7.4.17) - -[discrete] -=== Notable Bugfixes - -* Do not echo secrets when setting config values via `occ`: https://github.com/owncloud/core/pull/41780[#41780] + -`config:system:set` and `config:app:set` printed the value that had just been written back to stdout, so every secret configured through `occ` ended up in the terminal scrollback, the container log or the CI log of whoever ran the command — WOPI signing keys and app JWT secrets leaked out of Docker deployments that configure them from a startup hook. Both commands now print a placeholder instead. Recognition reuses the list of sensitive keys in `OC\SystemConfig` and falls back to matching the key name against the patterns `credential`, `key`, `passwd`, `password`, `pwd`, `salt`, `secret` and `token`, which covers app keys core does not know such as `wopi.token.key` or `jwt_secret`. Boolean values keep being shown. Only the confirmation output changed; the stored value is written as before. -* Ship only the app payload in the release tarballs: https://github.com/owncloud/core/issues/41824[#41824] + -The release bundles contained 13 bundled apps as the working tree they had been built in rather than as the app's release artifact, carrying `.git/`, `.github/`, `tests/`, `vendor-bin/` and `build/artifacts/` — 101.94 MB of the 441.8 MB uncompressed complete tarball, in 16 shipped git repositories. Three consequences: `files_antivirus` shipped its anti-virus acceptance data, so a ClamAV scan of the tarball or of an image built from it reported `Eicar-Test-Signature FOUND`; the development files were covered by the app's `appinfo/signature.json`, so they could not be deleted without breaking `occ integrity:check-app`; and the shipped `.git/` carried the release engineer's clone metadata. The affected app releases have been repackaged, and the release tooling now refuses to build a bundle containing a build working tree. The standard tarball was affected as well, through `notifications`. -* Restrict federated address book sync to the trusted server: https://github.com/owncloud/core/pull/41869[#41869] + -The federated system address book sync could request resources that do not belong to the trusted server it was syncing with, and could follow redirects away from that server. Requests which would leave the trusted server are now refused, and resource references which do not belong to it are skipped and logged. -* Show federated users in the share dialog when local users also match: https://github.com/owncloud/core/pull/41807[#41807] + -The share dialog only offered federated users when the search returned no local users and no local groups, so a single local match hid every federated result, including exact federated cloud id matches. The server-generated suggestion that made this filtering necessary — any search term containing an `@` was offered as a federated cloud id, even when it was the email address of an existing local account — is now skipped whenever the search matched a local user or group exactly. -* Restore index usage for filecache writes on Oracle: https://github.com/owncloud/core/pull/41818[#41818] + -On Oracle every compare column of an upsert was wrapped in `to_char()`. That cast is only needed for text and binary columns, and `to_char(column)` cannot use an index on that column — so file cache writes, which compare `storage` and `path_hash`, could no longer use the unique index `fs_storage_path_hash` and uploads, renames and file scans became very slow on large installations. Only text and binary compare columns are cast now. -* Avoid a deprecation notice when hashing the file cache path on Oracle: https://github.com/owncloud/core/pull/41808[#41808] + -Oracle cannot store empty strings, so the file cache converts them to null before writing a row. For the storage root, whose path is the empty string, that left `md5()` being called with null, which PHP 8 reports as a deprecated implicit null to string conversion. The stored `path_hash` was never wrong; the value is now cast to a string before hashing. -* Release the file handle when a bitmap preview cannot be decoded: https://github.com/owncloud/core/pull/41835[#41835] + -Bitmap previews closed the file they had opened only when decoding succeeded, so every file that could not be decoded leaked a file handle for the lifetime of the process. Generating previews for a directory of files ImageMagick has no decoder for could therefore exhaust the available file handles. A file that cannot be opened at all now reports no preview instead of failing the whole request. -* Show a media type icon when a preview file cannot be opened: https://github.com/owncloud/core/pull/41855[#41855] + -Generating an SVG preview read the file without checking that it had been opened, so a file the storage could not open — or one whose name the filesystem rejects — made the request fail with a server error instead of falling back to a media type icon. The bitmap providers shared that gap for one of the two values an unsuccessful open can return. The SVG provider also held the file handle and its lock until the request ended when the file opened but then failed to be read, an encrypted file with a missing or damaged key for instance. -* Reduce the priority of the `checkPropFind` event: https://github.com/owncloud/core/pull/41797[#41797] + -The `checkPropFind` event that triggers during an HTTP PROPFIND request must happen before the Sabre DAV `httpPropFind` event. That had been happening only because it sorted first among listeners of equal priority; it is now ordered explicitly, so it always executes first regardless of any other sort order. The change was authored in https://github.com/owncloud/core/pull/41676[#41676], which was closed without being merged, and shipped in #41797 alongside that dependency update — core's changelog still cites the closed number. +IMPORTANT: This is a security release. Upgrading is strongly recommended for all installations. == Changes in 11.0.0 @@ -169,71 +98,7 @@ Files whose names end in extensions such as `.jpg`, `.png`, `.svg` or `.json` co Dear ownCloud administrator, find below the changes and known issues in ownCloud Classic 10.16.5 that need your attention. You can also read the {oc-changelog-url}[full ownCloud Classic changelog] for further details on what has changed. -IMPORTANT: This is a security release closing, among others, sixteen published dependency advisories. Upgrading is strongly recommended for all installations. Two of the fixes change how previews are generated, which also changes *which* files get a thumbnail, so please read the note below before upgrading. - -[discrete] -=== Security Fixes - -* Prevent path traversal via appconfig `public_`/`remote_` keys: https://github.com/owncloud/core/pull/41803[#41803] + -An authenticated administrator could set such a key on the `core` app to a traversal value which `public.php` later included, leading to remote code execution. An included handler must now resolve to a PHP file inside the app's own directory, and the app-id guard can no longer be bypassed by a mangled spelling such as a trailing space. + -Note for integrators: the appconfig endpoints now refuse to *read* a `core` `public_`/`remote_` key as well as to write one. `getValue`/`hasKey` on the legacy `core/ajax/appconfig` endpoint had no such guard at all and returned the stored handler path; `GET /settings/appconfig/core/...` refused the exact lowercase prefix already, and now refuses a mangled spelling of it too, as well as any key on `core` outside `[a-zA-Z0-9_.-]{1,64}`. Scripts which need a handler path should read it with `occ config:app:get`. Requesting a service which is not registered now answers 404 on both `public.php` and `remote.php`, and `remote.php` answers 503 for its own refusals instead of sending a malformed status line. -* Reject SVG and script content before it reaches ImageMagick bitmap previews: https://github.com/owncloud/core/pull/41827[#41827] https://github.com/owncloud/core/pull/41863[#41863] + -Bitmap previews (PDF, Font and others) sanitized SVG content before decoding it, but fell back to the original, unsanitized bytes whenever the sanitizer could not parse the input — which happened for any malformed SVG or non-XML payload, not only for genuinely broken SVG files. A crafted malformed SVG or a raw MVG script could therefore reach ImageMagick unsanitized and trigger an MSL script that reads or writes arbitrary files as the web server user. Such content is now rejected outright, and bitmap previews decode through the same hardened Imagick options the dedicated SVG preview provider already used. Media type detection from file content now always reports a media type; it previously passed an unusable value on to its caller when the magic database behind it could not be loaded, which left the new check with nothing to test the content against. -* Pin the Imagick coder for each preview provider: https://github.com/owncloud/core/pull/41834[#41834] https://github.com/owncloud/core/pull/41863[#41863] + -Bitmap and SVG previews decoded content with no format hint, so ImageMagick's own content sniffing — independent of the mime-type check that decides whether a preview is attempted at all — could pick a different coder than the one a provider actually serves. PostScript-looking content, which that check must allow through for the PDF and PostScript providers, could therefore still reach the Ghostscript delegate through any other bitmap provider. Each provider now pins the exact coder it expects. The pin is applied in memory and introduces no temporary file of its own. -* Update PHP dependencies to close published advisories: https://github.com/owncloud/core/pull/41784[#41784] + -The 10.16 branch had not seen a dependency update since 10.16.4 and several bundled packages were carrying published advisories. This closes sixteen of them: CVE-2026-69246, CVE-2026-69245, CVE-2026-67354, CVE-2026-67355, CVE-2026-67353, CVE-2026-67339, CVE-2026-59883, CVE-2026-55767 and CVE-2026-55568 in guzzlehttp/guzzle; CVE-2026-59882, CVE-2026-55766, CVE-2026-48998 and CVE-2026-49214 in guzzlehttp/psr7; CVE-2026-55599 in phpseclib/phpseclib; CVE-2026-48784 in symfony/routing; and CVE-2026-40301 in rhukster/dom-sanitizer. + -`rhukster/dom-sanitizer` was required as `dev-main`, an unversioned branch pin. Such a pin carries no version number, so vulnerability scanners cannot match it against advisory ranges and silently report nothing for the package. It is now required as a tagged release, which both applies the CVE-2026-40301 fix and makes the dependency visible to scanners. + -`firebase/php-jwt` remains at 6.10.0 and is still affected by CVE-2025-45769 (low, weak encryption). The advisory is only fixed in 7.0.0, and every 7.x release requires PHP 8.0 or later, so it cannot be applied to the 10.16 line, which supports PHP 7.4. + -The following have been updated to versions that are not affected: -** guzzlehttp/guzzle (7.10.0 to 7.15.3) -** guzzlehttp/promises (2.3.0 to 2.5.2) -** guzzlehttp/psr7 (2.8.0 to 2.13.0) -** phpseclib/phpseclib (3.0.52 to 3.0.56) -** rhukster/dom-sanitizer (dev-main to 1.0.14) -** symfony/polyfill-php80 (v1.33.0 to v1.37.0) -** symfony/routing (v5.4.52 to v5.4.53) - -NOTE: The coder pinning changes which files get a thumbnail. Media types are derived from the file name extension, so a file whose extension does not match its content now falls back to a media type icon instead of being rendered: a JPEG saved as `photo.tif` is routed to the TIFF provider, pinned to the TIFF coder, and no longer previews. The affected extensions are `ai`, `bw`, `eps`, `heic`, `heif`, `int`, `inta`, `pdf`, `ps`, `psd`, `rgb`, `rgba`, `sgi`, `tif` and `tiff`. Of those providers only SGI and Heic are registered by default, so on a stock install this is visible for `bw`, `int`, `inta`, `rgb`, `rgba`, `sgi`, `heic` and `heif`; the rest need their provider enabled in `enabledPreviewProviders`. The font extensions `otf`, `pfb` and `ttf` behave differently — the font coder accepts any bytes, so a mismatched file still produces a thumbnail, just one drawn by the font coder rather than reflecting the file's real content, and real `.otf` files gain previews they did not have before. - -[discrete] -=== Changes - -* Update PHP dependencies: https://github.com/owncloud/core/pull/41787[#41787] https://github.com/owncloud/core/pull/41788[#41788] https://github.com/owncloud/core/pull/41793[#41793] https://github.com/owncloud/core/pull/41810[#41810] https://github.com/owncloud/core/pull/41830[#41830] https://github.com/owncloud/core/pull/41843[#41843] + -The following have been updated: -** deepdiver/zipstreamer (2.0.3 to 3.0.1) -** dg/composer-cleaner (v2.2.1 to v2.2.2) -** guzzlehttp/guzzle (7.15.3 to 7.15.5) -** guzzlehttp/promises (2.5.2 to 2.5.3) -** guzzlehttp/psr7 (2.13.0 to 2.13.1) -** monolog/monolog (2.11.0 to 2.11.1) -** nikic/php-parser (v5.7.0 to v5.9.0) -** pear/archive_tar (1.6.0 to 1.6.1) -** phpseclib/phpseclib (3.0.56 to 3.0.57) -** pimple/pimple (v3.6.1 to v3.6.2) -** punic/punic (3.8.1 to 3.8.2) -** rhukster/dom-sanitizer (1.0.14 to 1.0.17) -** sabre/dav (4.7.0 to 4.7.1) -** sabre/event (5.1.7 to 5.1.9) -** sabre/vobject (4.5.8 to 4.6.1) - -[discrete] -=== Notable Bugfixes - -* Restrict federated address book sync to the trusted server: https://github.com/owncloud/core/pull/41869[#41869] https://github.com/owncloud/core/pull/41870[#41870] + -The federated system address book sync could request resources that do not belong to the trusted server it was syncing with, and could follow redirects away from that server. Requests which would leave the trusted server are now refused, and resource references which do not belong to it are skipped and logged. -* Show federated users in the share dialog when local users also match: https://github.com/owncloud/core/pull/41814[#41814] + -The share dialog only offered federated users when the search returned no local users and no local groups, so a single local match hid every federated result, including exact federated cloud id matches. The server-generated suggestion that made this filtering necessary — any search term containing an `@` was offered as a federated cloud id, even when it was the email address of an existing local account — is now skipped whenever the search matched a local user or group exactly. -* Restore index usage for filecache writes on Oracle: https://github.com/owncloud/core/pull/41783[#41783] + -On Oracle every compare column of an upsert was wrapped in `to_char()`. That cast is only needed for text and binary columns, and `to_char(column)` cannot use an index on that column — so file cache writes, which compare `storage` and `path_hash`, could no longer use the unique index `fs_storage_path_hash` and uploads, renames and file scans became very slow on large installations. Only text and binary compare columns are cast now. -* Speed up Oracle schema introspection: https://github.com/owncloud/core/pull/41815[#41815] https://github.com/owncloud/core/pull/41819[#41819] + -Installing and upgrading on Oracle took an unreasonably long time: a fresh `occ maintenance:install` needed over 40 minutes. The bundled doctrine/dbal 2.13 describes a schema one table at a time — four queries per table, each inlining the table name as a literal, so Oracle hard parses every one of them — and the migration code asks for the full schema once per applied migration. Oracle schema introspection now reads the whole data dictionary with a fixed number of queries instead: reading a 48 table schema went from 194 queries to 6, and `occ maintenance:install` on PHP 7.4 from 43 minutes to 30 seconds. The resulting schema is unchanged and is compared against the previous implementation in the test suite. doctrine/dbal does this natively from version 3.4 onwards, which is why the 11.x line was never affected; upgrading it on the 10.16 branch is not an option, because its 3.x line changes public API that third-party apps use. -* Avoid a deprecation notice when hashing the file cache path on Oracle: https://github.com/owncloud/core/pull/41808[#41808] https://github.com/owncloud/core/pull/41815[#41815] + -Oracle cannot store empty strings, so the file cache converts them to null before writing a row. For the storage root, whose path is the empty string, that left `md5()` being called with null. The deprecation is PHP 8.1's, for passing null to a non-nullable internal parameter, so PHP 7.4 — the only version this release line supports — is silent and an ownCloud 10.16 installation sees no symptom. It was found on the 11.x line, whose test suite runs PHP 8.3 and turns the notice into an error. The stored `path_hash` was never wrong either way, because `md5(null)` coerces to `md5('')`; the value is now cast to a string before hashing. -* Release the file handle when a bitmap preview cannot be decoded: https://github.com/owncloud/core/pull/41835[#41835] https://github.com/owncloud/core/pull/41837[#41837] + -Bitmap previews closed the file they had opened only when decoding succeeded, so every file that could not be decoded leaked a file handle for the lifetime of the process. Generating previews for a directory of files ImageMagick has no decoder for could therefore exhaust the available file handles. A file that cannot be opened at all is now reported as having no preview right away, instead of travelling on until ImageMagick rejects the empty content and an unrelated warning plus a misleading decoder error have been logged. -* Report a preview file that cannot be opened without logging noise: https://github.com/owncloud/core/pull/41855[#41855] https://github.com/owncloud/core/pull/41863[#41863] + -Generating an SVG preview read the file without checking that it had been opened. A file the storage could not open, or one whose name the filesystem rejects, still fell back to a media type icon, but only after warning about the read and then logging ImageMagick's complaint about content it had never received. The bitmap providers shared that gap for one of the two values an unsuccessful open can return. The SVG provider also held the file handle and its lock until the request ended when the file opened but then failed to be read, an encrypted file with a missing or damaged key for instance. +IMPORTANT: This is a security release. Upgrading is strongly recommended for all installations. == Changes in 10.16.4