Apache Wicket follows the Apache Software Foundation security process.

Please do not report security vulnerabilities through GitHub issues, GitHub discussions, pull requests, JIRA, or the public mailing lists. Doing so discloses the issue publicly before a fix is available.

Report suspected vulnerabilities privately to:

• security@apache.org — the ASF Security Team, who will forward the report to the Wicket PMC.

A useful report includes:

• the affected Wicket version(s) and the module (e.g. wicket-core),
• the affected class and method, ideally with a source reference,
• a concrete description of how an attacker reaches the code, including what the attacker is assumed to control (see Security Model),
• the impact you believe follows from that, and
• a reproducer where possible — a failing test is ideal.

Please state clearly whether you have published anything about the issue, and whether you are requesting a CVE.

We ask reporters to keep the issue confidential until a fixed release is published and the PMC has announced it. In return, we will keep you informed of our assessment and of the release timeline, and credit you in the announcement unless you ask us not to.

Note that reports are assessed against the scope, the two conditions in Reports We Do Not Assess, and the security model below. A report that depends on the framework distrusting something this model treats as trusted may be closed as a deployment or configuration issue rather than a framework vulnerability. If you believe the model itself is wrong, that is a legitimate and useful thing to report — please say so explicitly, so we discuss the model rather than the individual code path.

Conversely, a demonstrated bypass of a boundary this model does claim — for example the package resource guard, or an authorization strategy — is a vulnerability, and we want to hear about it. The boundaries below describe what Wicket intends to enforce; where the code falls short of them, the code is what needs fixing.

Security fixes are applied to the actively maintained release lines. Refer to the download page for the current status and the latest release of each line.

If you are running a discontinued version, the fix is to upgrade. See the Migration to Wicket 10.0 guide on our wiki, which links the guides for the earlier lines.

The table above says which release lines receive security fixes. Three categories of code inside those lines sit outside this process.

@Deprecated is our statement that code has no future and that an application should stop relying on it. Where an application has to reach that code deliberately — calling a deprecated method, extending a deprecated class, setting a deprecated setting — the remedy for a problem in it is to stop using it, not to harden something we intend to remove. Such a report is closed with a pointer to whatever the migration is; it receives no CVE, and the deprecated code is not fixed.

Two limits on that, both of which cut in the reporter's favour:

• Deprecation is per release line. A member deprecated on master may still be current in 10.x or 9.x. A report is judged against the line it targets, not against master.
• Deprecating a member does not deprecate the behaviour behind it. Where a deprecated accessor merely fronts a feature that is still current and still reachable without the application opting in, the feature is in scope and the deprecated accessor is beside the point. What this section excludes is functionality an application chooses to use, not behaviour it gets whether it asks for it or not.

Where something is deprecated because it is insecure, the javadoc says so. Usually it also names what to use instead. Sometimes it cannot: where the design rather than the implementation is the problem, a feature may be one that cannot be made safe, and we will deprecate it with no replacement offered — the secure course is to stop doing the thing at all rather than to do it differently, so there is nothing to migrate to. Deprecation is the fix in that case, and the code is out of scope on the same footing as any other deprecated code. The javadoc says which of the two applies, so it is clear before reporting.

Wicket ships two IResourceIsolationPolicy implementations, and only one of them carries the boundary described in Another origin may not invoke a listener.

FetchMetadataResourceIsolationPolicy, added in 9.1.0, is the supported one. It reads the Sec-Fetch-* request headers, which the browser sets and which page content can neither forge nor remove.

OriginResourceIsolationPolicy is the older mechanism, kept so that ResourceIsolationRequestCycleListener still has something to say about a client that does not send those headers. It compares the Origin and Referer headers against the requested URL, and the limits of that approach are inherent in the headers rather than in the implementation:

