Patching Collabora Online from security advisories

Why patching Collabora Online from security advisories needs a fixed process

A fixed patching process is what keeps a Collabora Online server that handles sensitive documents on a supported minor release. Collabora Online is usually embedded in Nextcloud or another WOPI host, so every document a user opens passes through the server, and a security flaw in that server affects every file your users edit. Collabora publishes security fixes in point releases on its existing branches rather than in new major versions, which means the work is not a one-off upgrade but a recurring duty tied to a branch you have already chosen.

The 25.04 branch shows how this plays out. According to the Collabora Online 25.04 release notes, release 25.04.7.5 on January 29, 2026 fixed CVE-2026-23623, and the same notes record that package signing keys were updated for RPM and DEB users. The first change is a vulnerability fix you have to deploy. The second is an operational task: if your package manager trusts an old key, the update path can break or, worse, you may start trusting packages you have not verified. The branch also kept receiving point releases into 2026, with 25.04.13 released on September 21, 2026, so staying on a branch is viable only if someone is tracking those releases and applying them.

Your process therefore needs three fixed elements: a named owner who watches for advisories, a target window for applying minor releases on each branch you run, and a check that signing keys and package sources still match what Collabora publishes. Confirm with Collabora how advisories reach customers and which channel carries signed security updates for your plan, and record the answers in your runbook before an advisory arrives. The Collabora Online 25.04 release notes are a good baseline for what a typical advisory and key change looks like.

Applying a minor release: the patch workflow

This sequence takes a Collabora Online minor release from advisory to production without cutting off people who are mid-edit. Each step ends with a check you can record, so the result is a verified upgrade rather than an assumed one.

Inventory every running Collabora Online version
Before anything else, list each Collabora Online instance and its exact version. On Linux package installs, query the installed package version on every host that runs the server. In Kubernetes, read the image tag of every running pod, not only the Helm release values, because a pod can lag behind a chart change. Include CODE instances and any test or staging servers that Nextcloud or another WOPI host still points at. The step is done when you have one table with host or pod, version, and the WOPI host it serves, and no instance is unaccounted for.
Read the release notes for the target minor
Open the release notes for the minor branch you are moving to and find the entries that name a CVE, a security fix or a change to package signing keys. Note any configuration change, removed option or changed default, and check whether your current branch is still receiving point releases. For the 25.04 branch, the release notes record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623 and updated the RPM and DEB signing keys, so a key import step may be needed on package hosts. The step is done when you have a written list of required actions per instance.
Verify signed packages before installing
Before you install, confirm the package signing key you trust matches the key described in the release notes. Import the updated key if the release notes call for it, then check the package signature with your package manager's verification tool. Keep the verification output with the change record. If the signature does not verify, stop and contact Collabora through your support channel. The step is done when every package you plan to install verifies against the expected key.
Test the new version in staging with real documents
Deploy the target version to a staging instance connected to a non-production WOPI host, ideally a copy of your Nextcloud or other host configuration. Open a representative set of documents you actually use, covering the formats your organization relies on, and edit, save, and export each one. Confirm that the WOPI allow list, TLS settings and any proof key configuration still behave as before. Check the admin console and logs for new warnings. The step is done when the test set opens, saves and exports without errors and your sign-off notes list any differences in rendering.
Roll out with WOPISrc-aware routing
Upgrade instances one at a time or in small groups, so the rest of the fleet keeps serving sessions. In a multi-server or Kubernetes setup, make sure your load balancer still routes by the WOPISrc parameter, so everyone editing one document stays on the same server while you work. Drain or wait out active sessions on an instance before restarting it where your tooling allows, and confirm the Helm chart replica settings are not changed by the rollout. The Helm chart README states that horizontal pod autoscaling is disabled and replicas are set manually, so review any automation that could change them. The step is done when each instance runs the target version and no session was dropped without a recorded decision.
Verify health checks and WOPI connectivity
After each instance restarts, confirm that its health endpoint responds and that the server is reachable from the WOPI host through the same protocol and URL that users use. Open a document from the production host, edit it, and save it. Check that the server accepts requests only from the expected WOPI hosts. Review logs for errors in the first few minutes of traffic. The step is done when a live document opens, saves and closes on every upgraded instance, and the health checks report healthy.
Record the result and close the advisory
Write a change record that lists each instance, the old and new versions, the advisory or CVE addressed, the signature verification result, the staging test set, and the production checks. Store it where your audit and incident teams can find it. Note any instance you have deliberately left on an older version, with the reason and the owner responsible for it. The step is done when every instance in the inventory has a recorded final version and the advisory is marked as addressed in your tracking system.

