If you’re running any oCIS (ownCloud Infinite Scale) version, please update to 8.0.3 today.
The latest patch, released on May 11th 2026, contains security fixes.
The upgrade is a binary swap with no configuration changes, no migrations, nothing else to do if you were running oCIS 8.0.x before.
Now for the full story of what the Curie release series has brought since February.
Curie
Each named production release of Infinite Scale is named after a female Nobel Prize laureate, a quiet but deliberate choice. These are the women whose work shaped the scientific and humanitarian foundations the modern world runs on. Naming a release series after them is at minimum a reminder that the infrastructure we build doesn’t exist in a cultural vacuum.
The Curie series is named for Marie Curie, two-time Nobel laureate in Physics and Chemistry. The next releases in development are Deledda, after Grazia Deledda (Literature, 1926), and Ebadi (Shirin Ebadi, Peace 2003), planned for Q3.
The Curie series shipped in four production releases between February and May, with an early access RC (Release Candidate) in the first week of Q1.
Patch numbering follows semantic versioning, the team doesn’t pre-decide whether something will be a major or minor; that’s determined by what actually lands.
What landed across Curie is substantial.
Multi-instance and federation
The centerpiece of the Curie series is multi-instance oCIS.
You can now connect multiple oCIS deployments to the same Identity Provider and share resources across them.
The UI gained an instance switcher and cross-instance resource references in the user context menu.
For federated school clouds, multi-tenant enterprise setups, or the growing number of deployments that need cross-organizational collaboration, this opens use-cases that previously required significant custom work.
Federation via Open Cloud Mesh (OCM) was substantially reworked for full specification compliance at the same time, enabling proper interoperability with other OCM implementations beyond just ownCloud.
This comes with a migration note:
existing OCM invitations and shares need to be recreated after upgrading from oCIS 7.x.
If you’re running OCM in production, plan for that window.
OCM permission change notifications for federated contexts were fixed in a subsequent patch, and internal link access control was tightened.
Security and hardening
Alongside the federation work, Curie brought a round of security improvements that are worth naming explicitly:
- Public link brute-force protection is now enabled by default:
up to five failed password attempts per hour before a link is locked, with the threshold fully configurable. - The Referrer-Policy was tightened to no-referrer, removing any cross-origin leakage from outgoing requests.
- PROXY_FORCE_STRICT_TRANSPORT_SECURITY was added to deployments where oCIS terminates behind an upstream proxy that was swallowing HSTS headers.
- Server-provided strings are now properly escaped before rendering in the UI a category of issue that belongs in a security review regardless of whether a known exploitation path exists. Then there’s 8.0.3, which closes runtime-level CVEs in Go and libvips.
Many reasons you should Update now.
Office integration
The collaboration service (the WOPI layer that connects oCIS to e.g. Collabora) gained the ability to blacklist specific file extensions from specific editors.
In compliance environments where document type routing needs to be policy-controlled rather than left to users, this was a missing configuration knob.
A persistent user-facing error in OnlyOffice view-only mode was also closed.
OnlyOffice sends a WOPI Lock request every time it opens a document, even when the user only has read access. The oCIS WOPI handler was trying to acquire a write lock regardless of view mode, failing with a permission error that OnlyOffice surfaced as an error dialog on document load. The fix returns 200 OK immediately for read-only and view-only modes without touching the lock state which is exactly what the WOPI specification requires. If users were getting error pop-ups when opening shared documents they couldn’t edit, this is what closed it.
Identity and LDAP
Enterprise LDAP setups got meaningful attention across the series:
- The Graph service can now provision users against an external ID attribute from LDAP rather than always generating its own, with a switch to enable it.
This is relevant for AD setups where the authoritative identifier lives upstream and oCIS shouldn’t be minting its own. - A regression that was writing empty externalID values to LDAP on user creation (blocking creation entirely in many configurations) was patched quickly.
- Group creation was fixed to respect the objectClass configured in the server rather than always falling back to groupOfNames.
- And a new environment variable (OCIS_LDAP_GROUP_ADDITIONAL_OBJECTCLASSES) lets you attach additional objectClasses to groups at creation time, closing a gap for LDAP schemas that require groups to carry multiple values.
This is common in enterprise AD and some OpenLDAP setups.
Spaces and permissions
The permission model was extended in two directions:
- The space role set gained SpaceEditorWithoutVersionsWithoutTrashbin full edit rights without access to version history or the trashbin.
The previous step, SpaceEditorWithoutTrashbin (added in 7.2), removed trashbin access and this goes one step further; it’s designed for contexts where edit rights need to be granted without exposing file recovery capabilities: contractor access, compliance-constrained project spaces, environments where version history is a data governance concern. - The REPORT WebDAV method now returns spaceid in its responses, matching what PROPFIND already returned.
Clients that needed to correlate search results back to a specific space were carrying a workaround for this; now they don’t have to.
A more subtle but production-relevant fix:
the middleware responsible for reconciling space memberships was running on every authenticated request, including signed URL requests used for file downloads. Signed URL auth doesn’t carry OIDC claims. The middleware interpreted „no claims“ as „remove this user from all project spaces“, and did so, only to re-add them on the next regular OIDC request. That oscillation produced transient „space not found“ errors and intermittent download failures with nothing obvious in the logs to explain them.
The fix is to skip reconciliation entirely when no OIDC claims are present in the request context.
The user experience
The User Interface received a few great features and fixes:
- A proper crash page in the Curie series: a bounded failure state with a clear message, rather than a blank screen when something goes wrong during load.
- The search bar got a layout fix (search text was overlapping the search icon).
- The share button was being obscured when a sharing role had a long display name, pushing it out of the visible area and making certain sharing flows completely inaccessible.
- External members weren’t appearing in the „Shared with“ section at all, which made federated and external share recipients invisible in the sharing panel.
The release pipeline
Something changed structurally in how Curie was delivered.
For years, oCIS used Drone CI: a self-hosted setup driven by a multi-thousand-line Starlark configuration file that orchestrated everything from unit tests to multi-architecture Docker builds, S3 artifact caching, e2e test suites against a live stack, Helm chart publishing, and the signed release tag flow.
Running it meant owning the infrastructure underneath it.
Moving a pipeline of that complexity to GitHub Actions isn’t a weekend project.
The caching strategy needed rebuilding from scratch across a Go monorepo of around 50 internal services.
Shared infrastructure dependencies had to be recreated.
The release signing flow had to be re-orchestrated.
Every step had to be verified to produce equivalent artifacts, because the quality gates don’t move just because the plumbing did.
The transition completed mid-series.
Earlier Curie patches were still published by the ownClouders automation account; the most recent two came out of github-actions.
The pipeline is stable.
The practical upside: no more runner infrastructure to maintain, native integration with GitHub’s security tooling, and a release process readable by any contributor who knows GitHub Actions rather than ownCloud-specific Drone Starlark.
For a project that launched an OSPO and retired its CLA specifically to lower the barrier to external contribution, that alignment matters.
What’s coming: Deledda and Ebadi
The quarterly cadence puts an early access in the first week of each quarter, with GA (General Availability) gated by QA (Quality Assurance).
If you’re wondering why there’s no Deledda RC (Release Candidate) yet given that Q2 is well underway, yes, we’re running late; the CVE-2026-33634 Trivy/Aqua supply chain incident in March consumed significant bandwidth across engineering, communications, and customer-facing work. The CI (Continuous Integration) migration also ran long.
The Deledda RC will land when it’s clean, not on a calendar date we can no longer hit.
Ebadi enters development in Q3.
Both releases are shaping up on the public roadmap.
The community forum is the right place to push for features or fixes you need while those cycles are still being scoped.
Upgrade now
Update to 8.0.3 from any 8.0.x version as it’s a binary swap no configuration changes, no migrations.
If you’re coming from 7.3.x, the only thing that needs attention is OCM: existing federated invitations and shares need to be recreated as documented in the 8.0.0 release notes. Everything else upgrades cleanly.
- oCIS 8.0.3: github.com/owncloud/ocis/releases/tag/v8.0.3
- Full Curie changelog: github.com/owncloud/ocis/releases
