The Publisher portal fails to enforce proper validation on uploaded SVG files, allowing users with the Publisher role to inject malicious scripts. This weakness can be exploited by uploading a crafted SVG file, which is then stored and rendered by the application.
The security consequences include the ability for a malicious actor to redirect the victim's browser to an arbitrary website, modify the web page's UI, or retrieve information from the browser. However, the impact is mitigated as session-related sensitive cookies are protected with the httpOnly flag, preventing session hijacking.
The user search function within the management console fails to properly encode user-supplied input before rendering it in the browser. This allows an attacker to inject malicious scripts that are then executed by the user's browser in the context of the management console.
Successful exploitation enables an attacker to redirect the user's browser to a malicious website, modify the web page's user interface, or extract information from the browser. However, due to the use of the httpOnly flag on sensitive session cookies, session hijacking or similar attacks are prevented.
Apache Wicket reads texts from the application's resource bundles — a localized label, a css class name — and writes some of them into the JavaScript and the markup it generates for a component. Those texts are placed inside single-quoted JavaScript string literals and inside quoted attribute values without being escaped for that context, so a text containing a quote ends the literal or the attribute, and what follows is parsed as script or as markup in the application's origin when the page loads.
A resource bundle entry is authored for the application and does not say where the framework will write it. The same key is read by the framework into element text, where Wicket escapes it, and into the contexts below, where it did not. A text containing an apostrophe, which is ordinary in several languages, is enough to break the page; a text under the influence of another party is enough to run script.
In org.apache.wicket:wicket-core, org.apache.wicket.markup.html.form.upload.MultiFileUploadField writes the org.apache.wicket.mfu.delete message into a JavaScript string literal, and org.apache.wicket.markup.html.form.Form writes the hidden-fields css class into the class attribute of the container it renders for its hidden fields; on 8.0.0 through 8.19.0 and 9.0.0 through 9.24.0 Form#appendDefaultButtonField writes the same css class into a second container. In org.apache.wicket:wicket-extensions, UploadProgressBar writes its UploadProgressBar.starting text into a JavaScript string literal, FilterForm writes the hidden-fields css class into the class attribute of its hidden input markup, and on 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 TrapFocusBehavior writes its current css class into a JavaScript string literal.
The Content-Security-Policy that Apache Wicket 9.x and 10.x send by default does not prevent the JavaScript cases: the generated script is written into a script element carrying the per-response nonce, so the injected code is part of a script the policy admits. It does prevent an inline event handler injected through the attribute cases.
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.
Improper neutralization of input during web page generation in Apache Wicket.
Apache Wicket generates JavaScript that refers to the elements it renders, and
writes into that JavaScript two values it derives itself: a component's markup
id, and the input name of a form component, which is built from component ids.
Both are placed inside single-quoted JavaScript string literals without being
escaped for that context, so a value containing a single quote or a backslash
ends the literal, and what follows is parsed as script and runs in the
application's origin when the page loads.
A markup id is the value passed to org.apache.wicket.Component#setMarkupId(String),
or the id attribute written in the component's markup, or an id Wicket
generates, in that order. The first two are supplied by the application in an
HTML context, where both characters are legal and where Wicket escapes them
correctly when it writes the same value into the id attribute of the element; a
generated id cannot contain either. An input name is derived from the ids of the
components between the form and the form component, and a component id was
rejected only for ':' and '~'.
In org.apache.wicket:wicket-core on 9.x and 10.x,
org.apache.wicket.markup.head.OnEventHeaderItem#forMarkupId(String, String,
CharSequence) quotes the id it is given into a Wicket.Event.add call, and
components in both wicket-core and wicket-extensions reach it through
#forComponent(Component, String, CharSequence). On every affected version,
org.apache.wicket.markup.html.form.Form writes its markup id and the id of its
hidden-fields container into such literals,
org.apache.wicket.markup.html.form.FormComponentUpdatingBehavior writes an input
name, and org.apache.wicket.markup.html.form.upload.MultiFileUploadField writes
two markup ids and an input name. On 8.x, Form also writes an input name into the
action of a submitting link, and on 8.x and 9.x Form#appendDefaultButtonField
writes an input name into a name attribute with no escaping at all, so a value
containing a double quote escapes the attribute into markup.
org.apache.wicket:wicket-extensions is affected in its own right and not only
through wicket-core: AjaxEditableLabel, AjaxIndicatorAppender,
AjaxDisableComponentListener, UploadProgressBar, KittenCaptchaPanel, Palette,
FilterForm and, on 9.x and 10.x, TrapFocusBehavior and AjaxListPanel each build
their own JavaScript containing a markup id.
An application is affected where a markup id or a component id carries one of
those characters. Wicket does not put one there itself, so the value comes from
the application: an id set on a component, an id attribute in a template, or a
component id derived from data. None of those is a JavaScript context from the
application's point of view.
The Content-Security-Policy that Apache Wicket 9.x and 10.x send by default does
not prevent this. The generated script is written into a script element carrying
the per-response nonce, so the injected code is part of a script the policy
admits.
The fixed versions check an id where it enters instead of escaping each place it
is written. A component id and a markup id may no longer contain a quote, a
backquote, a backslash, braces, angle brackets, a semicolon, an ampersand or a
control character, and a markup id may not contain parentheses or square
brackets either; a component constructed with such an id, or given such a markup
id, fails with an exception.
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.
Improper neutralization of input during web page generation in Apache Wicket.
org.apache.wicket.markup.html.link.ExternalLink builds a JavaScript click handler and writes it into the tag's onclick attribute whenever the markup tag the component is bound to is not an a, link or area element. The URL held in the component's model is concatenated into a single-quoted JavaScript string literal in that handler without being escaped for that context. The same happens on the neighbouring branch, taken when popup settings are attached, where the value is concatenated into the window.open() call built by org.apache.wicket.markup.html.link.PopupSettings#getPopupJavaScript(). The only escaping applied is the markup escaping that every attribute value receives as the tag is written, which replaces an apostrophe with a character reference. A browser decodes character references in an attribute value before it compiles the event handler, so the apostrophe is restored, closes the string literal, and the rest of the model value is executed as script in the application's origin.
An application is affected where it binds an ExternalLink to a markup tag that is not an anchor, such as a button or a span, and the URL in the model holds data an attacker can influence, which is the ordinary use of the component rather than a misuse of it. Nothing runs until a user activates the element.
This issue affects Apache Wicket: from 8.0.0 through 8.19.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, which fixes the issue.
Improper neutralization of input during web page generation in Apache Wicket.
org.apache.wicket.extensions.markup.html.basic.SmartLinkLabel and org.apache.wicket.extensions.markup.html.basic.SmartLinkMultiLineLabel display a text value and turn any URL they find in it into a hyperlink. Both escape the model value and then hand the escaped text to org.apache.wicket.extensions.markup.html.basic.DefaultLinkParser, which searches it for anything of the form scheme://rest and wraps each match in an anchor whose href is the matched text, copied in as it is. The pattern accepts any scheme, and there is no list of permitted schemes anywhere on the path. A text value naming a scheme that executes script therefore becomes an anchor that executes it, in the application's origin and in the reader's own session, when the reader clicks the link. Rendering the page is not enough on its own; the link has to be activated. Escaping does not prevent this and is not the issue: the characters the payload needs are all valid in a URL and are ones that org.apache.wicket.util.string.Strings#escapeMarkup() leaves alone, and the value ends up in a URL rather than in element text, which is a context that escaping model data does not make safe.
An application is affected where it renders text it received through either of these two components. That is what they are for: they exist to linkify email addresses and web URLs found in the data an application is displaying, so untrusted input is the purpose of the feature rather than a misuse of it, and no unusual configuration is involved. No other component uses this parser, and an application that uses neither SmartLinkLabel nor SmartLinkMultiLineLabel is not affected.
On 9.x and 10.x the Content-Security-Policy Wicket sends by default admits script only from a source carrying a per-response nonce, and a URL whose scheme executes script cannot carry one, so that default policy stops the script from running. This is a property of the default policy and not of these components. An application that has weakened or disabled its Content-Security-Policy, for this or for any unrelated reason, is affected in full. Wicket 8.x has no Content-Security-Policy support at all and is affected as it stands.
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.
Improper neutralization of input during web page generation in Apache Wicket.
org.apache.wicket.ajax.AjaxNewWindowNotifyingBehavior notices that a page instance has been opened in a second browser window or tab. It asks the browser for the value of window.name, which reaches the server as the request parameter windowName, and remembers what the browser reported in a field of the behaviour. That field is part of the page's serialized state, so the remembered value stays in the page store for as long as the page instance does.
On every later render of that page instance the behaviour builds the precondition of its Ajax call by substituting the remembered value into a single-quoted JavaScript string literal, and Wicket writes that precondition into the page as raw JavaScript, because the precondition of an Ajax call listener is script supplied by the caller and is emitted without quoting or escaping. Nothing on that path escapes the value. The window name is client-supplied and Wicket applies no validation to it, so a remembered name containing a single quote ends the literal and the rest of it runs as script in the application's origin, every time that page instance is rendered.
An application is affected only where it has explicitly added AjaxNewWindowNotifyingBehavior to a component. No part of the framework installs the behaviour, so an application that does not use it is not affected. The name the behaviour generates for itself, when the browser reports no name at all, is a random UUID and is not client-supplied.
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 are recommended to upgrade to version 8.20.0, 9.25.0 or 10.12.0, which fix the issue.
Legacy (v1 to v3) Actions artifact uploads stored the request's `Content-Encoding` header unchecked in the column that is served as the artifact's `Content-Type` on download, and a value starting with `video/` or `audio/` also removed the sandboxing Content-Security-Policy. A user who can run an Actions job could upload an artifact that a browser renders as HTML on the Gitea origin when the direct artifact download URL is opened, and the URL is reachable anonymously on public repositories. A victim who opens the link runs the attacker's script with their own session, which for an administrator means control of the instance. Legacy uploads now store only the `gzip` marker, and the special serve headers are chosen only for valid media types.
The Media Library Assistant WordPress plugin before 3.44 does not escape one of its shortcode attributes before outputting it in an attribute of generated links, allowing users with the Contributor role and above to perform Stored Cross-Site Scripting attacks.
WebDyne versions from 2.014 before 3.022 for Perl reflect request parameters unescaped into form field values, allowing cross-site scripting.
The textfield, password_field and filefield tags fill their value attribute from the request parameter of the same name. WEBDYNE_CGI_AUTOESCAPE, which controls escaping of these values, defaults to off. From 2.022, WebDyne::HTML::Tiny also replaced its entity_encode method with one that returns its input unchanged, so enabling WEBDYNE_CGI_AUTOESCAPE has no effect.
A remote attacker can inject script into any page using these tags through a crafted link.
The WooCommerce Extra Product Options Pro plugin for WordPress contains a reflected cross-site scripting (XSS) vulnerability in all versions up to and including 3.3.2. This flaw arises from insufficient input sanitization and output escaping of the '<fieldname>_start' and '<fieldname>_end' parameters. The vulnerability is exploitable on product pages that have a Date & Time Range Picker extra field configured. An unauthenticated attacker can craft a malicious link that, when clicked by a user, executes arbitrary scripts in the context of the affected site.
The FlexStock – Product Stock Sync with Google Sheets for WooCommerce WordPress plugin versions up to 3.17.2 contain a stored cross-site scripting (XSS) vulnerability. This flaw arises from insufficient input sanitization and output escaping of the 'products[].post_content' parameter. Authenticated users with subscriber-level access or higher can inject malicious scripts that execute when other users view the affected pages. The vulnerability is exacerbated by the plugin exposing a REST bearer token in the Dashboard page source without proper capability checks, and the REST endpoint only validates the bearer token without verifying user capabilities.
The Debug Log Manager plugin for WordPress, versions up to and including 2.5.2, contains a stored cross-site scripting (XSS) vulnerability. This flaw arises from insufficient input sanitization and output escaping of the 'message' and 'pageUrl' parameters. An unauthenticated attacker can exploit this vulnerability if debug logging with JavaScript error logging is enabled and the attacker can obtain the publicly emitted nonce used for authentication. Successful exploitation allows injection of arbitrary scripts that execute when a user accesses the affected page.
Ninja Forms – Contact Form Builder with Calculators, Quizzes, Signatures & AI Form Builder plugin for WordPress versions up to 3.15.5 is vulnerable to reflected DOM-based cross-site scripting (XSS) via a crafted query string parameter. This vulnerability allows unauthenticated attackers to inject arbitrary scripts that execute in the context of a victim's browser if they are tricked into clicking a malicious link. The issue arises from insufficient input sanitization and output escaping, specifically when a crafted URL parameter causes the client-side code to bypass server sanitization and reconstruct field content from raw query data.
The BuddyBoss Platform WordPress plugin is affected by a stored cross-site scripting (XSS) vulnerability in the Group Name field. This vulnerability exists in all versions up to and including 3.6.0 and allows authenticated users with subscriber-level access or higher to inject malicious scripts. Exploitation requires the default setting that enables social group creation by all members; if group creation is restricted to administrators, exploitation is not possible.
The GeoDirectory – WP Business Directory Plugin and Classified Listings Directory for WordPress contains a stored cross-site scripting (XSS) vulnerability in the 'post_images' parameter affecting all versions up to 2.8.197. Authenticated users with subscriber-level access or higher can inject malicious scripts that execute in the browsers of administrators or editors when they open the pending listing's edit screen. This vulnerability enables a privilege escalation chain through normal editorial workflows.
FeedWordPress plugin for WordPress versions up to 2026.0517 is vulnerable to stored Cross-Site Scripting (XSS) via syndicated RSS/Atom feed content. The vulnerability arises because the plugin's sanitization function only removes the 'target' attribute and disables WordPress's default content filters before saving imported feed items. This allows unauthenticated attackers controlling an external feed to inject malicious scripts that execute when users view the injected content.
The WP Activity Log plugin for WordPress contains a stored cross-site scripting (XSS) vulnerability in all versions up to and including 5.6.1. This flaw arises from insufficient input sanitization and output escaping, allowing unauthenticated attackers to inject malicious scripts that execute when users view the affected pages.
The Smart Post – Post Grid, Post Carousel, Post Slider Gutenberg Blocks for Blog & News WordPress plugin contains a stored cross-site scripting (XSS) vulnerability in the 'display_name' parameter. This affects all versions up to and including 4.0.9. Authenticated users with subscriber-level access or higher can inject malicious scripts that execute when other users interact with the affected page's author filter dropdown. Exploitation requires the victim to click the attacker's author entry in a filter block, which is a normal user action requiring no special privileges.
The Content Pilot – Autoblogging & Affiliate Marketing Suite WordPress plugin versions up to 2.2.4 contain a stored cross-site scripting (XSS) vulnerability. This flaw arises because the plugin processes HTML meta descriptions from remotely fetched articles without proper sanitization before storing them as post content. An unauthenticated attacker controlling an RSS feed configured in a campaign can inject malicious scripts that execute when users view the affected posts.