Overview 5 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
5matches
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
5
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
5
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
5
100.0%
split by
peak 2 / quarter
Q1 211
No exploit published1
Medium1
not blocked1
No public exploit1
Q2 212
No exploit published2
High2
not blocked2
No public exploit2
Q3 210
Q4 210
Q1 220
Q2 220
Q3 220
Q4 220
Q1 231
No exploit published1
Critical1
not blocked1
No public exploit1
Q2 231
No exploit published1
Critical1
not blocked1
No public exploit1
Q1 21Q2 21Q3 21Q4 21Q1 22Q2 22Q3 22Q4 22Q1 23Q2 23
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2023-29528 | Critical | 2023-04-20 | No exploit published | No public exploit | XWiki Commons are technical libraries common to several other top level XWiki projects. The "restricted" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1 and massively improved in version 14.6-rc-1, allowed the injection of arbitrary HTML code and thus cross-site scripting via invalid HTML comments. As a consequence, any code relying on this "restricted" mode for security is vulnerable to JavaScript injection ("cross-site scripting"/XSS). When a privileged user with programming rights visits such a comment in XWiki, the malicious JavaScript code is executed in the context of the user session. This allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. This problem has been patched in XWiki 14.10, HTML comments are now removed in restricted mode and a check has been introduced that ensures that comments don't start with `>`. There are no known workarounds apart from upgrading to a version including the fix. |
| CVE-2023-26055 | Critical | 2023-03-02 | No exploit published | No public exploit | XWiki Commons are technical libraries common to several other top level XWiki projects. Starting in version 3.1-milestone-1, any user can edit their own profile and inject code, which is going to be executed with programming right. The same vulnerability can also be exploited in all other places where short text properties are displayed, e.g., in apps created using Apps Within Minutes that use a short text field. The problem has been patched on versions 13.10.9, 14.4.4, 14.7RC1. |
| CVE-2021-32621 | High | 2021-05-28 | No exploit published | No public exploit | XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions prior to 12.6.7 and 12.10.3, a user without Script or Programming right is able to execute script requiring privileges by editing gadget titles in the dashboard. The issue has been patched in XWiki 12.6.7, 12.10.3 and 13.0RC1. |
| CVE-2021-32620 | High | 2021-05-28 | No exploit published | No public exploit | XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In versions prior to 11.10.13, 12.6.7, and 12.10.2, a user disabled on a wiki using email verification for registration canouldre-activate themself by using the activation link provided for his registration. The problem has been patched in the following versions of XWiki: 11.10.13, 12.6.7, 12.10.2, 13.0. It is possible to workaround the issue by resetting the `validkey` property of the disabled XWiki users. This can be done by editing the user profile with object editor. |
| CVE-2021-3137 | Medium | 2021-01-20 | No exploit published | No public exploit | XWiki 12.10.2 allows XSS via an SVG document to the upload feature of the comment section. |