CVE status and security fixes #

Maintained by BW-Tech GmbH. As of October 28, 2026, owncloud.online 11.0.25.

The tables list the vulnerabilities with a CVE ID that owncloud.online has fixed, and the version that first contains each fix. They serve as evidence in security reviews and explain why scanners still flag some of the bundled libraries. Security fixes without a CVE ID are listed in the CHANGELOG under "Security".

Code base #

The code base contains all security fixes of the upstream project up to February 17, 2026. Later fixes from upstream are reviewed regularly and backported one by one. In the Git history, the commit message names the origin ("cherry picked from commit …"). The backported fixes are listed under Backported fixes in the code.

composer audit --locked reports no vulnerabilities for the PHP dependencies of 11.0.25 (checked on October 28, 2026, for the core and the oco_mcp and market apps). The same check runs in CI for every code change on the main branch and in every pull request, and stops the build if it finds anything.

PHP dependencies #

"—" means that no severity is given. 11.0.25 ships guzzle 7.15.2, psr7 2.13.0, phpseclib 3.0.57, symfony/routing 7.4.13, symfony/mime 8.0.15, and symfony/mailer 7.4.15.

PHP itself #

CVE-2026-109618 and CVE-2026-109619 affect the PHP interpreter, not the owncloud.online code. They let attackers run code on the server without logging in. For PHP 8.4, they are fixed in 8.4.27 and later. Since 11.0.24, owncloud.online reports an affected PHP version in the setup warnings, see Security and setup warnings. Install the update itself through your system's package manager.

Backported fixes in the code #

These fixes come from the upstream project. Most of them close security holes; some fix operational bugs.

Login form #

The form derived the password reset link from canChangePassword(). Whether the link appeared therefore revealed whether an account existed. This part of the fix is backported; the link now appears the same way for every login attempt.

The second part of the upstream fix was deliberately left out. It resolves the login name through userManager->get()->getUserName(). Because AccountMapper::getByUid() searches case-insensitively, the form would return the canonical spelling for existing accounts and the raw input for unknown ones (?user=fRANK gives frank or fRANK). That would be a new, cheaper way to guess accounts: a single GET request without a login that brute-force protection does not cover.

Search result excerpts #

FilesSearchReportPlugin returned the WebDAV property search-highlights unchanged from the search result. The excerpt is built from the file content and deliberately carries markup (line breaks become <br/>). A client that renders it as HTML therefore executed injected markup: stored XSS through shared file content.

The server now encodes the excerpt first with htmlspecialchars(..., ENT_QUOTES, 'UTF-8') and only then replaces the line breaks, so the intended <br/> survives. The order matters. The path only becomes active with a search provider that returns excerpts. owncloud.online does not ship one, but the vulnerable code was present. Regression test: FilesSearchReportPluginTest::testOnReportEncodesHighlights.

Frontend libraries #

The frontend libraries are committed to the repository under core/vendor, including the fixes, and shipped exactly as committed. The fixes therefore persist across updates.

The version numbers stay the same. Scanners that judge by version number will therefore keep reporting the CVEs, even though the holes are closed.

jQuery UI #

The three vulnerabilities from 2021 concern options of the datepicker and the position utility. The shipped code sets none of them: the datepicker is called only with format and date range options, and the position utility not at all. That did not apply to third-party extensions, which was the remaining risk. The fixes from jQuery UI 1.13.0 are therefore backported:

• CVE-2021-41182 (altField) and CVE-2021-41184 (position({of})): Both options are meant as selectors. $(x), however, interprets a string that starts with < as markup and builds elements from it. Both places now go through $(document).find(x), which always treats a string as a selector, word for word as in 1.13.0. A string that is not a valid selector now throws an error instead of silently building an element. 1.13 behaves the same way.
• CVE-2021-41183 (text options of the datepicker): The datepicker builds its markup as a string and inserted prevText, nextText, currentText, closeText, weekHeader, appendText, buttonText, the day and month names, the year suffix, and the return value of calculateWeek raw. All of them are now escaped, including the single quote. The templates write their attributes in single quotes (title='…'), so escaping double quotes alone would not be enough.

The bundled jQuery UI language files write prevText as <Zurück, with an HTML entity. After escaping, the entity would appear literally. That is not a problem here, because these files are never loaded (core/js/core.json lists only jquery-ui.custom.min.js). Month and day names come from the owncloud.online translation and are plain text.

Moving to jQuery UI 1.13 is not backward compatible: button and buttonset are dropped there in favor of controlgroup, and tabs changes. The library therefore keeps the version number 1.10.0.

Select2 #

Select2 inserted the return value of formatResult and formatSelection raw into the result list (select2.js:1123, :2650, :3254), whether or not escapeMarkup was turned off. What mattered was what the formatters returned.

The hole is closed where the markup is inserted, with the same rule that Select2 applies from 4.0.6 on: where all options come together (prepareOpts), a formatter passed in by the caller is wrapped. If it returns a DOM element or a jQuery object, that passes through unchanged. Code that builds its markup through the DOM has already set the external data as text. If it returns a string, the string is escaped. The built-in formatters are left alone; they escape on their own and need their highlighting as markup. This also protects third-party extensions.

The six formatters in the code base (systemtagsfilelist.js, systemtagsinputfield.js, settings/js/settings.js, files_external/js/settings.js) now return jQuery objects instead of HTML strings. That is also the only form in which Select2 4.x still accepts markup. The three escapeMarkup: m => m overrides are no longer needed and have been removed.

Moving to Select2 4.x changes the API in several places (templateResult, ajax.processResults, initSelection, .select2('val')). The library therefore keeps the version number 3.5.4.

Browser test #

make test-js-browser tests both fixes in a real Chromium, each against the normal and the minified version of the library (tests/js/jquery_ui_xss_test.js with 56 checks, tests/js/select2_xss_test.js with 26 checks). A datepicker whose text options are set to <img src=x onerror=…>, and a tag with that name, appear as text. No element is created, and nothing runs. altField and position({of}) with the same string are rejected. In the cross-check against the unmodified library, the injected code actually runs (window.__xss === 1).

The tests also check that the libraries otherwise work unchanged: for jQuery UI, the datepicker with custom month and day names, position with a selector, and tabs, button, buttonset, progressbar, autocomplete, draggable, and droppable, the widgets the product actually uses.

Note for developers #

If you build from source: make clean-nodejs-deps (and therefore make clean) deletes core/vendor. A rebuild through yarn afterwards fetches the libraries without these fixes. The make target warns about this. Restore core/vendor from the repository instead.

Checking it yourself #

You can check the dependencies of a release against the known security advisories with Composer. composer.json and composer.lock are not part of the release package, but they are in the repository under the version tag:

mkdir /tmp/oco-audit && cd /tmp/oco-audit
curl -fLO https://raw.githubusercontent.com/BWTECH-github/owncloud.online/v11.0.25/composer.json
curl -fLO https://raw.githubusercontent.com/BWTECH-github/owncloud.online/v11.0.25/composer.lock
composer audit --locked

The expected output is "No security vulnerability advisories found." The same works for the oco_mcp app with the files under apps/oco_mcp/. The versions actually installed on an instance are listed in lib/composer/composer/installed.json.