Show last authors
1 {{box cssClass="floatinginfobox"}}
2 {{toc/}}
3 {{/box}}
5 The goal of this document is to provide some information about the policy of in case a vulnerability is found in XWiki Standard.
7 = What are the available channels to discuss about security issues? =
9 Four channels are available with different usages.
11 == Security Forum & Mailing-List ==
13 The main discussion channel is the private [[security forum category >>]]. However, this channel is private and for this reason, we've kept the old mailing-list (security[at] since anyone can post on it (but only core committers and some other trusted persons can read them). See also [[Mailing Lists>>doc:Community.Discuss||anchor="HMailingLists"]].
15 The forum channel **must be used** for warning the sponsoring companies that a new security issue has been discovered. It **might be used** for asking about a potential security issue.
17 == JIRA ==
19 The JIRA of XWiki ([[https:~~/~~/>>url:]]) is the right place to submit issues by using the visibility set to Confidential and the label “security”. Those issues are only visible to people who submitted them, to the committers of XWiki, and to anyone trusted by the XWiki committers who can help fixing them. All informations about the submitted issues if discussed elsewhere should be added on the comments of the issues so that the reporter can follow them. Note that the label “security” could be used in JIRA dashboard or in Release Notes to inform about the fixed security issues.
21 == Matrix ==
23 A dedicated Matrix Chat room is dedicated to talk about security issues but is dedicated to the same people as the security mailing-list. It should be mainly used to discuss about the security policy and technical details about a specific issue.
24 More information are available on [[Chat>>doc:Community.Chat||anchor="HMatrix"]].
26 == Github Security Advisories ==
28 For each security issue fixed for XWiki, a dedicated security advisory is created on Github. Those advisories remain private until they are publicly disclosed. By default, the owners of a Github organization can view the advisories: in the case of XWiki, the Github organization is owned by all XWiki committers.
29 On top of that, access to the advisories is also manually granted to a dedicated Github Team for trusted people who are not committers, to see the advisories before they are publicly disclosed.
31 People wanting to get access to this Github Team should request access on the security mailing-list.
33 = Where to submit security issues? =
35 As specified above, all security issues should be submitted on [[https:~~/~~/>>url:]] with the visibility set to Confidential and the label “security”. Try to give as much information as possible for those issues and in particular a way to exploit the vulnerability, or a way to assess that the vulnerability is present: we will use it to determine if some instances are subject to it or not.
37 Those issues are only visible to people who submitted them, to the committers of XWiki and to anyone trusted by the XWiki committers who could help fixing them.
39 = What are the criteria for computing severity? =
41 The severity is defined case by case by the core committers depending on two criteria:
43 * the impact of the security issue (e.g. an issue that might impact all pages of a wiki is more severe than an issue which might impact only pages with specific rights)
44 * and the difficulty to reproduce it (e.g. an issue which needs script rights to be reproduced is less severe than an issue which only needs view access on the wiki)
46 We currently use two types of labels to compute the severity of an issue: the type of attacker (depending on its rights on the wiki) and the type of attack (depending on what he can actually do).
48 == Types of attackers ==
50 |=Label|=Description
51 |attacker_guest|The attacker doesn’t need to be logged-in to perform the attack.
52 |attacker_account|The attacker needs to be logged-in to perform the attack.
53 |attacker_view|The attacker needs to have view right to perform the attack.
54 |attacker_comment|The attacker needs to be logged-in and the comment rights to perform the attack.
55 |attacker_edit|Same as above but with edit rights.
56 |attacker_script|Same as above but with script rights.
57 |socialeng|The attacker can only perform the attack if he has physical access to the target device
59 == Types of attacks ==
61 |=Label|=Description
62 |stability|Attacks that are related to targeting the host (e.g. DOS attack)
63 |escalation|Attacks that are related to permanently getting more rights
64 |login|Attacks that are related to login with another user identity
65 |xss|All attacks related to code injection
66 |impersonation|Attacks that are related to using another people right to perform actions
67 |dataleak|Attacks that are related to confidential data that might be retrieved in readonly: could be emails, but could also be XWiki document that shouldn’t be viewable.
68 |spam|Attacks that are related to spamming
70 == Severity matrix ==
72 **DISCLAIMER**: This severity matrix is only indicative, the severity is computed on a case-by-case basis only.
74 How to read this matrix:
76 * columns are representing the type of attackers
77 * lines are representing the type of attacks
78 * values are a severity between high / medium / low
80 |=Attacks \ Attackers|=guest|=account or view|=comment|=edit|=script|=socialeng
81 |stability|High|High|High|Medium|Medium|Low
82 |escalation|High|High|High|High|Medium|Low
83 |impersonation|High|High|High|High|Medium|Low
84 |login|High|High|High|Medium|Low|Low
85 |xss|High|High|High|Medium|Low|Low
86 |dataleak|High|High|High|Medium|Low|Low
87 |spam|High|High|High|Medium|Low|Low
89 Note: on the future we’ll need to formalize the usage of [[https:~~/~~/>>url:]] to compute the severity of our security.
91 = How long does it take to fix a security issue? =
93 The priority of the JIRA issue is set depending on the severity of the issue, we apply basically the following mapping:
95 * high severity: blocker
96 * medium severity: critical
97 * low severity: major
99 Blocker issues have to be fixed before next release. There’s no obligations about critical and major issues, so they are handled depending on the other priorities of the core committers.
101 = When is a security issue considered as fixed? =
103 Security issues are considered as fixed only once the fix is part of releases for all supported branches impacted by the issue. So for example, if [[>>url:]] is currently in the 12.x cycle and a security issue impacts both 11.10.1 (LTS) and 12.3 (stable), the issue is fixed when 11.10.2 and 12.3.1 (or 12.4) are released with the fix.
105 = Are security issues ever publicly disclosed? =
107 Once the issue has been properly fixed and the fix releases, a CVE is published to publicly disclose about this issue and to incitate for an upgrade. The CVE is **mandatory** for any security issues.
109 = How long does it take to publish a CVE? =
111 Once an issue has been fixed and released, an embargo of 3 months is starting to allow anyone working with XWiki to perform actions before the publication of the CVE. The sponsoring companies are automatically informed as soon as a security issues has been discovered through the security communication channels.
113 For example, if a security issue has been fixed and released in 11.10.2 and in 12.0, respectively released the 5th of February and the 29th of January, the CVE could be published 3 months after latest release: i.e. the 5th of May.
115 = What’s the process to handle security issues for committers? =
117 1. Take the ownership on the security issue by assigning the JIRA ticket to yourself.
118 1. Validate the information about the security issue (including the label and confidentiality fields) and provide missing information: in particular make sure that the issue contains reproduction steps to either exploit the vulnerability or assess its presence
119 1. Announce the problem on the dedicated security communication channel
120 1. Fix the issue on all supported branches
121 1. Create a draft advisory on Github (see: [[>>url:]]).
122 11. The advisory must contain clear description of the vulnerability and a described example of how it can be exploited, it's not necessary to details the steps as those are contained in the JIRA ticket
123 11. When possible the advisory should contain workarounds to allow patching the vulnerability without upgrading
124 11. The advisory should contain a severity computed using CVSS and if possible a CWE link
125 11. The advisory should contain the links of the all commits pushed in master to fix the vulnerability
126 11. Add the ##xwiki/security## Github Team to the collaborators.
127 1. Add a link to the advisory draft on the JIRA issue
128 1. Annnounce the fix on the security forum with the list of branches where the fix is provided and the link to the advisory
129 1. When all XWiki versions where the fix is provided are released, announce on the security list that the 3 months embargo is starting and specify the date when the issue will be made public
130 1. After 3 months, request a CVE through GitHub Advisory page. Remove the confidential label on the Jira issue. Publish the advisory once the CVE ID has been received.

Get Connected