Which update path fits which deployment

This table compares CODE, a Business subscription and an Enterprise arrangement on the things that matter when a security advisory lands: whether signed security updates and long term support are included, and whether the option suits production. Read each row against your own patch window and assessor expectations, then confirm the current terms in writing before you commit.

Patch factor	CODE (free edition)	Business and Enterprise
Intended use	Testing, home use or small teams. Collabora does not recommend it for production.	Production use, with the commercial terms set out on the pricing page.
Release cadence	Rolling release, on average about once a month.	Supported branches with point releases, such as the 25.04 branch that was still receiving point releases in 2026.
Signed security updates	Not part of the free edition terms. Confirm with Collabora before relying on it.	Business plan includes signed security updates, according to the pricing page.
Long term support	Not included. Plan for frequent version moves.	Business plan includes long term support, according to the pricing page.
Service level agreement	Not included.	Business plan includes an SLA, according to the pricing page. Ask for the written terms.
Customer portal access	Not included.	Business plan includes customer portal access, according to the pricing page.
Pricing basis	No fee.	Business plan is 3 euros per user per month for up to 99 users, per the pricing page. Enterprise, for 100 or more users, is quoted with volume discounts.
Fit for production patching	Weak fit. Frequent version changes add risk and the image is not offered as a production edition.	Strong fit when you need a signed, supported update stream and a documented patch commitment.

Verifying signed packages and rotating signing keys

Package signing keys can change, and the 25.04 release notes show why you need a process for it. The notes record that, alongside the 25.04.7.5 security release on January 29, 2026, Collabora updated the package signing keys for RPM and DEB users. If your repository trust was set up once and never revisited, a key change can make updates fail to verify, or worse, tempt an operator to disable signature checks to get past the error. Treat a signing key change as a security event in its own right: it should be announced, confirmed and applied deliberately, not worked around.

Import the current key only from a source Collabora documents for your installation method, and confirm the fingerprint against Collabora's published values before you trust it. Do not copy a fingerprint from a forum post, a blog or a configuration file in an old runbook. Ask Collabora to confirm the exact repository locations, key URLs and fingerprints for your distribution and package format, then record them in your change log. Before each installation, verify package signatures with the native tools for your format (rpm -K for RPM packages, and apt's signed-repository checks for DEB repositories), and make the verification step a required gate in your deployment pipeline rather than an optional manual check.

When Collabora announces a rotation, update the trust store in a planned window. Import the new key, confirm its fingerprint against the value Collabora provides, and remove the old key only after you have confirmed that the new one verifies the current packages. Keep the old key in place until your mirrors, internal repositories and golden images all carry the new trust. Test the change on a staging host first, and confirm that your offline or air-gapped mirror process can carry the new key, since a stale mirror is a common reason an update stops at a restricted network boundary.

Why CODE does not belong in production

CODE is a free, rolling edition, and Collabora positions it for testing, home use or small teams. The cards below set out what that means for a team that has to track advisories, hold a tested baseline and answer to auditors for the versions it runs.

Rolling release cadence

CODE is released on average once a month as a rolling release. Each drop can carry changes to the server, the bundled components and the defaults. Your team therefore never has a fixed version to test against for long. Before you deploy anything to CODE, confirm which build you are running and record it, so you can tell whether an advisory applies to your exact version.

Not recommended for production

Collabora describes CODE as suited to testing, home use or small teams, and does not recommend it for production. That is the vendor's own statement about intended use. If your Nextcloud or other WOPI host serves real users and real documents, treat CODE as a staging or lab instance and plan a supported production build instead.

No signed security update commitment

The Business plan includes long term support, a service level agreement, signed security updates and customer portal access. CODE does not carry those commitments. When an advisory lands, a CODE user has no contracted path to a signed fix for their build. Ask any provider you evaluate to show, in writing, which patch channel and signing keys apply to the version you run.

No customer portal access

The paid plans include customer portal access, which is where a subscriber gets supported builds and related support material. CODE users do not get that portal. Without it, you depend on public release notes and your own monitoring to learn that a fix exists. Assign a named owner to read advisories and release notes on a fixed schedule, since no portal will prompt them.

Hard to hold a tested baseline

A monthly rolling build changes behavior faster than most change processes can review it. Document rendering, WOPI handling and admin settings can shift between drops, so a configuration you validated last month may not hold. A production baseline needs one fixed version, a staged test of each minor update and a rollback plan, which a rolling edition does not give you.

Patching Collabora Online: questions buyers ask before hiring help

How much effort does a Collabora Online patch cycle take?

