How to apply Ceph point releases and security fixes safely
Before you schedule anything, confirm that your cluster's release still receives fixes. Ceph applies security updates only to its current active releases, so a cluster on an unsupported release cannot take the fix by itself. Check the release your cluster runs against the Ceph releases page, which lists the actively maintained releases and their estimated end-of-life dates. If your release is no longer listed, the first task is a major upgrade to a supported release, and only then can you apply the fixes that matter. Security reports for Ceph go to security@ceph.io rather than the public tracker, so an advisory may reach your team through the Ceph security page or the release notes before a detailed public write-up exists. Treat a new point release as the vehicle for the fix, not as an announcement to read later.
Keep two kinds of change apart in your planning. A point release stays within your current major release, for example a later 19.2.x build of Squid, and carries backported bug and security fixes without changing the major version. A major upgrade moves the cluster to a new major release, changes defaults and often requires a sequence of checks, and needs its own change window and rollback thinking. The supported path is to stay on a release that is still in active maintenance, apply point releases to it as they arrive, and plan a major upgrade before the estimated end of life of your current release. For example, a cluster on Squid should expect to move to Tentacle before Squid's estimated end-of-life date, which the Ceph releases page lists as October 31, 2026, and should confirm that date on the page when it plans its window.
When a point release names CVE-level fixes, read its release notes for the affected components, such as authentication, the Object Gateway or the Dashboard, and for any required manual steps. For example, the Squid 19.2.6 release notes included fixes for authentication bypass and privilege escalation issues, which is the kind of entry that should move a patch up your queue. Confirm the exact fixes and any upgrade caveats in the Squid release notes for your release line before you act. Record the version you start from and the version you target, so the change record shows exactly which fixes were applied and when.
Which Ceph releases still receive backports and security fixes
Only releases on the active maintenance list receive periodic backports and security fixes, so the release you run decides how fast a patch reaches you. The cards below cover the two active releases, what to do with anything else, and where vulnerabilities are reported. Check each end of life date against your own change calendar before you plan the next window.
Tentacle (20.2.x)
Tentacle is the newer of the two actively maintained releases. It was first released November 18, 2025, and the latest point release at the time of writing is 20.2.4. Its estimated end of life is June 1, 2027. Clusters on Tentacle receive the backports and security fixes that the project ships in later 20.2.x point releases, so this is the line to target for a long-lived cluster. Confirm the current point release on the releases page before scheduling a rollout.
Squid (19.2.x)
Squid is the older active release. It was first released September 26, 2024, and the latest point release is 19.2.7. Its estimated end of life is October 31, 2026, which may fall well before your next major upgrade window. Plan the move to Tentacle now if your change calendar has a gap in the second half of 2026, and read the Squid release notes for the security fixes already shipped in its point releases.
Releases not on the active list
Any release not on the active releases page no longer receives routine backports or security fixes. Clusters on these releases carry known, patched exposure that the project will not close in place. Confirm the end of life status on the releases page for your exact version, then plan a major upgrade through the supported path. Treat the lack of a patch stream as a standing risk in your vulnerability register until the upgrade completes.
Reporting vulnerabilities to security@ceph.io
Vulnerabilities in Ceph are reported to security@ceph.io, not to the public tracker. Security updates are applied only to the current active releases, so your report and any internal finding should be routed through this channel. Keep the report private until the project has issued a fix, and record the date you received the fix in your patch log. Your team should know this address before an incident, not during one.
What a point release changes and what it asks of your team
This table compares five things a Ceph point release brings, the impact each has on a running cluster, and the action your team should take. Read it as a checklist to run for every point release on your supported branch. The main takeaway is that security fixes and daemon restarts both demand a planned window and a health baseline, even when the change looks small.
| Change | Impact | Action needed |
|---|---|---|
| Security fixes in the release notes | Squid 19.2.6 included fixes for authentication bypass and privilege escalation vulnerabilities, so an unpatched cluster stays exposed to those flaws. | Read the release notes for the target version, identify the CVE or security entries, and rank them against your exposure, such as client access and dashboard reachability. |
| Periodic backports to active releases | Only actively maintained releases receive backports and security fixes, so a cluster on an end-of-life branch stops receiving them. | Confirm your release is in the active list and note its estimated end of life, then schedule the next point release or major upgrade before that date. |
| New point releases with non-security fixes | A point release can carry bug fixes that are not security related, and these may change daemon behavior under your workload. | Review the full changelog for fixes touching your features, such as RGW, RBD or recovery, and test the target version in a non-production cluster first. |
| Daemon restarts during the rolling upgrade | cephadm restarts monitors, managers, OSDs, gateways and other daemons in sequence, so capacity and client I/O are briefly reduced on each host. | Schedule a maintenance window, confirm that enough redundancy exists to tolerate one daemon down, and confirm that clients can retry during restarts. |
| Cluster health before and after the upgrade | A cluster already in a warning state can fail to complete the upgrade cleanly, and problems may be hidden by the restarts. | Record a health baseline before starting, resolve or document any warnings, and repeat the health check after the upgrade finishes and data is back to normal. |
How to read a Ceph release note for CVE fixes
Start by scanning the release note for a security section and for entries that name vulnerability classes, affected daemons or CVE identifiers. The Squid 19.2.6 release notes are a useful model: they state that the release included fixes for authentication bypass and privilege escalation vulnerabilities. A fix entry of that kind tells you which part of the system was exposed, so map each entry to a component you run: monitors and managers, OSDs, the Ceph Object Gateway (RGW), the Dashboard or cephadm itself. Confirm first which Ceph version each host and container actually runs, because a cluster can be partly upgraded, and confirm whether the affected component is enabled at all. An RGW fix matters little if you do not run RGW, and a Dashboard fix matters less if the Dashboard is disabled or reachable only from a management network.
Then check the Ceph security page for reporting and disclosure context. It states that security updates apply to the current active releases and that vulnerabilities are reported to security@ceph.io rather than the public tracker. Use that to decide whether your version is still in the supported set. Do not assume a release note lists every CVE identifier that was addressed. Where you need a specific identifier for a scanner, a ticket or an auditor, ask the project directly through the reporting channel and record the answer with the release you applied.
Before deciding whether a patch is urgent, verify four things: the exposed component is enabled and reachable by users you do not fully trust, the vulnerable version range includes your current release, any mitigation the note describes is already in place, and whether the cluster can take a rolling upgrade on your change window. Illustrative example: a team running Squid with RGW exposed to an application network should treat an RGW-related authentication fix as a priority, while a team with no Dashboard exposure may schedule the same release in its normal maintenance window. Record each decision so the reasoning is reviewable later.
What to prepare before a point release reaches production
A point release is only as safe as the state it lands on. The cards below cover what to record, back up, rehearse and assign before the first daemon restarts, so that a failed step can be diagnosed and reversed instead of guessed at.
Confirm running versions everywhere
Before planning anything, check which Ceph version each daemon is actually running, not only the version the orchestrator reports as its target. Mixed versions left over from an earlier partial upgrade are common and change the order and risk of the next step. Record monitors, managers, OSDs, metadata servers, RGW and any gateway or NFS daemons, and note hosts that are offline or in maintenance. Confirm with your own environment's inventory tooling and cephadm's status output, and use the cephadm documentation for the commands on your version.
Read the target release notes closely
Read the release notes for the exact point release you plan to apply, not only the headline line. Look for fixes that affect your features, known issues, required pre-checks, and any change to defaults or upgrade ordering. For security content, note which vulnerabilities are fixed and whether they affect the authentication, dashboard or gateway components you run. Ceph security fixes are applied to the current active releases only, so confirm your cluster's release is still within its supported window.
Record baseline cluster health
Capture the cluster state before any change: the health status and every active warning, the count of degraded or undersized placement groups, and any inconsistent objects. Review the recent deep scrub results, because a scrub error found during an upgrade is hard to separate from one the upgrade caused. Store this baseline with a timestamp. A cluster that is already degraded should usually be stabilized first, and the team should decide in writing whether the window proceeds in that state.
Back up configuration and unrecreatable data
Export the cluster configuration, the cephadm service specifications and the host inventory, and store them outside the cluster. Identify any data the team cannot rebuild from source systems, such as recent object metadata, keys or application databases on RBD volumes, and confirm those backups exist and restore in a test. Verify the copies by reading them back, not only by checking that a file was written. Ask your storage team to confirm the exact export commands and the restore procedure for your Ceph release.
Rehearse in a mirrored test cluster
Stage the target image in a test cluster that matches production in release, daemon layout, host count, network design and client types. Run the same upgrade sequence, then exercise the workloads that matter, such as RBD attach, RGW requests and dashboard login. Confirm that every production host can pull the target image from the registry it will use. A test cluster far smaller than production can miss placement, capacity and timing problems, so record which differences remain and accept them explicitly.
Assign approval and rollback ownership
Name one person who approves the maintenance window, one who runs the upgrade, and one who decides to stop or roll back. Write down the stop conditions, such as health warnings that do not clear or client errors above an agreed threshold, and who may invoke them. Agree who communicates with application owners and security contacts. Rollback for a point release is not always a simple reversal, so confirm with your Ceph support channel which steps are reversible on your version before the window opens.
How to roll a Ceph point release through a cephadm cluster
This sequence moves a cephadm-managed Ceph cluster from one point release to a newer one in the same major series, with health checks, rollback points and tests at each stage. The output is a cluster running the target release with health confirmed after every stage and a record of what changed.
Confirm health and set the maintenance window
Before touching anything, the operator confirms the cluster reports a healthy status, with no degraded or misplaced data, no OSDs down and no unresolved warnings from earlier work. Record the current version of every daemon, capture the cluster status and any open health warnings, and confirm recent backups of critical pools and configuration exist and have been tested. Agree the maintenance window with application owners and the people who handle client tests. Done when the baseline is written down and the owners have accepted the window in writing.
Stage and verify the target image
Confirm the target point release is listed for your current major series on the Ceph release notes, and read its notes for fixes that affect your workloads, including any CVE fixes and any new upgrade prerequisites. Make sure every host can pull the target container image from your registry, or from a local mirror if the network is restricted. Check the image tag and digest match what you intend to deploy. Rollback point: nothing has changed yet, so stopping here is free. Done when every host pulls the image and the release notes have been reviewed by the operator and the application owner.
Start the cephadm upgrade to the target version
Start the upgrade with the cephadm orchestrator commands under the ceph orch upgrade family, pointing at the target version, and confirm the status command reports the upgrade in progress. Cephadm then manages the order of daemon restarts. Rollback point: a cephadm upgrade is not a simple downgrade, so before starting, record the previous image and the backup set you would restore from. Done when the orchestrator reports the upgrade has started and the target version is recorded as the intended state.
Watch the staggered daemon upgrade
Follow the upgrade through its stages: monitors, managers, OSDs, metadata servers and gateways. Cephadm restarts daemons in a sequence so that quorum and data availability are kept, but the operator should watch progress and the cluster log, not assume it. Run client tests and monitoring throughout, including block I/O from a test VM, object reads and writes through the gateway and any file mounts. Stop and call your vendor or partner if a monitor fails to rejoin quorum, the upgrade stalls on one daemon, or client errors rise. Done when the orchestrator reports the upgrade complete and every daemon reports the target version.
Check health after each stage
After each stage completes, confirm the cluster returns to a healthy status before the next stage is allowed to proceed. Check monitor quorum, manager failover state, OSD up and in counts, placement group states, and that recovery or backfill activity has finished or is progressing as expected. Record the health output at each checkpoint. Rollback point: before any stage that changes OSD or data state, confirm that rolling back is not possible with the orchestrator alone, so the decision to continue must rest on the health evidence. Done when each checkpoint is recorded and no new health warnings remain unexplained.
Run post-upgrade tests and close the change
Once every daemon runs the target release, run the post-upgrade test plan: confirm the reported version on all daemons, run a scrub on a sample of placement groups, test a block write and read from a client host, test object upload and download through the gateway, and check authentication for the dashboard and any single sign-on integration. Review monitoring for new alerts. Document the final versions, health output and test results, and confirm the owners accept the change. Done when the tests pass, the record is filed and any residual warnings have a named owner and a follow-up date.
How timing changes for scheduled, urgent and air-gapped patches
A scheduled point release is the normal case. The timing is set by your change calendar, your maintenance windows and the cadence at which the project publishes backports for the release you run. Because the release is planned, the work is mostly preparation: reading the release notes, checking the cluster's health and rehearsing the upgrade on a non-production cluster that matches production as closely as practical. Ask whether the release notes list fixes that matter to your configuration, such as RGW, RBD or dashboard features you use.
- Change calendar slot: Book the window through your normal change process so storage, network and application owners can object before work starts.
- Staging rehearsal: Run the same target version on a staging cluster with similar daemon counts and hardware classes, and time each stage.
- Health baseline: Record
ceph health detailand placement group state before the window, and do not start while the cluster is already degraded. - Rollback limits: Confirm which steps can be reversed. Some upgrades cannot be rolled back once daemons run the new version, so the staging run should state where the point of no return is.
- Client impact: Check whether any clients need a matching library or kernel version before or after the window.
Confirm the target point release number, the release notes reviewed and the staging result with the named owner before the window is approved.
An urgent advisory changes the order of work. When a security fix affects a component you have enabled, the window shrinks and the question moves from when to patch to which daemons and interfaces are exposed first. Ceph handles vulnerability reports through its security process, and security fixes are applied only to the current active releases, so the fix you need will normally arrive in a point release for the release you already run or the next one in that line. Start by confirming whether the advisory applies to your version and to features you enable, such as the dashboard, the Object Gateway or specific authentication settings.
- Exposure first: Identify which affected daemons are reachable from untrusted networks and patch those hosts or services first.
- Shortened window: Agree a compressed change slot with the approvers and keep the rehearsal to the steps that matter for this release.
- Documented risk decision: Record what is exposed, what compensating controls exist, and why the chosen date was accepted, with the approver's name.
- Compensating controls: Consider restricting network access or disabling the affected feature until the patch is applied, and state the trade-off.
- Communication: Tell application owners and clients what may be interrupted and when.
Confirm the advisory text and affected versions with the project's published notes, and confirm exposure with your own scan results before deciding the window.
On an air-gapped network, the timing depends on what can be moved across the boundary and how long that takes under your transfer rules. cephadm normally pulls container images from a registry, so the target images must be mirrored into a local registry before the window opens. The window is then only as reliable as your check that every host can pull the mirrored images. Treat image transfer, scanning and approval as part of the schedule, not as a step that happens during the change. The detailed procedure is covered in the topic on upgrading Ceph in an air-gapped network.
- Import lead time: Allow for media transfer, malware scanning and approval of the image set before the window is booked.
- Mirrored images: Mirror the Ceph image and any monitoring images the cluster uses, and record their digests.
- Host pull test: Confirm every host can pull the target image from the local registry before the window, not during it.
- Release notes offline: Store the release notes and advisory text inside the enclave so approvers can review them without internet access.
- Registry capacity: Confirm the local registry has space and access control for the new tags.
Confirm with your security team how images are approved and imported, and test the local pull on one host before the change is scheduled.
What makes a point release take longer than expected
This table lists the factors that stretch a Ceph point release window beyond the upgrade itself, with what each one adds and what to check before scheduling. Read it as a pre-scoping checklist: the more rows that apply to your clusters, the more test cycles and coordination a written scope should include.
| Driver | Why it adds effort | What to check |
|---|---|---|
| Cluster size and daemon count | Every MON, MGR, OSD, MDS and RGW daemon is restarted in a staggered order, so more hosts and daemons mean more cephadm rounds and more health checks between them. | Count daemons per cluster by type, and note which hosts run several daemon types. |
| Client types and versions | Kernel RBD clients and librados applications run their own library versions, and some older clients may not work with the new release or tunables, so each client group needs its own compatibility check. | List every client type, its kernel or librados version, and who owns it. |
| Custom container images or configuration | Modified images, custom entrypoints or hand-edited configuration can conflict with the stock images cephadm pulls, and each override must be re-tested against the target point release. | Inventory image overrides, custom config keys and any files edited outside cephadm. |
| Air-gapped image mirroring | Target images must be mirrored into a local registry and pulled by every host before the upgrade starts, and a missed image can stall the rollout mid-window. | Confirm the mirrored image tags match the release, and that every host can pull them. |
| Cluster health before the window | A cluster already showing health warnings, scrub errors or degraded placement groups makes it hard to tell upgrade effects from existing faults, and may block cephadm from proceeding. | Run a full health review and clear or document warnings before the window opens. |
| Data volume and recovery time | Large amounts of data slow daemon restarts and any recovery or backfill triggered during the rollout, which lengthens each stage and the total window. | Record used capacity, current recovery activity and the expected rebalance load. |
| Number of environments needing the patch | Development, test, staging and production each need the same point release applied and verified, often in sequence, so effort scales with the environment count. | Confirm how many environments are in scope and the order in which they will be patched. |
What buyers ask before they hire help with Ceph patching
Can our own team apply Ceph point releases without a partner?
Yes, if your team can run cephadm and follow a tested runbook. Point releases within a supported release are applied by cephadm as container upgrades, so the work is mostly preparation, health checks, staged daemon restarts and verification. Whether this suits your staff depends on how many people can perform it, whether they have done it on your cluster before, and how your change control process approves production work. Many teams keep routine patching in-house and bring in a partner for the first rollout, for a cluster with unusual hardware, or for a patch that touches a larger upgrade. Ask us for a written runbook review so you can see what your own team would be responsible for.
What drives the cost and effort of a Ceph patch engagement?
The main drivers are cluster size, the number of environments, how much customization sits on top of the default cephadm deployment, whether the site is air-gapped, and how much testing your change process requires. A larger cluster means more hosts to stage and more health checks between steps. Each additional environment, such as staging, lab and production, adds a separate rehearsal. Air-gapped sites need the new container images mirrored into a local registry before work starts. One-time costs include the runbook, the staging rehearsal and the first production patch. Recurring costs appear when you ask for patch cycles on a retainer. A quote should itemize these components and state what is excluded.
How long does a Ceph point release take to roll out?
The duration depends on cluster size, current health and how many change windows your organization allows. A healthy cluster with spare capacity moves through daemon restarts faster than one that is still recovering data or running with warnings. Because the time depends on your environment, do not rely on a general figure. Ask for a written schedule that lists the staging rehearsal, the production windows, the health gates between host groups and the verification steps at the end. The schedule should show what happens if a gate fails and how long a pause would add.
What does our team need to provide for a patch?
You need to provide access, change windows and named approvers. Access means a cephadm admin path to the cluster, read access to monitoring and logs, and the ability to pull images from your registry or mirror. Change windows must be booked in advance, with enough time for staged restarts and recovery. A staging cluster that resembles production makes the rehearsal meaningful, and named approvers let decisions about pausing or stopping happen during the window without delay. Your team should also confirm backup status and current health warnings before the first step.
Can an unsupported Ceph release still receive the security fix?
No. Security updates are applied only to the current active releases, so a release that is out of support will not receive the fix from the project. Your path is a planned upgrade to a supported release first, then the patch on that release. The upgrade itself is a separate change with its own checks, rollback points and testing. Check the active releases page to confirm which releases are maintained and their estimated end-of-life dates before you schedule the work.
What happens if a Ceph patch fails partway through?
Work should stop at a defined decision point, not continue because the schedule is tight. Before the first host is touched, the runbook should name the rollback points, such as the last fully healthy daemon group, and the conditions that trigger a stop, such as a cluster health state that does not return to normal between steps or client I/O errors. Because cephadm upgrades run daemons in stages, a failed step can often be paused while the cluster serves data, but recovery steps must be checked before continuing. The decision threshold, meaning who can call a stop and what evidence they use, should be agreed and written before the window opens. Ask your provider to show how each rollback point was tested in staging.
Should we read the release notes ourselves before patching?
Yes. Read the release notes for every point release in your target path, and look specifically for CVE references and any changed defaults or required steps. Security fixes are described in the notes for the release line, and a fix may matter more for some deployments, such as those that expose the dashboard or object gateway. Your team should map each listed fix to the features you run, then decide what needs verification after the patch. This reading is part of any partner engagement too, and it helps you judge whether a quoted scope covers the fixes that matter to your environment.
Does DeployOpen provide ongoing patching after the first rollout?
Ongoing support, upgrades and continuous testing are available as retainers, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. A retainer can cover recurring patch cycles, while a one-off engagement covers a single patch with its runbook and rehearsal. Ask for the written scope to state which releases are covered, which environments are included, how security notices are monitored, and how change windows are booked. DeployOpen does not publish a price list, so a quote follows from that scope.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports self-hosted open-source platforms inside your own infrastructure, including Ceph point release and security patching. We start by agreeing on the cluster's current release, the upgrade path and the maintenance windows, then deliver the patch work under a written, fixed scope.
How we scope
- Inventory the running Ceph release, cephadm version, container images and every host, daemon and client that depends on the cluster.
- Confirm the target point release against the Ceph release notes and the security fixes it carries for your environment.
- Agree the written scope, maintenance windows, rollback criteria and who approves each step before any work starts.
How we build
- Run the point release first in a non-production cluster or lab that mirrors your host and network layout where one exists.
- Execute a staged cephadm rolling upgrade with health checks between daemon groups and a documented stop condition.
- Test client access, RGW endpoints and monitoring alerts after each stage, recording results against the agreed acceptance list.
How we hand over
- Deliver a runbook covering the exact commands, image references, health checks and rollback steps used for your cluster.
- Provide a change record showing versions before and after, advisories addressed and any deviations from the plan.
- Walk your operations team through the procedure so the next point release can be applied from your own runbook.
How we support
- Ongoing support, point release application and continuous testing are available as a retainer, scoped in writing.
- Retainer scope can cover monitoring the Ceph release calendar and planning each patch cycle before end of life dates.
- Confirm with DeployOpen during scoping which vendor advisories, response times and escalation paths the retainer includes.
