Within just a few days in April 2025, Magnolia International implemented three measures that, in combination, mean far more than routine maintenance: On April 8, 2025, Magnolia 6.3.7 was shipped as an LTS release — primarily a security release with a breaking change to the SPA Template Annotations Endpoint. Shortly afterward came Magnolia CMS 6.3.8 as another bug-fixing and security release, which among other things introduces support for Elliptic Curve (EC) cryptography for signing publication requests. Alongside this: Magnolia CLI v4 reached end-of-life on April 16, 2025 and will no longer receive any updates — including security fixes. Anyone who looks at these three events in isolation misses the actual signal.
What happened technically — and why it is urgent
The most serious cut is in 6.3.7: Magnolia has removed the `bypassWorkspaceAcls` property from the Template Annotations Endpoint. To keep SPA projects editable, adjustments must be made to the authentication logic. In many headless SPA projects, this property was a silent convenience mechanism: the frontend request could bypass workspace ACLs without being explicitly authenticated. The SPA Template Annotations make content from a frontend project editable in Magnolia — by injecting annotations (HTML comments) around components, which the Magnolia Page Editor converts into controls for editors. These annotations are generated server-side and retrieved via a dedicated endpoint. Removing the bypass is technically overdue — in practice, however, it means immediate action is required for ongoing projects: the recommended migration path is to create a dedicated Magnolia user for frontend requests, assign it a role with write access to the website repository and switch the frontend project to Basic Authentication.
In parallel, 6.3.8 introduces ECC as a cryptographically more up-to-date alternative to RSA: ECC can now be configured for signing publication requests. Due to the shorter key length, ECC performs better than RSA signing, and it is now also possible to use cipher algorithms other than RSA for data encryption. This is not a cosmetic feature — in view of increasing requirements from NIS2, BSI IT-Grundschutz and enterprise security audits, algorithmic agility for signed content transactions between author and public instances is a serious compliance requirement.
The third signal is the CLI v4 end-of-life. CLI v5 is a plugin-based tool that offers developers modularity and the ability to extend functionality with their own CLI commands. The architecture makes it easy to add or extend functionality and supports both Freemarker-based and headless projects. The migration is not trivial: project-specific setups, CI/CD pipelines and dev onboarding scripts built on v4 `mgnl` commands must be reworked.
Strategic assessment: Magnolia is consolidating its security architecture
In my view, this April package is no coincidence but a deliberate consolidation signal. Since version 6.3, Magnolia has consistently positioned itself as an enterprise-ready, composable DXP — and that requires a security architecture that lives up to this claim. The removal of `bypassWorkspaceAcls` concludes a longer process: new nodes are only persisted if the permissions for the website workspace are set to Read and Write. That is the right principle — it just should have come sooner.
Compared with competitors such as Contentful or Contentstack, which were developed from the ground up as API-first and cloud-native, Magnolia has the structural advantage of a hybrid headless architecture with visual editing — but at the same time carries historical complexity in its permission model. The fact that this debt is now being actively reduced significantly increases the platform's long-term competitiveness.
Concrete implications for projects and companies
For ongoing production projects based on Magnolia 6.2.x or 6.3.x, the situation is clear: if you run SPA integrations and still use `bypassWorkspaceAcls`, you have technical debt that will lead to regressions when updating to 6.3.7+. An inventory of all template annotation endpoints and a review of the frontend authentication logic are now mandatory — not at the next planning meeting, but in the current sprint.
The new `canSkipProperty` and `excludeProperty` indexing rules allow fine-grained control over which properties are excluded from indexing, and improve performance and storage efficiency — a feature that can bring considerable runtime gains in large content repositories with complex JCR structures and should be taken seriously in performance reviews.
And finally: if you still use CLI v4 in new projects, you are building on a foundation without a safety net. CLI v4 will no longer receive any updates — not even security fixes. For continued support, improvements and compatibility with current Magnolia versions, CLI v5 is the only valid option. Agencies and companies operating Magnolia projects should include this migration in their Q2 roadmap — before a security vulnerability in an unpatched toolchain becomes a problem.
The April 2025 package is not noise in the changelog. It is Magnolia's clear statement: security is no longer a feature — it is a prerequisite.
