Page tree

Magnolia 5.7 reached extended end of life on May 31, 2022. Support for this branch is limited, see End-of-life policy. Please note that to cover the extra maintenance effort, this EEoL period is a paid extension in the life of the branch. Customers who opt for the extended maintenance will need a new license key to run future versions of Magnolia 5.7. If you have any questions or to subscribe to the extended maintenance, please get in touch with your local contact at Magnolia.

This page explains how we ensure that Magnolia is a secure platform for your project.

Magnolia is only as secure as your project implementation

There is no single certificate that would validate a Web application as secure. Magnolia is a platform, which means security depends on the environment Magnolia is deployed in and on your project-specific implementation.

Only you know the specifics of your environment and your business. For any given application, there may not be a threat agent that can perform the relevant attack, or the technical impact may not make any difference to your business. Therefore, you should evaluate each risk for yourself, focusing on the threat agents, security controls, and business impacts in your enterprise. – Open Web Application Security Project (OWASP)

OWASP Top 10 security risks

OWASP Top 10 is "a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications." (owasp.org)

While there is no certificate that could certify the Magnolia platform as secure, OWASP Top 10 is a very reasonable checklist. It's a good idea to always validate your project implementation against the OWASP Top 10.

How to report vulnerabilities

If you find a security vulnerability in Magnolia, please report it privately:

Our goal is to keep the vulnerability private. Issues in the SUPPORT project are private to Magnolia and the issue reporter.

How we react to vulnerability reports

  1. Magnolia evaluates whether the vulnerability is real or a case of misconfiguration. If real, we commit to provide a fix in 30 days.
  2. Magnolia creates separate JIRA issues for the fix. These issues are visible to Magnolia only. 
  3. When a fix is available, Magnolia informs the reporter through the same channel where the issue was reported and provides the fix.
  4. Magnolia makes the fix available to all clients in the next maintenance release. We make a short statement about the fix in release notes but give no details since unpatched installations are vulnerable.
  5. JIRA issues for the fix remain private for 90 days after the fix is released. This shelters clients from exposure and prevents anyone from exploiting the vulnerability.

How to learn about security fixes

  • Read the release notes carefully. Security fixes are announced in release notes.
  • Subscribe to the release notes RSS feeds.
  • Keep your instances up to date.

Backporting of security fixes

All currently maintained Magnolia branches get security fixes backported if the branch is vulnerable.

Maintenance releases for the current major version are available for the Community Edition as well as the Enterprise Edition.

Maintenance releases for previous major versions of Magnolia are available to Enterprise customers only (i.e. customers that have an active subscription to Magnolia Enterprise Edition).

  • No labels