The effort depends on the deployment shape and how much verification you need before each change reaches production. No effort figure is supplied for this work, so ask any partner to estimate it from your environment. The main drivers are the number of Collabora Online instances, whether they run from Docker or Kubernetes images or from system packages, how many Nextcloud or other WOPI host integrations depend on each server, and how much test coverage you already have.

Instance count and topology, including any load-balanced pods that must keep WOPISrc routing intact
Package channel: system packages, Docker images or Helm releases each follow a different rollout path
Document fidelity checks for the formats your users rely on most
Change windows and rollback steps agreed with the business owners

Ask for the estimate broken into these parts so you can see which ones you can reduce yourself.

Can our own team patch Collabora Online in-house?

Yes, many teams do, provided they have someone who watches the security advisories, a staging copy of the production setup, and a documented rollback. Collabora publishes security advisories and a security newsletter, and its Business plan includes signed security updates and customer portal access, according to the Collabora Online pricing page. Your team needs to subscribe to those channels and read them promptly. Running CODE in production is not a substitute, because Collabora describes CODE as not recommended for production. The in-house question usually turns on staffing: whether one or two engineers can absorb monthly updates alongside their other duties, and who covers the work when they are unavailable.

What does a fixed-scope patch retainer cover?

A fixed-scope retainer covers the work named in a written scope before it starts: which Collabora Online instances are included, which advisories and minor releases are in scope, how staging tests are run, who performs the change, and what evidence is returned. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms inside your own infrastructure, and ongoing support and upgrades are available as retainers. Ask the quote to list each instance, each target release channel, the test cases used for document fidelity, the rollback procedure, and what happens when an advisory lands outside the agreed window. Confirm whether major branch moves, such as between 25.04 and 26.04, are included or priced separately.

How quickly should a Collabora Online security fix be applied?

Apply a security fix on the timeline your risk owner sets, after testing it on a staging copy. Collabora's 25.04 release notes show that the 25.04.7.5 point release, dated January 29, 2026, fixed CVE-2026-23623, and that package signing keys were updated for RPM and DEB users. That is a useful example of why key rotations need to be handled alongside the update itself. Regarding service levels, the Business plan is described as including a service level agreement, but the terms are not supplied here. Ask Collabora for the SLA text and its response commitments, and ask any partner to state in writing the time from advisory to deployment that it commits to.

Which SLA terms should we confirm before signing?

Confirm the exact SLA terms in writing rather than assuming them from marketing. For vendor support, check the response times, the severity definitions, the scope of covered versions, and whether signed security updates are included at your plan level. For a services partner, check the commitment to response, the change window used for emergency patches, the coverage hours, and what is excluded, such as custom modules or integrations. Keep in mind that a vendor SLA covers the vendor's support, and a partner's commitment covers the work on your systems. Neither removes the need for your own change approval.

What do we need to provide for patching work?

Plan to provide access, a staging environment and change windows before work begins. Access means accounts on the Collabora Online hosts, the Kubernetes cluster or package repositories, and the WOPI host such as Nextcloud, along with the reverse proxy configuration. Staging should mirror production closely enough to test real WOPI sessions, document opening and saving, and the formats your users work with. Change windows need named approvers and an agreed rollback plan. Also provide the list of document formats in use, since Collabora supports OpenDocument and Microsoft formats including docx, xlsx and pptx, plus PDF, RTF, CSV and Visio files, according to the product page.

Why does patching Kubernetes deployments differ from package installs?

Kubernetes deployments need replica planning and routing checks that package installs do not. The official Helm chart README says horizontal pod autoscaling is disabled because scaling breaks collaborative editing and copy and paste, so replicas are set manually, and load balancers must route by the WOPISrc parameter so users editing one document reach the same pod. A rolling update must therefore keep that routing intact and avoid moving active sessions unexpectedly. Package installs on a single server are simpler to roll back but still need service restarts and signed package verification. Ask any partner how it handles drain, restart and session behavior for each topology.

Which signals show a patch needs more testing before rollout?

A patch needs more testing when it touches the components that handle documents, WOPI traffic or signing. Watch for release notes that mention file format handling, WOPI or authentication changes, or key updates, as well as any change to package signing keys. The 25.04 release notes illustrate this, since the signing keys for RPM and DEB users were updated alongside a security fix. Check that your package manager trusts the new keys before rollout and that your repository configuration is current. Any failed open, save or conversion in staging is a reason to hold the rollout and investigate.

Limits to confirm in your environment

Security advisories tell you what changed, but several details that decide whether a patch is safe to apply in your environment are not settled by the advisory alone. The cards below list the items to confirm with Collabora, your Nextcloud or WOPI host vendor, and your own change process before you set a patch window.

