Within a few days in April 2025, Magnolia International implemented three measures that, taken together, represent far more than routine maintenance: On April 8, 2025, Magnolia 6.3.7 was released as an LTS release—primarily a security release featuring a breaking change to the SPA Template Annotations endpoint. Shortly thereafter, Magnolia CMS 6.3.8 followed as another bug-fixing and security release, introducing, among other things, support for Elliptic Curve (EC) Cryptography for signing publication requests. In addition: Magnolia CLI v4 reached end-of-life on April 16, 2025, and will no longer receive any updates—including security fixes. If you look at these three events in isolation, you’ll miss the real message.
What Happened Technically — and Why It’s Urgent
The most significant change is found 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. This property served as a silent convenience mechanism in many headless SPA projects: 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 on the server side and retrieved via a dedicated endpoint. Removing this bypass is technically overdue—but in practice, it means immediate action is required for ongoing projects: The recommended migration path involves creating a dedicated Magnolia user for frontend requests, assigning them a role with write access to the website repository, and switching the frontend project to Basic Authentication.
In parallel, version 6.3.8 introduces ECC as a cryptographically more modern alternative to RSA: ECC can now be configured for signing publication requests. Due to its 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—given the increasing requirements from NIS2, BSI Basic Protection, and enterprise security audits, algorithmic agility in 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 custom CLI commands. The architecture makes it easy to add or extend functionalities and supports both Freemarker-based and headless projects. Migration is not trivial: project-specific setups, CI/CD pipelines, and dev onboarding scripts that rely on `mgnl` commands from v4 must be revised.
Strategic Assessment: Magnolia Consolidates Its Security Architecture
In my view, this April release is no coincidence, but a deliberate signal of consolidation. Since version 6.3, Magnolia has consistently positioned itself as an enterprise-ready, composable DXP—and that requires a security architecture capable of meeting this standard. The removal of `bypassWorkspaceAcls` marks the conclusion of a lengthy process: new nodes are only created persistently if the permissions for the website workspace are set to Read and Write. This is the right approach—it just should have come sooner.
Compared to competitors like Contentful or Contentstack, which were developed from the ground up to be 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 permissions model. The fact that this technical debt is now being actively reduced significantly enhances the platform’s long-term competitiveness.
Specific implications for projects and companies
For ongoing production projects based on Magnolia 6.2.x or 6.3.x, the situation is clear: Anyone running SPA integrations and still using `bypassWorkspaceAcls` has technical debt that will lead to regressions upon 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 for fine-grained control over which properties are excluded from indexing, improving performance and storage efficiency—a feature that can deliver significant runtime gains in large content repositories with complex JCR structures and should be taken seriously in performance reviews.
And finally: Anyone still using CLI v4 in new projects is building on a foundation without a safety net. CLI v4 will no longer receive any updates—including security fixes. For continued support, improvements, and compatibility with current Magnolia versions, CLI v5 is the only valid option. Agencies and companies with Magnolia projects in production should include this migration in their Q2 roadmap—before a security vulnerability in an unpatched toolchain becomes a problem.
The April 2025 release is not just noise in the changelog. It is Magnolia’s clear statement: Security is no longer a feature—it is a prerequisite.