• Neither header need arrive. Browsers send Origin on a form submit, but not on a plain GET — which is how a Link and most Ajax behaviours invoke their listener. There the check falls back to Referer, and Referer is suppressed by the referring page's own Referrer-Policy, by rel="noreferrer", and by an HTTPS-to-HTTP downgrade. The document on the other origin chooses its own referrer policy, so it is the party deciding whether a source header reaches us at all.
• A missing source is not a rejection. With no usable header the outcome is UNKNOWN and the request is settled by ResourceIsolationRequestCycleListener#setUnknownOutcomeAction, which defaults to aborting — but which deployments relax precisely because legitimate traffic also arrives without the headers.
• It cannot express the boundary. The policy ignores the RequestType, so it cannot distinguish a page render, which may legitimately be a top-level navigation from another site, from a listener invocation, which may not.
• Its idea of the target is the trusted host. It builds the URI it compares against from the container-reported host, port and scheme (see Wicket trusts the container-reported host, port and scheme), and addAcceptedOrigin matches subdomains, so accepting a domain accepts every host beneath it.

We therefore do not assess a report that a request can get past this policy, and we will not harden it. The remedy is FetchMetadataResourceIsolationPolicy, which is what the framework claims; a deployment that does not want the fallback at all can construct the listener without it: new ResourceIsolationRequestCycleListener(new FetchMetadataResourceIsolationPolicy()). The class is not marked @Deprecated only because it remains a reasonable fallback for a legacy client, where the alternative is to refuse the request outright.

What this exclusion does not cover is the chain around it. The default policy list is FetchMetadataResourceIsolationPolicy followed by OriginResourceIsolationPolicy, checked in order, and the first policy to return an outcome other than UNKNOWN decides. A request carrying Sec-Fetch-Site is consequently always settled by the fetch-metadata policy and never reaches the origin policy, and another document cannot make a browser omit that header. So a report showing that a request with Sec-Fetch-Site present is nonetheless decided by the origin policy is in scope, as is anything else in ResourceIsolationRequestCycleListener itself.

8.x has no supported resource isolation implementation. The IResourceIsolationPolicy mechanism arrived in 9.1.0. On 8.x the only cross-origin check Wicket offers is CsrfPreventionRequestCycleListener, which reads the same two headers with the same limits; 9.x deprecates it in favour of the resource isolation listener and it is therefore already out of scope there under Deprecated code is out of scope, while on 8.x it is not deprecated only because that line has nothing to migrate to. An 8.x application that needs anything stronger has to upgrade or implement the check itself: we will not backport the fetch-metadata policy, and reports against CsrfPreventionRequestCycleListener are out of scope on the same footing as the origin policy.

wicket-examples exists to demonstrate framework features in as few lines as possible. It is not written to production standards, and some of it is deliberately insecure so that the examples run anywhere out of the box. WicketExampleApplication, the base class of every example, installs NoCrypt as the crypt factory — a no-op cipher, so that nothing depends on the local JCE setup — and enables the development utilities; the source says in as many words not to do either in a real application. Individual examples go further: authentication1 hardcodes its one credential pair in the source. Do not read the examples as a security reference, and do not copy them into an application unchanged.

We do want to hear about problems in them, because example code gets copied and a misleading pattern propagates from there into real applications. But fixing one is a correction to teaching material rather than a fix to a vulnerability in the framework, so:

• the PMC will not request a CVE for it;
• it is fixed on master only. wicket-examples ships as a WAR in every release, and we knowingly leave the released examples as they are;
• once we have confirmed the problem is example-only, it is tracked in public JIRA, since there is nothing to embargo.

The same reasoning covers wicket-devutils, a development aid rather than a production module (see Deployment configuration), and the internal test modules that are never published. It does not cover wicket-tester or wicket-extensions-tester, which are released artifacts that applications depend on, and it does not cover the quickstart archetype: applications are started from the archetype, so it is expected to be secure by default and is in scope like any other module.

The examples are also hosted publicly by the ASF. Those deployments are ASF infrastructure, not a Wicket release. If you find something that affects the hosting rather than the example application itself, it is still worth reporting to security@apache.org — say that it concerns the hosted site, so that it can be routed to ASF Infrastructure as well as to the PMC.

