Overview 12 matches · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
12matches
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
12
100.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
12
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
2
16.7%
Forecast only
0
0.0%
No public exploit
10
83.3%
split by
peak 4 / year
20191
No exploit published1
High1
not blocked1
No public exploit1
20201
No exploit published1
High1
not blocked1
Proof of concept only1
20210
20223
No exploit published3
High3
not blocked3
No public exploit3
20232
No exploit published2
High2
not blocked2
No public exploit2
20241
No exploit published1
High1
not blocked1
No public exploit1
20250
20264
No exploit published4
High4
not blocked4
Proof of concept only1
No public exploit3
20192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-83559 | High | 2026-11-01 | No exploit published | No public exploit | Improper encoding or escaping of output in Apache Wicket. org.apache.wicket.core.util.string.JavaScriptUtils#escapeQuotes() replaces each single quote in its input with a backslash and a single quote, and each double quote with a backslash and a double quote, so that the value can be placed inside a JavaScript string literal. It does not escape the backslash, which is the character that has to be escaped, and escaped first, for the rest of that escaping to hold. A value that already holds a backslash immediately before a quote therefore ends up with two backslashes in front of that quote: the first escapes the second, the quote itself is left unescaped, and it closes the literal. Whatever the value carries after that point is no longer text but JavaScript, and it runs in the application's origin and in the session of the user looking at the page. The method is public, is not deprecated, and its documentation states that its result can be part of a JavaScript call such as an alert; the only limitation it notes concerns JSON values, which need different escaping. An application is affected wherever it calls the method itself and places the result inside a JavaScript string literal, from its own code or from a component of its own or of a third party, and the value it escapes holds data an attacker can influence. There is no further condition, and no component of Wicket has to be involved: the application is using the method for what its documentation offers, and the method does not deliver it. Two components shipped with Wicket Extensions pass a value through the method. org.apache.wicket.extensions.ajax.markup.html.AjaxEditableLabel writes the editor's first error feedback message into a single-quoted JavaScript string literal in the Ajax response, so an application is affected through that component where the message shown for a failed edit holds data an attacker can influence, whether that is the submitted value itself or another variable the application sets on the validation error. A validation message can carry the submitted value, because input is a message variable that every form component supplies for its own validation errors, and the documentation shows overriding a validator's message to include it; none of the message bundles shipped with Wicket interpolates it, so an application that has not written such a message is not affected through this component. org.apache.wicket.extensions.ajax.markup.html.repeater.AjaxListPanel passes the serialized markup tag of an appended component through the method and is not affected: the tag comes from the panel's own markup file, and a quote in any of its attribute values, the component's markup id included, is written as a character reference by the tag serialization and cannot close the literal. This issue affects Apache Wicket: from 8.0.0 through 8.19.0, from 9.0.0 through 9.24.0, from 10.0.0 through 10.11.0. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. Users are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue. |
| CVE-2026-73195 | High | 2026-09-14 | No exploit published | No public exploit | Improper Encoding or Escaping of Output vulnerability in Apache Syncope. Authenticated users can store a spreadsheet formula payload in one of their own plain attributes. When such users are included in a CSV export and the generated CSV file is opened by a spreadsheet application, the formula may be executed. This issue affects Apache Syncope: from 3.0.0-M0 through 3.0.16, from 4.0.0-M0 Through 4.0.7, from 4.1.0-M0 through 4.1.2. Users are recommended to upgrade to version 4.0.8 / 4.1.3, which fix this issue. |
| CVE-2026-34483 | High | 2026-04-09 | No exploit published | No public exploit | Improper Encoding or Escaping of Output vulnerability in the JsonAccessLogValve component of Apache Tomcat. This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.20, from 10.1.0-M1 through 10.1.53, from 9.0.40 through 9.0.116. Users are recommended to upgrade to version 11.0.21, 10.1.54 or 9.0.117 , which fix the issue. |
| CVE-2025-66024 | High | 2026-03-04 | No exploit published | Proof of concept only | The XWiki blog application allows users of the XWiki platform to create and manage blog posts. Versions starting with 9.15 and prior to 9.15.7 are vulnerable to Stored Cross-Site Scripting (XSS) via the Blog Post Title. The vulnerability arises because the post title is injected directly into the HTML <title> tag without proper escaping. An attacker with permissions to create or edit blog posts can inject malicious JavaScript into the title field. This script will execute in the browser of any user (including administrators) who views the blog post. This leads to potential session hijacking or privilege escalation. The vulnerability has been patched in the blog application version 9.15.7 by adding missing escaping. No known workarounds are available. |
| CVE-2024-55663 | High | 2024-12-12 | No exploit published | No public exploit | XWiki Platform is a generic wiki platform. Starting in version 6.3-milestone-2 and prior to versions 13.10.5 and 14.3-rc-1, in `getdocument.vm`; the ordering of the returned documents is defined from an unsanitized request parameter (request.sort) and can allow any user to inject HQL. Depending on the used database backend, the attacker may be able to not only obtain confidential information such as password hashes from the database, but also execute UPDATE/INSERT/DELETE queries. This has been patched in 13.10.5 and 14.3-rc-1. There is no known workaround, other than upgrading XWiki. |
| CVE-2022-4137 | High | 2023-09-25 | No exploit published | No public exploit | A reflected cross-site scripting (XSS) vulnerability was found in the 'oob' OAuth endpoint due to incorrect null-byte handling. This issue allows a malicious link to insert an arbitrary URI into a Keycloak error page. This flaw requires a user or administrator to interact with a link in order to be vulnerable. This may compromise user details, allowing it to be changed or collected by an attacker. |
| CVE-2022-45143 | High | 2023-01-03 | No exploit published | No public exploit | The JsonErrorReportValve in Apache Tomcat 8.5.83, 9.0.40 to 9.0.68 and 10.1.0-M1 to 10.1.1 did not escape the type, message or description values. In some circumstances these are constructed from user provided data and it was therefore possible for users to supply values that invalidated or manipulated the JSON output. |
| CVE-2022-29258 | High | 2022-05-31 | No exploit published | No public exploit | XWiki Platform Filter UI provides a generic user interface to convert from a XWiki Filter input stream to an output stream with settings for each stream. Starting with versions 6.0-milestone-2 and 5.4.4 and prior to versions 12.10.11, 14.0-rc-1, 13.4.7, and 13.10.3, XWiki Platform Filter UI contains a possible cross-site scripting vector in the `Filter.FilterStreamDescriptorForm` wiki page related to pretty much all the form fields printed in the home page of the application. The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, and 13.10.3. The easiest workaround is to edit the wiki page `Filter.FilterStreamDescriptorForm` (with wiki editor) according to the instructions in the GitHub Security Advisory. |
| CVE-2022-29252 | High | 2022-05-25 | No exploit published | No public exploit | XWiki Platform Wiki UI Main Wiki is a package for managing subwikis. Starting with version 5.3-milestone-2, XWiki Platform Wiki UI Main Wiki contains a possible cross-site scripting vector in the `WikiManager.JoinWiki ` wiki page related to the "requestJoin" field. The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, and 13.10.3. The easiest available workaround is to edit the wiki page `WikiManager.JoinWiki` (with wiki editor) according to the suggestion provided in the GitHub Security Advisory. |
| CVE-2022-29251 | High | 2022-05-25 | No exploit published | No public exploit | XWiki Platform Flamingo Theme UI is a tool that allows customization and preview of any Flamingo-based skin. Starting with versions 6.2.4 and 6.3-rc-1, a possible cross-site scripting vector is present in the `FlamingoThemesCode.WebHomeSheet` wiki page related to the "newThemeName" form field. The issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, and 13.10.3. The easiest available workaround is to edit the wiki page `FlamingoThemesCode.WebHomeSheet` (with wiki editor) according to the suggestion provided in the GitHub Security Advisory. |
| CVE-2020-13654 | High | 2020-12-31 | No exploit published | Proof of concept only | XWiki Platform before 12.8 mishandles escaping in the property displayer. |
| CVE-2019-10249 | High | 2019-05-06 | No exploit published | No public exploit | All Xtext & Xtend versions prior to 2.18.0 were built using HTTP instead of HTTPS file transfer and thus the built artifacts may have been compromised. |