An editor opens a website preview and sees an unpublished post from an area she has no permission to access. Is a role misconfigured? Is a permission check missing in an extension? Or is the error in the CMS itself? On platforms like Liferay and Magnolia, the answer determines who can close the vulnerability. The first report can leave that question open.
What responsible disclosure means
Responsible disclosure refers to handling a discovered vulnerability responsibly. The term now widely used, Coordinated Vulnerability Disclosure (CVD), emphasizes coordination between the parties involved. Whoever discovers a vulnerability first reports it confidentially. The responsible party reviews the finding, limits the risk and prepares a fix or a workaround. The parties then agree when affected operators or the public will receive which information.
Source: CERT Guide to Coordinated Vulnerability Disclosure
This coordination is mainly about timing and level of detail. Early technical details can make exploitation easier. Staying silent for too long can deprive operators of the chance to protect themselves. A security notice may therefore initially name affected versions and protective measures. A technical report with detailed reproduction steps can follow later, once operators have had time to install the patch.
Source: CERT Guide to Coordinated Vulnerability Disclosure
Disclosure program, bug bounty and security incident
A Vulnerability Disclosure Policy describes which systems and tests the operator authorizes, how reports are received and what happens next. A bug bounty program adds possible rewards for qualifying findings to this framework. Even a small team can run a reliable reporting process without rewards. Magnolia and Liferay illustrate both variants.
Sources: Magnolia Responsible Disclosure Policy · Liferay Reporting and Testing Policy
A vulnerability is an exploitable weakness in a system. If there are signs that someone is already exploiting it, security incident handling starts in parallel. The operations team secures relevant logs, restricts access and checks which systems and data are affected. Coordination with the reporter and the vendor continues in the meantime.
Source: NIST guidance on handling vulnerability reports
Why there are several deadlines
Acknowledging receipt, providing a first reliable status, delivering a fix and publishing are separate milestones. Receipt can be acknowledged within a few working days, even if the technical review takes longer. As soon as the team can better assess the impact, it agrees on the next status update and a target publication date with the reporter.
The frequently cited 90 days come, among other sources, from the policy of Google's Project Zero. In its regular process, the team allows 90 days for a patch and, if the issue is fixed in time, generally grants an additional window for installing it. Shorter deadlines apply when active exploitation has been observed. Which deadline suits a specific case depends on factors such as the risk and the available protective measures.
Source: Project Zero Vulnerability Disclosure Policy
If the responsible vendor does not respond despite attempts to make contact, or if several vendors use the same component, a coordinating body such as a competent CERT can help. It can establish contacts and coordinate how multiple affected parties are informed. This is relevant, for example, when an error sits in a library that is shipped through various CMS extensions.
Source: CERT Guide to Coordinated Vulnerability Disclosure
Who is responsible in a CMS project?
A CMS project consists of the product, project-specific code, roles and permissions, interfaces and the hosting infrastructure. An initial assignment often comes from asking under which conditions the error can be reproduced.
| Finding | First point of contact |
|---|---|
| The error also occurs in a clean test installation with standard components. | The product's vendor or security team |
| The error occurs only with a custom Liferay module, a Magnolia extension or a project-specific configuration. | The operator and the responsible project team |
| The finding concerns a third-party extension or an upstream service. | The operator to limit the risk, and the provider of the affected component to fix the error |
Anyone who discovers a vulnerability on a specific website without knowing the cause reports it confidentially to the site's operator. The operator can secure the instance and involve the vendor if needed. Reproducing the issue in an authorized standard installation helps distinguish product errors from project configuration.
How CMS operators set up the process
1. Publish a discoverable reporting channel
A short policy names a monitored security address or a protected form. It specifies which domains and environments are covered, which tests are permitted and how sensitive evidence can be submitted securely. Typical limits concern availability, changes to other people's data and access to personal content. Operators working with several service providers should clarify internally who receives reports and who can make changes on which platform.
A file available over HTTPS at /.well-known/security.txt makes the reporting channel machine-readable. Contact and Expires are required fields. Policy can point to the policy. The file generally applies to the host on which it is provided. With several public CMS domains, the reporting channel should therefore be discoverable on every relevant host.
Source: RFC 9116 on security.txt
2. Accept a reproducible report
A useful report contains the affected URL or component, the exact product and module version, the required role, the steps to reproduce, and the expected and observed behavior. A concrete sentence about the impact helps with the assessment, for example that an editorial account can read an unpublished post from another area.
Test data or a redacted screenshot is often enough as evidence. Once the finding is proven, testing ends. Anyone who unexpectedly comes across real customer data stops the test and reports the access through the protected channel.
3. Clarify responsibility and urgency
Every report gets a confidential ticket, a responsible person and a deputy. Two working days to acknowledge receipt can be a practical internal target for a small CMS team. The subsequent assessment considers whether the function is publicly accessible, which role is needed for exploitation, how many instances are affected and which data or functions are at stake. A publicly accessible endpoint that delivers unpublished content calls for a different response than the same error in an isolated test environment.
Source: NIST guidance on handling vulnerabilities
4. Limit the risk and verify the fix
The team can temporarily restrict access, disable an affected function or install an available patch. To verify the fix, it uses the same role and the same procedure with which the vulnerability was demonstrated. For a permission error, this includes a counter-check: authorized users must still be able to access the function. If the team runs several instances, it also records where the fix has already been installed and where a workaround is in place.
5. Inform those affected and coordinate publication
Operator, vendor and reporter agree on who is informed and when. A security advisory usually names the affected versions, the impact, available protective measures and the corrected version. If a fix takes longer, the team keeps the reporter up to date and agrees on the next date. In the case of active exploitation, an earlier warning with concrete protective measures can make sense.
Source: CERT Guide to Coordinated Vulnerability Disclosure
The reporting channels for Liferay and Magnolia
Liferay refers external security reports to its public bug bounty program on Intigriti, where the applicable rules and the explicitly covered targets are listed. For DXP subscription customers, Liferay also describes the route via Subscription Services in the Customer Portal. Anyone wishing to test a specific customer installation follows the authorization of the respective operator.
Sources: Liferay Reporting and Testing Policy · Liferay Security Support Policy
Magnolia names a private SUPPORT ticket or the address security@magnolia-cms.com for vulnerabilities in the product. The separate Responsible Disclosure Policy for domains and subdomains owned by Magnolia narrows the testing scope and requires reports in English with a comprehensible attack scenario. For a Magnolia website operated by a customer, that customer's own reporting channel is the first point of contact.
Sources: Magnolia Security Policy · Magnolia Responsible Disclosure Policy
Back to the preview
Using two test accounts and an unpublished test item, the operator checks whether the preview actually crosses the intended boundary between areas. If the error occurs only in a custom extension, the project team corrects the permission check. If it can also be reproduced with the standard function, the vendor receives a confidential report with versions and reproduction steps.
Until this is resolved, the operator can restrict access to the preview. After the fix, the operator rechecks both roles and informs the reporter of the result. The report thus reaches the place where the risk can be reduced first and the cause then fixed.