The two conditions below are about the report rather than about the code. Both exist because a report that cannot be verified costs as much to triage as one that can, and neither is a judgement on whether the concern behind it is real.

Verify the issue against the current tip of the line you are reporting against: wicket-8.x, wicket-9.x, wicket-10.x, or master. One of them is enough — say which, and name the commit you tested. A failing test against that commit is ideal. Reporting only the release you happen to be running is not sufficient: a released artifact is always behind its branch, and what you found may already be fixed there.

We do not assess a report verified only against an older version. A release that is not its branch tip may be missing fixes that are already public, and the discontinued lines — 7.x and earlier — receive no security fixes at all, so the remedy there is to upgrade whether or not the behaviour you found is a vulnerability. Note also that git branches exist for every line Wicket has ever shipped; a branch existing is not a statement that the line is supported. The table above is.

Before reporting, check the advisories already published for the line you tested, at security.apache.org/projects/wicket/. An issue fixed in a later release of that same line is not a vulnerability report; it is a reason to upgrade.

This is a condition on the evidence, not on the finding. If the behaviour does reproduce on a supported tip, re-verify it there and send it again — arriving first against the wrong version is not held against a report.

We do not assess a report whose subject cannot be found in the codebase: a class, method, setting, or file that does not exist on the branch the report names. Such a report cannot be confirmed or ruled out, and there is nothing in it for us to fix.

Quote the code you are describing, from the branch you are targeting, and give paths as they appear in the repository. Where a reference is merely inaccurate — the right class named under the wrong module, a line number that has moved since you looked — we will resolve it ourselves and say so. What we close unassessed is a report whose subject is not in the code at all: a method that was never written, a field given a value it does not have, a call chain whose steps do not exist.

How the report was produced does not matter to us: by hand, with tooling, or with a model. Accuracy is what matters. A report whose subject we cannot locate is indistinguishable from a real finding until every claim in it has been checked against the code, and that is effort we would rather spend on the reports that hold up. Tell us what you verified and where you verified it, and we will take it from there.

Wicket is a framework, not a deployed application. It runs inside a servlet container, usually behind a reverse proxy, and it inherits its view of the outside world from that container. This section documents which of those inputs Wicket treats as trusted, so that operators know what they are responsible for and reporters know what the framework does and does not claim to defend.

Wicket derives its own public identity — the scheme, host and port it believes it is being served on — from the servlet container, via HttpServletRequest#getScheme(), #getServerName() and #getServerPort(). There is no hostname allowlist in the framework and no attempt to verify the Host header, in any of the places this identity is used:

• ServletWebRequest#setParameters sets the host, port and protocol on the client URL from these three values. That URL backs UrlRenderer, and so every absolute URL Wicket renders.
• HttpsMapper#createRedirectUrl builds the scheme-switch redirect for @RequireHttps pages from the same values.
• OriginResourceIsolationPolicy#getTargetUriFromRequest builds the trusted target URI that incoming Origin and Referer headers are compared against.

This is a deliberate design decision, not an oversight. Only the deployment knows its own canonical hostnames; the framework cannot infer them. Note in particular that the third item means the container-reported host is a trusted input to a request-forgery defence — a deployment that lets arbitrary Host values through weakens more than URL rendering. That policy is the legacy one and is out of scope; FetchMetadataResourceIsolationPolicy, the supported one, does not consult the host at all.

Therefore the deployment is responsible for ensuring that only expected Host values reach the application. Concretely:

1. Configure the container or virtual host to reject requests carrying an unrecognised Host — return a 400 or 404 rather than routing them to the application. Tomcat, Jetty and the common reverse proxies all support this.
2. If TLS is terminated at a proxy, have the proxy set or overwrite Host to the canonical name rather than forwarding whatever the client sent.
3. Do not expose a Wicket application through a catch-all or default virtual host that accepts any Host.
4. Serve the application over HTTPS and enable HSTS, so that plaintext requests — including the ones HttpsMapper exists to upgrade — are not part of the normal flow.

