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 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. Two 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-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.

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 Wicket's own request-forgery defences — a deployment that lets arbitrary Host values through weakens more than URL rendering.

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 exception is a page store configured with encryption (StoreSettings#setEncrypted(true)), and then only as far as the configured ICrypter implementation documents. Encryption does not by itself imply tamper detection: whether the stored bytes are merely confidential or are also protected against modification depends entirely on the implementation in use, and the default implementation is not authenticated. Consult the javadoc of the ICrypter you configure and rely on no more than it states.

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. Requests that are not top-level navigations — subresource loads, fetch, <object> and <embed> — are refused for renders too.
• 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.

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.

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.