CVE-2018-19943
QNAP NAS File Station Cross-Site Scripting Vulnerability
CVSS
8.0
High
EPSS
17.7%
p97
KEV
YES
May 24, 2022
Exploit Today
79
0-100
Published: Oct 28, 2020 · Last modified: Aug 13, 2026 · CWE-79 · CWE-80
17.7%EPSS · 30 days17.7%
2026-08-022026-08-31
Product
QNAP / Network Attached Storage (NAS)
Vulnerability
QNAP NAS File Station Cross-Site Scripting Vulnerability
Added to KEV
May 24, 2022
Remediate by
Jun 14, 2022
Known ransomware use
Yes
Summary description
A cross-site scripting vulnerability affecting QNAP NAS File Station could allow remote attackers to inject malicious code.
Required action
Apply updates per vendor instructions.
Notes
https://nvd.nist.gov/vuln/detail/CVE-2018-19943
If exploited, this cross-site scripting vulnerability could allow remote attackers to inject malicious code. QNAP has already fixed these issues in the following QTS versions. QTS 4.4.2.1270 build 20200410 and later QTS 4.4.1.1261 build 20200330 and later QTS 4.3.6.1263 build 20200330 and later QTS 4.3.4.1282 build 20200408 and later QTS 4.3.3.1252 build 20200409 and later QTS 4.2.6 build 20200421 and later
CVECVSSEPSSKEVRExploitTitleMod.
CVE-2026-76984——
——0Improper neutralization of input during web page generation in Apache Wicket.
org.apache.wicket.markup.head.MetaDataHeaderItem generates <meta> and <link> header tags. It escaped the attribute names it wrote, but ran the attribute values through a replacement of " with \". A backslash before a double quote means nothing in HTML, so a value containing a double quote ends its own attribute and what follows is parsed as further attributes of the generated tag.
An application is affected where it supplies an attribute value holding data an attacker can influence, through addTagAttribute or the forMetaTag and forLinkTag factory methods. A value may be given as an IModel, so it is not necessarily a literal.
There is no setting to change; an application can only avoid supplying a value that contains a double quote. Note that these values have never been escaped effectively: before the change released in 6.24.0, 7.4.0 and 8.0.0 they were written with no escaping at all.
This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 6.17.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.2hCVE-2026-76983——
——0Improper neutralization of input during web page generation in Apache Wicket.
The <wicket:label> tag is provided by org.apache.wicket.markup.html.form.AutoLabelTextResolver, which is registered by default in every WebApplication. The resolver writes the label it finds into the markup as it is, and reads no escaping setting at all, so markup in a label is rendered as markup.
When the label comes from the labelled component's label model, set through FormComponent#setLabel(IModel), it is written to the markup unescaped. An application is affected where the label of a form component holds data an attacker can influence. Wicket cannot determine where a model value comes from, so whether it reaches the page from a request or from storage is a property of the application.
There is no workaround. Unlike every other rendering path in Wicket, the resolver never consulted the escape-model-strings setting, so an application had no way to ask for the label to be escaped.
The body of a <wicket:label> tag is markup by design and is not affected; it remains the supported way to place markup in a label.
This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 1.5.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.2hCVE-2026-76982——
——0Improper neutralization of input during web page generation in Apache Wicket.
org.apache.wicket.markup.html.form.Button clears the escape-model-strings flag in its constructor, so that the value attribute it writes is not encoded twice — ComponentTag already encodes attribute values when it writes the tag. That reasoning holds only for the attribute. When the component is attached to a <button> element rather than an <input>, it writes its model object into the element body instead, and nothing encodes an element body, so markup in the model is rendered as markup.
An application is affected where it renders a Button on a <button> element and that button's model holds data an attacker can influence. Wicket cannot determine where a model value comes from, so whether it reaches the page from a request or from storage is a property of the application. The subclasses that inherit this constructor — AjaxButton, AjaxFallbackButton and WizardButton — are affected on the same terms.
As a workaround, calling setEscapeModelStrings(true) on a button that renders as a <button> element escapes the body correctly, and does not cause double encoding, because the value attribute is written only for <input> elements.
This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 6.25.0 and 7.5.0 onwards are also affected.
Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.2hCVE-2026-75802——
——0AjaxEditableChoiceLabel in wicket-extensions, when constructed with a non-null IChoiceRenderer, writes the display value obtained from that renderer into the label's markup without applying the HTML escaping Wicket performs by default for component model values. An attacker who can influence the choice or model data rendered by such a label can inject HTML or script that executes in the browser of any user who views the page. The same value is correctly escaped when the component's dropdown editor renders it as an option, so only the label rendering is affected.
AjaxEditableLabel, AjaxEditableChoiceLabel and AjaxEditableMultiLineLabel write the value returned by the protected defaultNullLabel() method into the label's markup the same way when the component's model is empty, while the model value they show otherwise is escaped. The default implementation returns a constant, so an application is affected where it overrides that method and returns a value an attacker can influence.
Neither value could be escaped by configuration, because escapeModelStrings had no effect on any of the three components: it is read by the label they render with rather than by the component itself, and nothing carried the setting across.
This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases are also affected; the display value from the renderer since 6.22.0 and the null label since 1.4.0. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.2hCVE-2026-828815.4 MED—
——0Aix-DB through 1.2.4 renders markdown with raw HTML enabled into v-html bindings without sanitization, allowing stored cross-site scripting attacks. Attackers can inject malicious HTML and JavaScript through markdown content in chat responses, skill descriptions, or knowledge messages that execute in users' browsers when viewed.4hCVE-2026-828686.1 MED4.9%
——1@pdfme/schemas before 5.5.9 contains a cross-site scripting vulnerability in the SVG schema plugin that renders user-supplied SVG content directly to innerHTML without sanitization. Attackers can inject malicious SVG with embedded scripts, event handlers, or foreignObject elements to execute arbitrary JavaScript in users' browsers when viewing or filling templates.4h