Fix status for your branch

Confirm that the minor release you plan to deploy fixes the specific CVE you are tracking in the branch you run. Advisories name the fixed release, but a fix shipped in one branch may not be backported to another, so check the release notes for the exact branch. For example, the 25.04 release notes record that 25.04.7.5 fixed CVE-2026-23623. Ask Collabora which of your installed branches carry the same fix before you assume coverage.

Advisory and newsletter channels

Confirm the exact channels Collabora uses for security notices, including the security newsletter, release notes and the customer portal if your plan includes it. Subscribe the people who own patching, not a shared inbox that nobody reads. Record which channel is authoritative, because a forum post or social announcement may come before the formal advisory text.

Package signing keys and repositories

Confirm the current signing key fingerprints and repository paths for the RPM and DEB packages you install before you import anything new. The 25.04 release notes record that signing keys were updated for these package types, so a key change is a normal event that must be verified, not accepted blindly. Compare fingerprints against the vendor's published values through a second channel and write the check into your change procedure.

Compatibility with your WOPI host

Confirm that a new Collabora minor release works with your Nextcloud or other WOPI host version, including the Nextcloud Office app version it expects. Test document opening, saving, and the WOPI allow list settings on a staging copy before production. Check whether the host requires a matching protocol and URL scheme, since a change in the server can surface a mismatch that did not exist before.

Behavior of open sessions on restart

Confirm what happens to users with documents open when the service restarts for a patch. Ask whether editing sessions are dropped, whether unsaved changes can be lost, and how long users need to reconnect. Also confirm how your load balancer handles pods that restart, since routing by WOPISrc means all editors of one document depend on the same instance. Schedule restarts with that in mind.

Support covered by your plan

Confirm which support terms your subscription includes, such as signed security updates, long term support, a service level agreement and customer portal access, and whether they apply to the branch you run. Community builds such as CODE are not meant for production, so confirm the status of any build before it goes live. Ask in writing what response you can expect if a patch fails.

Where to read the release notes and advisories

The Collabora Online release notes are the first place to check for security fixes, and they are where advisories are recorded alongside each point release. Start there when you plan a patch window, and make it a standing task to review the page for every branch you run in production. The 25.04 release notes show the pattern to expect: they record that 25.04.7.5, released January 29, 2026, fixed CVE-2026-23623, and they also state that package signing keys were updated for RPM and DEB users. A key update is an operational event, not just a note, so your package manager configuration and any internal mirror need to accept the new keys before the next update runs.

Read the *Collabora Online 25.04 release notes* when you are on that branch, because they give the most complete record of point releases and fixes for it. The branch itself is still receiving point releases, with 25.04.13 released on September 21, 2026, so confirm the current point release on the release notes page before you schedule work. Record the CVE identifiers and the signing key changes in your change tickets, so auditors and your own security team can trace which build closed which issue and when your environment picked it up.

For branch-level changes, read the COOL 26.04 is here forum post. It was announced on July 23, 2026, and describes a new branch with an optional AI assistant that is off by default. A new branch is not a patch for your current branch, so decide deliberately whether to stay on your current line, move to a newer branch, or move to a supported subscription. Ask Collabora directly which branch receives security fixes for your edition, and how long it will be supported, before you commit a roadmap to it.

How DeployOpen scopes and supports Collabora Online patching

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For Collabora Online patching, we start from your advisory tracking and release process, then agree the work in writing before any change reaches your servers.

How we scope

Inventory every Collabora Online server, its package source, version and whether it runs CODE or a supported edition.
Agree in writing which branches you will follow, who reviews advisories, and the target window for minor release updates.
Confirm how signing keys for RPM and DEB packages are verified and who rotates them when Collabora publishes changes.

How we build

Set up a staging environment that matches production routing, WOPI hosts and TLS so each minor release is tested first.
Script the update path for your chosen install method, including package pinning, service restarts and rollback steps.
Test document editing end to end after each update, covering the formats your users depend on before production changes.

How we hand over

Document the advisory watch routine, roles, approval steps and the release calendar your team will run after handover.
Provide a runbook for applying minor releases, verifying signatures and confirming the running version on every node.
Record a rollback procedure and a dated change log so auditors and security teams can trace each applied fix.

How we support

Offer ongoing patch application, testing and advisory review as a retainer, scoped to your environment and release cadence.
Agree response expectations for new advisories in the retainer terms rather than assuming them, and confirm them with us in writing.
Review each branch change, such as moving from 25.04 to a later branch, as a separate fixed-scope piece of work.