Apache Wicket vulnerabilities

Apache Wicket generates JavaScript that references rendered elements, placing markup ids and form input names inside single-quoted JavaScript string literals without proper escaping. A value containing a single quote or backslash can terminate the literal and inject script that runs in the application's origin when the page loads. The issue affects wicket-core and wicket-extensions in versions 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, and 10.0.0 through 10.11.0.

Apache Wicket 10.10.0, 10.11.0 and 9.24.0 do not set Content-Security-Policy headers on a page whose render request handler is wrapped in more than one IRequestHandlerDelegate. The framework unwraps only a single delegate level when deciding whether a request renders a page, so with a deeper chain, for example an application-provided delegating request mapper combined with CryptoMapper, the page is served without any CSP header even though CSP is enabled, and no error or warning is raised. The nonce-based protection Wicket applies to inline scripts and styles, together with any other CSP directives configured by the application, is thereby lost for those pages, exposing them to content injection the policy was meant to prevent. Applications on stock Wicket that do not wrap request handlers themselves are not affected. Versions before 10.10.0 and 9.24.0 handled nested delegates correctly.

A cross-site scripting (XSS) vulnerability in Apache Wicket arises from improper neutralization of input during web page generation. The ExternalLink component, when bound to a non-anchor element, concatenates the model URL into a JavaScript string literal in the onclick attribute without proper escaping, allowing script execution in the application's origin.

Apache Wicket has an incorrect behavior order: a file path is validated by PackageResourceGuard before the framework appends the style, variation and locale attributes. As a result, the file opened may differ from the file approved by the guard, allowing disclosure of HTML markup templates of components whose class names contain an underscore (e.g. Report_v2).

In Apache Wicket, PackageResourceGuard incorrectly allows component markup templates to be served as package resources when wicket-core is loaded by a class loader that cannot see the application's classes. In such a setup the check for a class file beside the template fails, and a request for the package resource URL returns the component's markup template with status 200. Disclosed content is developer-authored template material such as component structure, comments, inline script, and named endpoints.

A vulnerability in Apache Wicket affects AbstractFileUploadResource, the server side of the form-less upload offered by FileUploadToResourceField. The request size, single-part size and part-count limits are taken from request parameters (maxSize, fileMaxSize, fileCountMax) instead of application configuration, so a client can raise or omit them. The resource carries no authorization annotation, so by default requests need no authentication.

A vulnerability in Apache Wicket affects the FileUploadToResourceField component, whose Ajax callback reads the filesInfo request parameter without binding it to an actual upload. The UploadInfo#get() method allocates a byte array based on the client-supplied size, allowing a single request to exhaust the JVM heap, while negative values trigger a NegativeArraySizeException.

A vulnerability in Apache Wicket affects the JavaScriptUtils#escapeQuotes() method, which fails to escape the backslash character before quotes. A value containing a backslash immediately before a quote results in the quote being left unescaped, closing the JavaScript string literal and allowing JavaScript injection. The issue occurs when an application uses this method to place attacker-influenced data inside a JavaScript string literal, including via the AjaxEditableLabel component.

Cross-site scripting (XSS) vulnerability in the SmartLinkLabel and SmartLinkMultiLineLabel components of Apache Wicket. These components turn URLs found in text into hyperlinks and accept any URL scheme, including script-executing schemes such as javascript:. Escaping the model value does not help because the payload ends up in the href attribute rather than in element text.

A cross-site scripting (XSS) vulnerability in Apache Wicket affects the AjaxNewWindowNotifyingBehavior, which stores the client-supplied window.name value in the page's serialized state. That value is later substituted without escaping into a single-quoted JavaScript string literal in the Ajax call precondition, allowing arbitrary script execution in the application's origin on every render of the page instance. Only applications that explicitly add this behavior to a component are affected.

Apache Wicket writes texts from resource bundles (labels, CSS class names) into generated JavaScript and markup without context-appropriate escaping. A text containing a quote can terminate the literal or attribute and be parsed as script or markup in the application's origin. Affected components include MultiFileUploadField, Form, UploadProgressBar, FilterForm and TrapFocusBehavior in versions 8.0.0–8.19.0, 9.0.0–9.24.0 and 10.0.0–10.11.0.

