Apache Wicket
Monthly
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 allows text read from the application's resource bundles to escape the single-quoted JavaScript string literals and quoted HTML attribute values the framework generates, so a quote in that text ends the literal or attribute and what follows is parsed as script or markup in the application's origin when the page loads. Only bundle-sourced values rendered by specific components are affected - the org.apache.wicket.mfu.delete message in MultiFileUploadField, the hidden-fields CSS class in Form (and in Form#appendDefaultButtonField on the 8.x and 9.x ranges) and FilterForm, the UploadProgressBar.starting text, and TrapFocusBehavior's current CSS class on 9.0.0-9.24.0 and 10.0.0-10.11.0 - so exploitation depends on a non-default situation in which a bundle entry is influenced by another party, although an ordinary apostrophe in a legitimate translation is enough to break page rendering. The unauthenticated network vector requires the victim to load the generated page; no public exploit identified at time of analysis, and the default Content-Security-Policy in Wicket 9.x and 10.x blocks the attribute-injection cases but not the JavaScript string-literal cases because the generated script carries the per-response nonce the policy trusts.
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 lets a value that the application places into a component markup id or a component id break out of a single-quoted JavaScript string literal that Wicket itself generates, so the injected script executes in the application's origin when the page loads. Exploitation is conditional: Wicket never generates a quote or backslash in these identifiers, so the tainted value must originate from application data flow (a value passed to Component#setMarkupId, an id attribute in a template, or a component id derived from data), and a victim must load the affected rendered page; the supplied independent assessment scores this as CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N, i.e. a genuine but conditional flaw rather than a trivially reachable one. No KEV listing is present and no public exploit code is identified in the available intelligence; the vendor's own advisory carries a CVSS 4.0 score of 7.6 and a this_week remediation priority.
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0 lets remote attackers get script executed in the application's origin when an ExternalLink component is bound to a markup tag that is not an a, link or area element (such as a button or span) and the URL held in the component's model contains attacker-influenceable data, which the vendor describes as the component's ordinary use rather than a misuse. The URL is concatenated unescaped into a single-quoted JavaScript string inside the generated onclick handler, and also into the window.open() call built by PopupSettings when popup settings are attached; only attribute-level markup escaping is applied, and the browser decodes the apostrophe character reference before compiling the handler, restoring the quote and closing the literal. Exploitation is unauthenticated and remote but conditional: nothing executes until a user activates the affected element, and the deployment must bind the component to a non-anchor tag, which the Apache reporter scores as CVSS 4.0 7.4 (AT:P, UI:A); no public exploit identified at time of analysis.
Apache Wicket's form-less upload endpoint (AbstractFileUploadResource, the server side of FileUploadToResourceField, or a manually mounted FileUploadResourceReference) takes its upload bounds from client-supplied request parameters - maxSize, fileMaxSize and fileCountMax - instead of from the values the application configured via setMaxSize(), setFileMaxSize() and setFileCountMax(). A client that supplies a very large maxSize, or omits the per-part and part-count parameters, can therefore drive one repeatable request to spool unlimited data to disk or read non-file parts into the heap, exhausting disk or memory. Affected releases are 9.14.0 through 9.24.0 and 10.0.0 through 10.9.1; the 8.x line has no such resource, and the ordinary Form/FileUploadField and AjaxFileDropBehavior paths are unaffected because they read limits from the component. Rated CVSS 4.0 8.3 (with attack requirements present, AT:P, since the application must deliberately use or mount this resource) and rated 'this_week' by priority; no public exploit code was identified at time of analysis.
Heap-exhaustion denial of service in Apache Wicket 9.14.0 through 9.24.0 and 10.0.0 through 10.11.0, reachable without authentication (CVSS 4.0 PR:N) by any client that can load a page rendering the FileUploadToResourceField callback URL. The Ajax callback trusts the client-supplied filesInfo JSON without binding it to a real upload, and UploadInfo#get() allocates a byte array sized from the attacker-controlled UploadInfo#getSize() before opening any file, so a single small request can cost close to two gigabytes of heap and repeated requests exhaust the JVM heap for all requests; a size that converts to a negative int instead throws an uncaught NegativeArraySizeException into the application. Exploitation is narrowly scoped: the application must deliberately extend and mount this component (not the ordinary FileUploadField/Form path) and must call UploadInfo#get(); no public exploit code or active exploitation was identified at time of analysis, and the priority label is this_week.
Apache Wicket's public JavaScriptUtils.escapeQuotes() helper fails to escape backslashes before quotes, so attacker-influenced data containing a backslash immediately before a quote can terminate a JavaScript string literal and run script in the application's origin and the viewing user's session. The flaw affects Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0, but exploitation is conditional: an application must itself place the method's output inside a JavaScript string literal, and the bundled AjaxEditableLabel path additionally requires a custom validation message that interpolates submitted input or another attacker-controlled variable. No public exploit was identified at time of analysis, and the issue requires user interaction because the victim must view the page that renders the vulnerable response.
Cross-site scripting in Apache Wicket's SmartLinkLabel and SmartLinkMultiLineLabel components turns attacker-influenced text into anchors whose href is copied verbatim, so a value naming a script-executing scheme becomes a clickable script link in the application's origin and the reader's session. Affected are Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0, but only applications that render untrusted text through one of those two components; no other component uses DefaultLinkParser. Exploitation is not a drive-by: the reader must click the injected link, and on 9.x and 10.x the default nonce-based Content-Security-Policy blocks the script unless the deployment has weakened or disabled it, while 8.x has no CSP support and is exposed as it stands. No public exploit code was identified at time of analysis; fixed releases are 8.20.0, 9.25.0 and 10.12.0.
Stored cross-site scripting in Apache Wicket's AjaxNewWindowNotifyingBehavior allows a client-supplied browser window name to be persisted in a page instance's serialized state and later emitted as raw, unescaped JavaScript, executing in the application's origin each time that page instance is rendered. Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 are affected, but only applications that explicitly added the behaviour to a component are exposed, since the framework never installs it; the vector is unauthenticated (PR:N) yet requires victim interaction and specific attack prerequisites, so real-world priority is moderate rather than urgent. No public exploit identified at time of analysis, and the vendor has released fixes in 8.20.0, 9.25.0 and 10.12.0.
Session fixation in Apache Wicket's role-based authentication module leaves the container session id unchanged when an already-signed-in session authenticates a second time, so an attacker-planted session id can survive a successful login. Affected releases are 8.18.0 through 8.19.0, 9.23.0 through 9.24.0 and 10.9.0 through 10.11.0, and exploitation requires an application that authenticates via AuthenticatedWebSession, permits re-authentication of a signed-in session (step-up prompt, account switch, or a sign-in form still reachable after login), and an attacker who can plant a session id in the victim's browser and has already authenticated that session with a valid account (PR:L, UI:A). Successful exploitation yields high confidentiality and integrity impact within the vulnerable application; the vendor-released fix is available in 8.20.0, 9.25.0 and 10.12.0, and no public exploit has been identified at time of analysis. The CVSS 4.0 base score is 7.2 (High), though the vector is tempered by AT:P (an attack requirement outside the attacker's control) alongside PR:L and UI:A.
Pages rendered by Apache Wicket 10.10.0, 10.11.0 and 9.24.0 can be served without any Content-Security-Policy header when the page's render request handler is wrapped in more than one IRequestHandlerDelegate, because the framework unwraps only a single delegate level when deciding whether a request renders a page; with a deeper chain - for example an application-provided delegating request mapper combined with CryptoMapper - CSP is silently skipped with no error or warning, and the nonce-based protection for inline scripts and styles plus any other configured directives are lost for those pages. Only applications that wrap request handlers themselves in a non-default deployment are exposed; stock Wicket applications are not affected, and because the defect removes a protective control rather than providing an injection primitive, actual content injection additionally requires a separate injection vector on such a page and a victim rendering it (passive user interaction). This is a low-severity, configuration-dependent regression - versions before 10.10.0 and 9.24.0 handled nested delegates correctly - and no public exploit has been identified at time of analysis, with CISA KEV status absent and the vulnerability not listed as actively exploited.
Apache Wicket 8.x through 10.x can be made to return the HTML markup template of an application's own component class instead of the static file that the package resource guard approved, giving a remote unauthenticated attacker read access to developer-authored template source. Exposure is conditional: the application must contain a component class whose simple name includes an underscore and for which no shorter underscore-delimited prefix is itself a class (for example Report_v2 or Wizard_Step1), and disclosure is confined to HTML files in that component's own package - component structure, developer comments, conditional markup, inline script and named endpoints, but no user data, credentials or session material. No public exploit code is identified at time of analysis, and the vendor has released fixed versions 8.20.0, 9.25.0 and 10.12.0.
Markup template disclosure in Apache Wicket 8.0.0-8.19.0, 9.0.0-9.24.0 and 10.0.0-10.11.0 allows unauthenticated remote attackers to fetch a component's HTML markup template over HTTP with status 200 by requesting its package-resource URL. The flaw only manifests in non-standard deployments where wicket-core is loaded by a class loader that cannot see the application's component classes (shared servlet-container library directory, EAR lib directory with the WAR-hosted application, application-server global module, or OSGi bundle); the ordinary WAR layout with wicket-core in WEB-INF/lib is not affected. Impact is strictly read-only disclosure of developer-authored template content - component structure, comments, conditionally rendered markup, inline script and named endpoints - with no user data, credentials or session material reachable and no integrity or availability effect; no public exploit code was identified at time of analysis and there is no CISA KEV listing, and the priority signal is this_month rather than immediate action.
Apache Wicket's resource authorization check is bypassed when a restricted resource is served through a component that was constructed with an IResource instance instead of a ResourceReference. The framework enforces IAuthorizationStrategy#isResourceAuthorized() and the wicket-auth-roles @AuthorizeResource annotation at only one point - ResourceRequestHandler - so ResourceLink(String, IResource), Image, ImageButton and AjaxDownloadBehavior call IResource#respond() directly from their own request listener and never consult the strategy; for Image and ImageButton the listener URL is written into the tag's src attribute, so a browser fetches the protected content with no user action. Affected versions are 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0; only applications that actually restrict a resource and then hand that same instance to one of these components are exposed, and ExportToolbar in wicket-extensions triggers the pattern for data-table exports. No public exploit code and no confirmed active exploitation were identified at time of analysis, and EPSS data was not provided; severity is rated medium (vendor CVSS 4.0 base 6.3).
Missing authorization in Apache Wicket 8.x, 9.x and 10.x allows unauthenticated remote attackers to invoke a component's IRequestListener even though the application's IAuthorizationStrategy denied the Component.RENDER action for that component, or even though the application set the component invisible or disabled in Component#onConfigure(). The flaw is reachable with nothing more than a crafted or simply unmodified request, because Wicket can build a listener URL without a page identifier and then invokes the listener on a freshly constructed page instance before any render pass has populated the authorization-derived visibility flag; the impact is limited to integrity (low), with no confidentiality or availability effect assessed. Exploitation requires a Wicket application that withholds an individual component via a RENDER denial or via visibility/enablement set in onConfigure(), on a page that is reachable from a bookmarkable or mounted URL and has a public no-argument or PageParameters constructor; signals are moderate and broadly consistent, and no public exploit identified at time of analysis.
Apache Wicket's native WebSocket support keeps serving a session after the servlet container has ended it: because each connection resolves its Wicket session from a copy taken at handshake time, an authenticated user holding an open socket continues to be treated as signed in - with the original session attributes and, in wicket-auth-roles applications, the signed-in state - for as long as the connection stays open. Affected are Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 (older unsupported 6.x releases from 6.0.0 are also affected), but only where an application uses native WebSocket pages or WebSocketResource endpoints that require an authenticated session and terminates sessions through the container (idle timeout, filter or security-framework HttpSession#invalidate(), container-managed logout, or session replacement) rather than through Wicket. Severity is low (CVSS 4.0 base score 2.3; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N) since the attacker must already hold such an authenticated connection, and no public exploit has been identified at time of analysis.
Missing authorization in Apache Wicket's native WebSocket support lets a client's text and binary messages reach a WebSocketBehavior's onMessage() callbacks even when the component that behavior is attached to is hidden, disabled, or denied by the application's IAuthorizationStrategy. Only applications that override onMessage() on a WebSocketBehavior attached to (or beneath) such a restricted component are affected, and an attacker must hold their own valid session and open their own page containing that component, since messages are delivered only within the client's own page store and never to another user's session or connection. Affected releases are 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 (with older unsupported 6.x-and-later releases also affected); no public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and priority signals point to monitoring rather than urgent action.
Missing authorization in Apache Wicket 10.3.0 through 10.11.0 allows a remote unauthenticated caller to invoke the server-side callbacks of a form submit control that the application deliberately withheld from them, because Form#findSubmitter() resolves the submitter from the request parameter name alone and the visible/enabled check runs only when no submitter is supplied. Where a Button or SubmitLink is hidden, disabled, or denied by IAuthorizationStrategy while the enclosing form stays available, a request naming that control still reaches its onSubmit() and onAfterSubmit(), and its onError() when validation fails - reaching onSubmit()/onAfterSubmit() with no validation at all when the button sets setDefaultFormProcessing(false). No public exploit code has been identified at time of analysis; Ajax submissions through AjaxFormSubmitBehavior, AjaxButton and AjaxSubmitLink are not affected, restrictions on the form or page are not bypassed, and the 9.x and 8.x lines are unaffected because the behaviour was introduced in 10.3.0.
Missing authorization in Apache Wicket's native WebSocket transport allows a remote caller who holds a bound Wicket session to invoke the callbacks of a registered `WebSocketResource` shared resource without the application's `IAuthorizationStrategy` ever being consulted, so class-level restrictions such as `@AuthorizeResource` are silently ignored. The flaw is unauthenticated per the CVSS vector (PR:N) and affects Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, 10.0.0 through 10.11.0, and older unsupported 7.x releases, but only where an application registers a `WebSocketResource` as a shared resource and relies on the authorization strategy to protect it. Impact is bounded to whatever the targeted resource's `onConnect()` and `onMessage()` callbacks do with an attacker-supplied text or binary message, and because the connection registers under the caller's own session there is no path to another user's connection; no public exploit code has been identified at time of analysis, and the vendor has released fixed versions 8.20.0, 9.25.0 and 10.12.0.
Unauthenticated remote attackers can partially read and modify data in Apache Wicket versions 9.0.0 through 9.23.0 and 10.0.0 through 10.9.0 due to a protection mechanism that relies on insufficiently random values. The vulnerability is automatable with low attack complexity and no user interaction, though no active exploitation or public exploit code has been observed at this time. While the technical impact is limited to partial confidentiality and integrity compromise, the widespread enterprise use of Wicket makes it a moderate priority for patching.
Cross-site scripting (XSS) in Apache Wicket versions 9.0.0-9.23.0 and 10.0.0-10.9.0 allows attackers to inject client-side scripts into pages rendered by the affected application, potentially compromising user sessions or redirecting victims. The vulnerability arises from insufficient neutralization of user input during HTML generation, enabling script injection via crafted URLs or form submissions. No public exploit is known, but upgrading to version 10.10.0 eliminates the issue.
Path traversal vulnerability in Apache Wicket's FolderUploadsFileManager allows unauthenticated attackers to read arbitrary files or write files outside the intended upload directory by exploiting unsanitized uploadFieldId and clientFileName parameters. Affected versions 8.0.0-8.17.0, 9.0.0-9.22.0, and 10.0.0-10.8.0 are vulnerable to remote file access and modification without authentication or user interaction. Vendor-released patch available in version 10.9.0.
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 allows text read from the application's resource bundles to escape the single-quoted JavaScript string literals and quoted HTML attribute values the framework generates, so a quote in that text ends the literal or attribute and what follows is parsed as script or markup in the application's origin when the page loads. Only bundle-sourced values rendered by specific components are affected - the org.apache.wicket.mfu.delete message in MultiFileUploadField, the hidden-fields CSS class in Form (and in Form#appendDefaultButtonField on the 8.x and 9.x ranges) and FilterForm, the UploadProgressBar.starting text, and TrapFocusBehavior's current CSS class on 9.0.0-9.24.0 and 10.0.0-10.11.0 - so exploitation depends on a non-default situation in which a bundle entry is influenced by another party, although an ordinary apostrophe in a legitimate translation is enough to break page rendering. The unauthenticated network vector requires the victim to load the generated page; no public exploit identified at time of analysis, and the default Content-Security-Policy in Wicket 9.x and 10.x blocks the attribute-injection cases but not the JavaScript string-literal cases because the generated script carries the per-response nonce the policy trusts.
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 lets a value that the application places into a component markup id or a component id break out of a single-quoted JavaScript string literal that Wicket itself generates, so the injected script executes in the application's origin when the page loads. Exploitation is conditional: Wicket never generates a quote or backslash in these identifiers, so the tainted value must originate from application data flow (a value passed to Component#setMarkupId, an id attribute in a template, or a component id derived from data), and a victim must load the affected rendered page; the supplied independent assessment scores this as CVSS 3.1 AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N, i.e. a genuine but conditional flaw rather than a trivially reachable one. No KEV listing is present and no public exploit code is identified in the available intelligence; the vendor's own advisory carries a CVSS 4.0 score of 7.6 and a this_week remediation priority.
Cross-site scripting in Apache Wicket 8.0.0 through 8.19.0 lets remote attackers get script executed in the application's origin when an ExternalLink component is bound to a markup tag that is not an a, link or area element (such as a button or span) and the URL held in the component's model contains attacker-influenceable data, which the vendor describes as the component's ordinary use rather than a misuse. The URL is concatenated unescaped into a single-quoted JavaScript string inside the generated onclick handler, and also into the window.open() call built by PopupSettings when popup settings are attached; only attribute-level markup escaping is applied, and the browser decodes the apostrophe character reference before compiling the handler, restoring the quote and closing the literal. Exploitation is unauthenticated and remote but conditional: nothing executes until a user activates the affected element, and the deployment must bind the component to a non-anchor tag, which the Apache reporter scores as CVSS 4.0 7.4 (AT:P, UI:A); no public exploit identified at time of analysis.
Apache Wicket's form-less upload endpoint (AbstractFileUploadResource, the server side of FileUploadToResourceField, or a manually mounted FileUploadResourceReference) takes its upload bounds from client-supplied request parameters - maxSize, fileMaxSize and fileCountMax - instead of from the values the application configured via setMaxSize(), setFileMaxSize() and setFileCountMax(). A client that supplies a very large maxSize, or omits the per-part and part-count parameters, can therefore drive one repeatable request to spool unlimited data to disk or read non-file parts into the heap, exhausting disk or memory. Affected releases are 9.14.0 through 9.24.0 and 10.0.0 through 10.9.1; the 8.x line has no such resource, and the ordinary Form/FileUploadField and AjaxFileDropBehavior paths are unaffected because they read limits from the component. Rated CVSS 4.0 8.3 (with attack requirements present, AT:P, since the application must deliberately use or mount this resource) and rated 'this_week' by priority; no public exploit code was identified at time of analysis.
Heap-exhaustion denial of service in Apache Wicket 9.14.0 through 9.24.0 and 10.0.0 through 10.11.0, reachable without authentication (CVSS 4.0 PR:N) by any client that can load a page rendering the FileUploadToResourceField callback URL. The Ajax callback trusts the client-supplied filesInfo JSON without binding it to a real upload, and UploadInfo#get() allocates a byte array sized from the attacker-controlled UploadInfo#getSize() before opening any file, so a single small request can cost close to two gigabytes of heap and repeated requests exhaust the JVM heap for all requests; a size that converts to a negative int instead throws an uncaught NegativeArraySizeException into the application. Exploitation is narrowly scoped: the application must deliberately extend and mount this component (not the ordinary FileUploadField/Form path) and must call UploadInfo#get(); no public exploit code or active exploitation was identified at time of analysis, and the priority label is this_week.
Apache Wicket's public JavaScriptUtils.escapeQuotes() helper fails to escape backslashes before quotes, so attacker-influenced data containing a backslash immediately before a quote can terminate a JavaScript string literal and run script in the application's origin and the viewing user's session. The flaw affects Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0, but exploitation is conditional: an application must itself place the method's output inside a JavaScript string literal, and the bundled AjaxEditableLabel path additionally requires a custom validation message that interpolates submitted input or another attacker-controlled variable. No public exploit was identified at time of analysis, and the issue requires user interaction because the victim must view the page that renders the vulnerable response.
Cross-site scripting in Apache Wicket's SmartLinkLabel and SmartLinkMultiLineLabel components turns attacker-influenced text into anchors whose href is copied verbatim, so a value naming a script-executing scheme becomes a clickable script link in the application's origin and the reader's session. Affected are Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0, but only applications that render untrusted text through one of those two components; no other component uses DefaultLinkParser. Exploitation is not a drive-by: the reader must click the injected link, and on 9.x and 10.x the default nonce-based Content-Security-Policy blocks the script unless the deployment has weakened or disabled it, while 8.x has no CSP support and is exposed as it stands. No public exploit code was identified at time of analysis; fixed releases are 8.20.0, 9.25.0 and 10.12.0.
Stored cross-site scripting in Apache Wicket's AjaxNewWindowNotifyingBehavior allows a client-supplied browser window name to be persisted in a page instance's serialized state and later emitted as raw, unescaped JavaScript, executing in the application's origin each time that page instance is rendered. Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 are affected, but only applications that explicitly added the behaviour to a component are exposed, since the framework never installs it; the vector is unauthenticated (PR:N) yet requires victim interaction and specific attack prerequisites, so real-world priority is moderate rather than urgent. No public exploit identified at time of analysis, and the vendor has released fixes in 8.20.0, 9.25.0 and 10.12.0.
Session fixation in Apache Wicket's role-based authentication module leaves the container session id unchanged when an already-signed-in session authenticates a second time, so an attacker-planted session id can survive a successful login. Affected releases are 8.18.0 through 8.19.0, 9.23.0 through 9.24.0 and 10.9.0 through 10.11.0, and exploitation requires an application that authenticates via AuthenticatedWebSession, permits re-authentication of a signed-in session (step-up prompt, account switch, or a sign-in form still reachable after login), and an attacker who can plant a session id in the victim's browser and has already authenticated that session with a valid account (PR:L, UI:A). Successful exploitation yields high confidentiality and integrity impact within the vulnerable application; the vendor-released fix is available in 8.20.0, 9.25.0 and 10.12.0, and no public exploit has been identified at time of analysis. The CVSS 4.0 base score is 7.2 (High), though the vector is tempered by AT:P (an attack requirement outside the attacker's control) alongside PR:L and UI:A.
Pages rendered by Apache Wicket 10.10.0, 10.11.0 and 9.24.0 can be served without any Content-Security-Policy header when the page's render request handler is wrapped in more than one IRequestHandlerDelegate, because the framework unwraps only a single delegate level when deciding whether a request renders a page; with a deeper chain - for example an application-provided delegating request mapper combined with CryptoMapper - CSP is silently skipped with no error or warning, and the nonce-based protection for inline scripts and styles plus any other configured directives are lost for those pages. Only applications that wrap request handlers themselves in a non-default deployment are exposed; stock Wicket applications are not affected, and because the defect removes a protective control rather than providing an injection primitive, actual content injection additionally requires a separate injection vector on such a page and a victim rendering it (passive user interaction). This is a low-severity, configuration-dependent regression - versions before 10.10.0 and 9.24.0 handled nested delegates correctly - and no public exploit has been identified at time of analysis, with CISA KEV status absent and the vulnerability not listed as actively exploited.
Apache Wicket 8.x through 10.x can be made to return the HTML markup template of an application's own component class instead of the static file that the package resource guard approved, giving a remote unauthenticated attacker read access to developer-authored template source. Exposure is conditional: the application must contain a component class whose simple name includes an underscore and for which no shorter underscore-delimited prefix is itself a class (for example Report_v2 or Wizard_Step1), and disclosure is confined to HTML files in that component's own package - component structure, developer comments, conditional markup, inline script and named endpoints, but no user data, credentials or session material. No public exploit code is identified at time of analysis, and the vendor has released fixed versions 8.20.0, 9.25.0 and 10.12.0.
Markup template disclosure in Apache Wicket 8.0.0-8.19.0, 9.0.0-9.24.0 and 10.0.0-10.11.0 allows unauthenticated remote attackers to fetch a component's HTML markup template over HTTP with status 200 by requesting its package-resource URL. The flaw only manifests in non-standard deployments where wicket-core is loaded by a class loader that cannot see the application's component classes (shared servlet-container library directory, EAR lib directory with the WAR-hosted application, application-server global module, or OSGi bundle); the ordinary WAR layout with wicket-core in WEB-INF/lib is not affected. Impact is strictly read-only disclosure of developer-authored template content - component structure, comments, conditionally rendered markup, inline script and named endpoints - with no user data, credentials or session material reachable and no integrity or availability effect; no public exploit code was identified at time of analysis and there is no CISA KEV listing, and the priority signal is this_month rather than immediate action.
Apache Wicket's resource authorization check is bypassed when a restricted resource is served through a component that was constructed with an IResource instance instead of a ResourceReference. The framework enforces IAuthorizationStrategy#isResourceAuthorized() and the wicket-auth-roles @AuthorizeResource annotation at only one point - ResourceRequestHandler - so ResourceLink(String, IResource), Image, ImageButton and AjaxDownloadBehavior call IResource#respond() directly from their own request listener and never consult the strategy; for Image and ImageButton the listener URL is written into the tag's src attribute, so a browser fetches the protected content with no user action. Affected versions are 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0; only applications that actually restrict a resource and then hand that same instance to one of these components are exposed, and ExportToolbar in wicket-extensions triggers the pattern for data-table exports. No public exploit code and no confirmed active exploitation were identified at time of analysis, and EPSS data was not provided; severity is rated medium (vendor CVSS 4.0 base 6.3).
Missing authorization in Apache Wicket 8.x, 9.x and 10.x allows unauthenticated remote attackers to invoke a component's IRequestListener even though the application's IAuthorizationStrategy denied the Component.RENDER action for that component, or even though the application set the component invisible or disabled in Component#onConfigure(). The flaw is reachable with nothing more than a crafted or simply unmodified request, because Wicket can build a listener URL without a page identifier and then invokes the listener on a freshly constructed page instance before any render pass has populated the authorization-derived visibility flag; the impact is limited to integrity (low), with no confidentiality or availability effect assessed. Exploitation requires a Wicket application that withholds an individual component via a RENDER denial or via visibility/enablement set in onConfigure(), on a page that is reachable from a bookmarkable or mounted URL and has a public no-argument or PageParameters constructor; signals are moderate and broadly consistent, and no public exploit identified at time of analysis.
Apache Wicket's native WebSocket support keeps serving a session after the servlet container has ended it: because each connection resolves its Wicket session from a copy taken at handshake time, an authenticated user holding an open socket continues to be treated as signed in - with the original session attributes and, in wicket-auth-roles applications, the signed-in state - for as long as the connection stays open. Affected are Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 (older unsupported 6.x releases from 6.0.0 are also affected), but only where an application uses native WebSocket pages or WebSocketResource endpoints that require an authenticated session and terminates sessions through the container (idle timeout, filter or security-framework HttpSession#invalidate(), container-managed logout, or session replacement) rather than through Wicket. Severity is low (CVSS 4.0 base score 2.3; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N) since the attacker must already hold such an authenticated connection, and no public exploit has been identified at time of analysis.
Missing authorization in Apache Wicket's native WebSocket support lets a client's text and binary messages reach a WebSocketBehavior's onMessage() callbacks even when the component that behavior is attached to is hidden, disabled, or denied by the application's IAuthorizationStrategy. Only applications that override onMessage() on a WebSocketBehavior attached to (or beneath) such a restricted component are affected, and an attacker must hold their own valid session and open their own page containing that component, since messages are delivered only within the client's own page store and never to another user's session or connection. Affected releases are 8.0.0 through 8.19.0, 9.0.0 through 9.24.0 and 10.0.0 through 10.11.0 (with older unsupported 6.x-and-later releases also affected); no public exploit code has been identified at time of analysis, the issue is not in CISA KEV, and priority signals point to monitoring rather than urgent action.
Missing authorization in Apache Wicket 10.3.0 through 10.11.0 allows a remote unauthenticated caller to invoke the server-side callbacks of a form submit control that the application deliberately withheld from them, because Form#findSubmitter() resolves the submitter from the request parameter name alone and the visible/enabled check runs only when no submitter is supplied. Where a Button or SubmitLink is hidden, disabled, or denied by IAuthorizationStrategy while the enclosing form stays available, a request naming that control still reaches its onSubmit() and onAfterSubmit(), and its onError() when validation fails - reaching onSubmit()/onAfterSubmit() with no validation at all when the button sets setDefaultFormProcessing(false). No public exploit code has been identified at time of analysis; Ajax submissions through AjaxFormSubmitBehavior, AjaxButton and AjaxSubmitLink are not affected, restrictions on the form or page are not bypassed, and the 9.x and 8.x lines are unaffected because the behaviour was introduced in 10.3.0.
Missing authorization in Apache Wicket's native WebSocket transport allows a remote caller who holds a bound Wicket session to invoke the callbacks of a registered `WebSocketResource` shared resource without the application's `IAuthorizationStrategy` ever being consulted, so class-level restrictions such as `@AuthorizeResource` are silently ignored. The flaw is unauthenticated per the CVSS vector (PR:N) and affects Wicket 8.0.0 through 8.19.0, 9.0.0 through 9.24.0, 10.0.0 through 10.11.0, and older unsupported 7.x releases, but only where an application registers a `WebSocketResource` as a shared resource and relies on the authorization strategy to protect it. Impact is bounded to whatever the targeted resource's `onConnect()` and `onMessage()` callbacks do with an attacker-supplied text or binary message, and because the connection registers under the caller's own session there is no path to another user's connection; no public exploit code has been identified at time of analysis, and the vendor has released fixed versions 8.20.0, 9.25.0 and 10.12.0.
Unauthenticated remote attackers can partially read and modify data in Apache Wicket versions 9.0.0 through 9.23.0 and 10.0.0 through 10.9.0 due to a protection mechanism that relies on insufficiently random values. The vulnerability is automatable with low attack complexity and no user interaction, though no active exploitation or public exploit code has been observed at this time. While the technical impact is limited to partial confidentiality and integrity compromise, the widespread enterprise use of Wicket makes it a moderate priority for patching.
Cross-site scripting (XSS) in Apache Wicket versions 9.0.0-9.23.0 and 10.0.0-10.9.0 allows attackers to inject client-side scripts into pages rendered by the affected application, potentially compromising user sessions or redirecting victims. The vulnerability arises from insufficient neutralization of user input during HTML generation, enabling script injection via crafted URLs or form submissions. No public exploit is known, but upgrading to version 10.10.0 eliminates the issue.
Path traversal vulnerability in Apache Wicket's FolderUploadsFileManager allows unauthenticated attackers to read arbitrary files or write files outside the intended upload directory by exploiting unsanitized uploadFieldId and clientFileName parameters. Affected versions 8.0.0-8.17.0, 9.0.0-9.22.0, and 10.0.0-10.8.0 are vulnerable to remote file access and modification without authentication or user interaction. Vendor-released patch available in version 10.9.0.