Innerhalb weniger Tage im April 2025 hat Magnolia International drei Maßnahmen umgesetzt, die in ihrer Kombination weit mehr als Routine-Wartung bedeuten: Am 8. April 2025 wurde Magnolia 6.3.7 als LTS-Release ausgeliefert — primär ein Security-Release mit einem Breaking Change am SPA Template Annotations Endpoint. Kurz darauf folgte Magnolia CMS 6.3.8 als weiteres Bug-Fixing- und Security-Release, das unter anderem Unterstützung für Elliptic Curve (EC) Cryptography zur Signierung von Publikationsanfragen einführt. Flankierend dazu: Magnolia CLI v4 hat am 16. April 2025 das End-of-Life erreicht und wird keinerlei Updates mehr erhalten — einschließlich Security-Fixes. Wer diese drei Ereignisse isoliert betrachtet, verpasst das eigentliche Signal.
Was technisch passiert ist — und warum es brennt
Der gravierendste Einschnitt findet sich in 6.3.7: Magnolia hat die `bypassWorkspaceAcls`-Property aus dem Template Annotations Endpoint entfernt. Um SPA-Projekte weiterhin editierbar zu halten, müssen Anpassungen an der Authentifizierungslogik vorgenommen werden. Diese Property war in vielen headless SPA-Projekten ein stiller Komfortmechanismus: Der Frontend-Request konnte Workspace-ACLs umgehen, ohne explizit authentifiziert zu sein. Die SPA Template Annotations machen Content aus einem Frontend-Projekt in Magnolia editierbar — durch das Injizieren von Annotations (HTML-Kommentare) rund um Komponenten, die der Magnolia Page Editor in Steuerelemente für Redakteure umwandelt. Diese Annotations werden serverseitig erzeugt und über einen dedizierten Endpoint abgerufen. Das Entfernen des Bypasses ist technisch überfällig — in der Praxis bedeutet es für laufende Projekte jedoch sofortigen Handlungsbedarf: Der empfohlene Migrationspfad sieht vor, einen dedizierten Magnolia-User für Frontend-Requests anzulegen, ihm eine Rolle mit Write-Access auf das Website-Repository zuzuweisen und das Frontend-Projekt auf Basic Authentication umzustellen.
Parallel führt 6.3.8 mit ECC eine kryptografisch zeitgemäßere Alternative zu RSA ein: ECC kann nun zur Signierung von Publikationsanfragen konfiguriert werden. Aufgrund der kürzeren Schlüssellänge ist ECC performanter als RSA-Signierung, und es ist nun auch möglich, andere Cipher-Algorithmen als RSA für die Datenverschlüsselung zu verwenden. Dies ist kein kosmetisches Feature — angesichts zunehmender Anforderungen aus NIS2, BSI-Grundschutz und Enterprise-Security-Audits ist algorithmische Agilität bei signierten Inhaltstransaktionen zwischen Author- und Public-Instanz eine ernsthafte Compliance-Anforderung.
Das dritte Signal ist das CLI v4 End-of-Life. CLI v5 ist ein plugin-basiertes Tool, das Entwicklern Modularität und die Möglichkeit bietet, Funktionalitäten durch eigene CLI-Kommandos zu erweitern. Die Architektur ermöglicht es, Funktionalitäten einfach hinzuzufügen oder zu erweitern, und unterstützt sowohl Freemarker-basierte als auch headless Projekte. Die Migration ist nicht trivial: Projektspezifische Setups, CI/CD-Pipelines und Dev-Onboarding-Skripte, die auf `mgnl`-Commands der v4 aufbauen, müssen überarbeitet werden.
Strategische Bewertung: Magnolia konsolidiert seine Sicherheitsarchitektur
Aus meiner Sicht ist dieses April-Paket kein Zufall, sondern ein bewusstes Konsolidierungssignal. Magnolia positioniert sich seit Version 6.3 konsequent als enterprise-fähige, composable DXP — und das erfordert eine Sicherheitsarchitektur, die diesem Anspruch standhält. Die Entfernung von `bypassWorkspaceAcls` ist der Abschluss eines längeren Prozesses: Neue Nodes werden nur dann persistent angelegt, wenn die Berechtigungen für den Website-Workspace auf Read und Write gesetzt sind. Das ist das richtige Prinzip — es hätte nur früher kommen müssen.
Im Vergleich mit Wettbewerbern wie Contentful oder Contentstack, die von Grund auf API-first und Cloud-native entwickelt wurden, hat Magnolia den strukturellen Vorteil der hybriden Headless-Architektur mit Visual Editing — trägt aber gleichzeitig historische Komplexität im Berechtigungsmodell. Dass diese Schulden jetzt aktiv abgebaut werden, erhöht die Langzeit-Wettbewerbsfähigkeit der Plattform erheblich.
Konkrete Implikationen für Projekte und Unternehmen
Für laufende Produktionsprojekte auf Basis von Magnolia 6.2.x oder 6.3.x ist die Lage eindeutig: Wer SPA-Integrationen betreibt und noch `bypassWorkspaceAcls` verwendet, hat technische Schulden, die bei einem Update auf 6.3.7+ zu Regressionen führen. Eine Bestandsaufnahme aller Template-Annotation-Endpoints sowie eine Überprüfung der Frontend-Authentifizierungslogik sind jetzt Pflicht — nicht beim nächsten Planungsmeeting, sondern im laufenden Sprint.
Die neuen `canSkipProperty`- und `excludeProperty`-Indexierungsregeln erlauben feingranulare Kontrolle darüber, welche Properties von der Indizierung ausgeschlossen werden, und verbessern Performance und Storage-Effizienz — ein Feature, das bei großen Content-Repositorys mit komplexen JCR-Strukturen erhebliche Laufzeitgewinne bringen kann und in Performance-Reviews ernst genommen werden sollte.
Und schließlich: Wer in neuen Projekten noch CLI v4 einsetzt, baut auf einem Fundament ohne Sicherheitsnetz. CLI v4 wird keinerlei Updates mehr erhalten — auch keine Security-Fixes. Für continued Support, Verbesserungen und Kompatibilität mit aktuellen Magnolia-Versionen ist CLI v5 die einzige valide Option. Agenturen und Unternehmen, die Magnolia-Projekte im Betrieb haben, sollten diese Migration in ihre Q2-Roadmap aufnehmen — bevor eine Sicherheitslücke in einer ungepatchten Toolchain zum Problem wird.
Das April-Paket 2025 ist kein Rauschen im Changelog. Es ist Magnolias klares Statement: Sicherheit ist kein Feature mehr — sie ist Voraussetzung.