Apache Wicket performs security checks in the wrong order in ResourceIsolationRequestCycleListener: the target page is obtained before the resource isolation policies are consulted, because those policies are passed that page. As a result, RestartResponseAtInterceptPageException is thrown from inside the listener before any policy runs, so a cross-origin request is not refused. The stored destination URL, including its query string, is later used after sign-in, allowing another origin to influence form field values passed to Form#onSubmit().

Session fixation in Apache Wicket affects the AuthenticatedWebSession class and its signIn(String, String) method. The session id is renewed only on the first sign-in transition and not when an already signed-in session authenticates again, even though the method returns true in both cases. Exploitation requires an attacker to plant a chosen session id in the victim's browser, e.g. through control of a host under the same registrable domain or a container configured to carry the session id in the URL.

Apache Wicket fails to enforce resource authorization (isResourceAuthorized() or the @AuthorizeResource annotation) in ResourceLink, Image, ImageButton and AjaxDownloadBehavior components when a resource is passed as an IResource instance. In that case the resource is served without the permission check, while the same control works when a ResourceReference is used. ExportToolbar is also affected because it builds its export links from IResource instances.

Apache Wicket has a missing authorization flaw that allows a component's listener to be invoked even when the authorization strategy denied the RENDER action for it. A crafted or even standard listener URL without a page identifier skips the render phase and Component#configure(), leaving the visibility flag at its constructor default. Components hidden or disabled in Component#onConfigure() are equally exposed.

The vulnerability in Apache Wicket is insufficient session expiration in native WebSocket support. A WebSocket connection keeps a copy of the HTTP session from when it was opened, so invalidating the session via the container (idle timeout, logout, filter invalidate) does not end the connection — subsequent frames still resolve the revoked identity and its attributes.

Apache Wicket fails to check authorization before invoking onMessage() callbacks in WebSocketBehavior. A client message is delivered to every WebSocketBehavior on the page, even when the component it is attached to is hidden, disabled, or denied by IAuthorizationStrategy — unlike Ajax behaviors, which perform this check.

Apache Wicket versions 10.3.0 through 10.11.0 contain a missing authorization vulnerability in form handling. The form resolves the submitting component from request parameters and passes it directly to onFormSubmitted(), skipping the visibility and enablement check. As a result, a request can invoke actions of a button or link that the application withheld.

Apache Wicket is missing authorization in its native WebSocket support. WebSocketMessageBroadcastHandler calls WebSocketResource#onPayload() directly without consulting IAuthorizationStrategy#isResourceAuthorized(), and the @AuthorizeResource annotation has no effect. A caller only needs a bound Wicket session and the resource name (exposed in the page that opens the connection) to reach all resource callbacks, including onConnect() and onMessage().

Apache Wicket before 1.5.12, 6.x before 6.17.0, and 7.x before 7.0.0-M3 might allow remote attackers to obtain sensitive information via identifiers for storing page markup for temporary user sessions.

Apache Wicket versions 6.x before 6.25.0, 7.x before 7.5.0, and 8.0.0-M1 contain a security vulnerability that improperly handles CSRF prevention, failing to detect some cross-origin requests. The issue also involves not checking all Wicket server-side targets.

Apache Wicket before 1.5.13, 6.x before 6.19.0, and 7.x before 7.0.0-M5 make it easier for attackers to defeat a cryptographic protection mechanism and predict encrypted URLs by leveraging use of CryptoMapper as the default encryption provider.

The DiskFileItem class in Apache Wicket 6.x before 6.25.0 and 1.5.x before 1.5.17 allows remote attackers to cause a denial of service (infinite loop) and write to, move, and delete files with the permissions of DiskFileItem. Additionally, if running on a Java VM before 1.3.1, it can execute arbitrary code via a crafted serialized Java object.