A consequence worth stating plainly: on a deployment that accepts arbitrary Host values, absolute URLs and redirects generated by Wicket will contain the host the client supplied. That is the documented behaviour of trusting the container. It is not treated as a framework vulnerability, because the host in such a response is always the same authority the client had already connected to — it grants an attacker no origin they did not already control. The fix belongs at the container or proxy, per the points above.

Wicket ignores X-Forwarded-For and X-Forwarded-Proto unless you explicitly enable XForwardedRequestWrapperFactory. When enabled, it overrides getRemoteAddr(), getRemoteHost(), getScheme() and getServerPort() from those headers, subject to its allowedInternalProxies and trustedProxies configuration.

Only enable it when a trusted proxy in front of the application appends to these headers and strips any client-supplied copies; otherwise the headers are attacker-controlled. Wicket does not implement X-Forwarded-Host at all, and XForwardedRequestWrapper does not override getServerName() — the host always comes from the container as described above.

For Ajax requests Wicket reads a client-supplied base URL — the Wicket-Ajax-BaseURL header, falling back to the wicket-ajax-baseurl request parameter — in order to resolve relative URLs against the page the client is actually on. The host, port and protocol of that URL are always overwritten with the container-reported values before use. The client can influence the path Wicket renders relative to, never the authority.

RuntimeConfigurationType.DEVELOPMENT enables debugging aids, verbose error reporting and development-only components, and disables some caching. It is not intended for production and is not hardened. Always run production deployments with the configuration type set to RuntimeConfigurationType.DEPLOYMENT. Issues only reachable in DEVELOPMENT mode are treated as configuration errors rather than vulnerabilities.

Likewise, wicket-devutils is a development aid. Do not deploy it in production; it is out of scope for the same reason the examples are (see Scope).

Wicket serializes page instances and session data to its page store. Java deserialization is not a safe operation on untrusted input, and by default Wicket's page store does not defend against it. Treat the page store and the session store as trusted, private storage: do not point them at storage that untrusted parties can write to, and do not accept externally supplied serialized page or session data.