A cross-site scripting (XSS) vulnerability was found in Apache Wicket in AbstractSingleSelectChoice (base class of DropDownChoice). The default option body is written without escaping, while other options are escaped. Applications overriding getNullValidDisplayValue() or getNullKeyDisplayValue() with attacker-influenced data are affected. Versions 8.0.0-8.18.0, 9.0.0-9.23.0, 10.0.0-10.10.0 are affected.

A cross-site scripting (XSS) vulnerability was found in Apache Wicket in AbstractOptions (renders option lists in Palette). Attribute names and values from getAdditionalAttributes are written without escaping. Applications overriding getAdditionalAttributesForChoices, getAdditionalAttributesForSelection, or getAdditionalAttributes with attacker-influenced data are affected. Versions 8.0.0-8.18.0, 9.0.0-9.23.0, 10.0.0-10.10.0 are affected.

In Apache Wicket, the MetaDataHeaderItem component improperly neutralizes input during web page generation. Attribute values in <meta> and <link> tags are not properly escaped, allowing injection of additional attributes. Affects versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0.

In Apache Wicket, the <wicket:label> tag is rendered without escaping, allowing HTML injection if the label comes from a model containing attacker-controlled data. Affects versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0.

XSS vulnerability in Apache Wicket affects the Button component rendered as a <button> element. The constructor clears the escape-model-strings flag, so the model is not encoded when written to the element body, allowing markup injection.

XSS vulnerability in Apache Wicket affects AjaxEditableChoiceLabel, AjaxEditableLabel, and AjaxEditableMultiLineLabel components. Displayed label values are not properly escaped, allowing an attacker to inject HTML or scripts. Affected versions: 8.0.0-8.18.0, 9.0.0-9.23.0, 10.0.0-10.10.0.

The vulnerability in Apache Wicket concerns the CSRF protection mechanism (ResourceIsolationRequestCycleListener). The default FetchMetadataResourceIsolationPolicy incorrectly allows simple top-level navigations and same-site requests, enabling an attacker to trigger component listeners within an authenticated session. Affected versions are 9.1.0 through 9.23.0 and 10.0.0 through 10.10.0.

A vulnerability in Apache Wicket allows bypassing file size and count limits when a multipart request has already been consumed by another component. Wicket then reads uploads via HttpServletRequest#getParts() without applying per-file and file-count limits, allowing larger or more numerous files than permitted. Additionally, a part without a Content-Type header is fully read into memory, potentially causing excessive resource consumption.

A vulnerability in Apache Wicket allows an unauthenticated remote attacker to read files from the web application, including files under WEB-INF that the servlet container would not otherwise serve. The attack exploits improper validation of resource URL attributes, which are spliced into the resource lookup path without checking for path separators.

A vulnerability in Apache Wicket due to use of insufficiently random values and protection mechanism failure. Affects versions 9.0.0 through 9.23.0 and 10.0.0 through 10.9.0. Upgrade to version 10.10.0 is recommended.

A Cross-Site Scripting (XSS) vulnerability in Apache Wicket due to improper input neutralization during web page generation. Affects versions 9.0.0 through 9.23.0 and 10.0.0 through 10.9.0. Upgrade to version 10.10.0 is recommended.

In Apache Wicket, FolderUploadsFileManager does not validate or sanitize the uploadFieldId parameter or clientFileName before constructing file paths. This allows an unauthenticated attacker to write arbitrary files outside the intended upload directory or read files from arbitrary locations on the server. The issue affects versions 8.0.0–8.17.0, 9.0.0–9.22.0, and 10.0.0–10.8.0.

Apache Wicket has a vulnerability that exposes sensitive information to unauthorized actors. This affects versions from 8.0.0 to 8.17.0, from 9.0.0 to 9.22.0, and from 10.0.0 to 10.8.0.

Apache Wicket contains a Cross-site Scripting (XSS) vulnerability due to improper neutralization of input during web page generation. The issue affects versions from 8.0.0 through 8.17.0, 9.0.0, and from 10.0.0 through 10.8.0.