The partial exception is a page store configured with encryption (StoreSettings#setEncrypted(true)). Every ICryptScheme Wicket ships is authenticated (AEAD), so encrypted pages are tamper-evident as well as confidential: modified or substituted bytes fail to decrypt and the page is treated as absent instead of being handed to the deserializer. Each page is additionally bound to the page id it was stored under, so a stored page cannot be replayed as a different one. The scheme marker prefixing each ciphertext is authenticated too, and is refused unless it is one of the schemes accepted by SecuritySettings#setWhitelistedCryptSchemes, so an attacker cannot force decryption with a weaker scheme.

Three limits on that exception are worth stating. The key lives in the user's session, so this protects the stored pages against a party who can read or write the store, not against one who already controls the session. It covers the page store only — the container's session store, and anything else holding serialized Wicket data, remains trusted storage. And a custom ICryptScheme inherits the guarantee only if it honours the contract: decrypt must return null on authentication failure rather than returning unverified plaintext.

Wicket escapes the text a component renders from its model. Component's escapeModelStrings flag is on by default, and a component renders model-derived text either through Component#getDefaultModelObjectAsString() or by applying Strings#escapeMarkup when that flag is set. A component that writes application model data into the markup unescaped in the default configuration is a bug in the framework and an opening for cross-site scripting (XSS). We want to hear about it.

setEscapeModelStrings(false) is the application saying the content is markup and taking responsibility for it. Reports that depend on an application having cleared the flag are configuration issues rather than framework vulnerabilities. Note that a few components clear it themselves because their value is written into an attribute, which is escaped when the tag is written and would otherwise be encoded twice; that is an implementation detail of those components and not an invitation to render untrusted markup through them.

Two inputs on the other side of the boundary are trusted, because both are authored by the developer and neither is data the application received at runtime:

• Markup files are trusted. A .html file on the classpath is a template, exactly like a JSP or a Thymeleaf template, and Wicket renders it as markup. An application that serves markup from somewhere an untrusted party can write — through a custom IMarkupResourceStreamProvider, for instance — has taken that trust on itself.
• Message bundles are trusted. <wicket:message key="…"/> renders its property value as markup by default, and escape="true" opts in to escaping. Markup in a bundle is therefore a supported way to format a message.

The value a bundle string interpolates is a different matter. ${name} in a message resolves first to a child component with wicket:id="name", whose rendered markup carries that component's own escaping. Only when there is no such child does Wicket fall back to reading name from the surrounding component's model, and that value is written as it came — so a static bundle can still place model data in the markup unescaped. Prefer the child component. Where the fallback is unavoidable and the data is not trusted, the message needs escape="true", which escapes the whole message and therefore any markup the bundle itself contains.

Finally, Strings#escapeMarkup escapes <, >, &, " and '. That is enough for element text and for a quoted attribute value, and it is not enough for anything else: it does not make a value safe inside <script> or <style>, in an unquoted attribute, or in a URL where the scheme itself is the payload. Wicket does not automatically escape a value the application places into a JavaScript context — through TextTemplate variable substitution, for example — so the application has to encode it.

Where ResourceIsolationRequestCycleListener is registered, a request originating from another origin must not be able to invoke a listener on a page — a Link.onClick(), a Form.onSubmit(), or an AJAX behaviour. A demonstrated way for another origin to reach one is a vulnerability.

Two things sit deliberately outside that boundary:

• Rendering a page is allowed. A page may be reached by a simple top-level navigation from anywhere, so that pages remain linkable from other sites. Only the invocation of a listener is refused. This holds for every render, not only for top-level navigations: a page reached as a subresource load, through fetch, or inside an <object> or <embed> is not refused either, because the listener does not consult a policy for renders at all. A page whose render alone discloses something sensitive cannot rely on this listener.
• Sibling origins may be trusted explicitly. Sec-Fetch-Site: same-site means a different origin on the same registrable domain and scheme, such as another subdomain, and is refused by default. A deployment that trusts every origin on its own site can allow it; sibling-origin actions are then that deployment's decision rather than a framework vulnerability.

The boundary is FetchMetadataResourceIsolationPolicy's. The listener also consults OriginResourceIsolationPolicy by default, for clients that send no Sec-Fetch-* headers, and that policy is out of scope.

This listener is opt-in and is not registered by default. Without it Wicket enforces no cross-origin boundary on listener invocation at all. CryptoMapper raises the cost of forging a URL but is not a substitute for it, for the reason below.

CryptoMapper encrypts URLs so that page and component identifiers are not guessable. It raises the cost of forging a URL, but it is not an access-control mechanism. Authorization must be enforced with IAuthorizationStrategy (or equivalent) so that it holds regardless of whether a URL was guessed, replayed, leaked through a referrer, or found in a log.

CryptoMapper encrypts a URL to the same text every time, for as long as the key lives. It has to: a URL regenerated during rendering must match the one the client requested, and a resource URL must stay identical across requests or the browser re-downloads the resource on every page view. The consequence is that equal URLs are recognisable as equal, and that anyone holding the key can confirm a guessed URL by encrypting it themselves. With the default KeyInSessionCryptFactory the key is per session, so this is confined to a single user; with an application-wide key it is not. Encrypted URLs are therefore an obfuscation and a per-session CSRF token, never a secret in their own right — which is the same reason they are not an authorization mechanism. Everything Wicket encrypts elsewhere, such as the page store, uses the randomized path and does not have this property.

Findings that are real but not vulnerabilities are still welcome — please raise them publicly in JIRA or as a pull request rather than through the private security channel, so they can be discussed and fixed in the open. Hardening suggestions, defence-in-depth improvements, and clarifications to this document all fall into that category.

If you are unsure which channel applies, use the private one — we would rather receive a non-issue privately than a real issue publicly.