The ftp and scp tasks of Apache Ant can download files from a remote server. A malicious server can provide relative paths that allow it to write outside of the dedicated target directory for the download, making it possible to overwrite files of the attacker's choice using the permissions of the user running Ant in versions prior to Ant 1.10.18.

In order to exploit this vulnerability, the server would either have to be malicious or be subject to a machine-in-the-middle attack. Additionally in the case of scp or the ftp task using ftps the server must pass the server identity checks performed by the tasks.

For ftp tasks not using ftps a malicious server could act as a machine-in-the-middle to provide malicious files.

Starting with Ant 1.10.18 both tasks will prevent writing outside of the destination directory by default. An option is available to disable this behavior in the unlikely case that the old behavior is required by existing build files.

Mitigations:

Users of scp and ftp (when using ftps) in any version of Ant should not bypass server identity checks. Users of ftp not using ftps should switch to ftps where possible.

All users are recommended to upgrade to Apache Ant 1.10.18, which fixes this issue.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Severity: moderate

Affected versions:

- - Apache Ant (org.apache.ant:ant) 1.2 before 1.10.18

Description:

The ftp and scp tasks of Apache Ant can download files from a remote server. A malicious server can provide relative paths that allow it to write outside of the dedicated target directory for the download, making it possible to overwrite files of the attacker's choice using the permissions of the user running Ant in versions prior to Ant 1.10.18.

In order to exploit this vulnerability, the server would either have to be malicious or be subject to a machine-in-the-middle attack. Additionally in the case of scp or the ftp task using ftps the server must pass the server identity checks performed by the tasks.

For ftp tasks not using ftps a malicious server could act as a machine-in-the-middle to provide malicious files.

Starting with Ant 1.10.18 both tasks will prevent writing outside of the destination directory by default. An option is available to disable this behavior in the unlikely case that the old behavior is required by existing build files.

Mitigations:

Users of scp and ftp (when using ftps) in any version of Ant should not bypass server identity checks. Users of ftp not using ftps should switch to ftps where possible.

All users are recommended to upgrade to Apache Ant 1.10.18, which fixes this issue.

References:

https://ant.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-78254 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1

iEYEARECAAYFAmqdrDYACgkQohFa4V9ri3I5qACfcG2HDTmYacy8+gH61R+JXo5k qJoAnR8LgcxQirXqj5mwVacgFR5ZXVLX =iAQR -----END PGP SIGNATURE-----

UNSUPPORTED WHEN ASSIGNED Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') vulnerability in Apache Griffin Hive Metastore Module.

This issue affects Apache Griffin Hive Metastore Module: all versions.

As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative or restrict access to the instance to trusted users.

NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

UNSUPPORTED WHEN ASSIGNED  Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Apache SkyWalking Booster UI.

This issue affects Apache SkyWalking UI : from 10.2.0 through 10.4.0.

Users are recommended to upgrade to Horizon UI 1.0.0, which fixes the issue.

PagerDuty alarm hook transmits the integration routing key over cleartext HTTP.

PagerDuty serves this endpoint over HTTPS and will normally answer plain HTTP with a redirect. That does not remove the exposure. The initial POST -- including the JSON body containing the routing key -- is written to the socket unencrypted before any redirect response is received. Redirection affects only whether the request is retried securely, not whether the first copy left the host in the clear.

This issue affects Apache SkyWalking: from 9.6.0 through 11.0.0.

Users are recommended to upgrade to version 11.0.0, which fixes the issue.

Affected versions:

- Apache SkyWalking 10.2.0 through 10.4.0

Description:

Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Apache SkyWalking Booster UI.

This issue affects Apache SkyWalking UI : from 10.2.0 through 10.4.0.

Users are recommended to upgrade to version Horizon UI 1.0.0, which fixes the issue.

Credit:

n0mi1k (reporter)

References:

https://skywalking.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-85229

Severity: low

Affected versions:

- Apache SkyWalking 9.6.0 through 11.0.0

Description:

PagerDuty alarm hook transmits the integration routing key over cleartext HTTP.

PagerDuty serves this endpoint over HTTPS and will normally answer plain HTTP with a redirect. That does not remove the exposure. The initial POST -- including the JSON body containing the routing key -- is written to the socket unencrypted before any redirect response is received. Redirection affects only whether the request is retried securely, not whether the first copy left the host in the clear.

This issue affects Apache SkyWalking: from 9.6.0 through 11.0.0.

Users are recommended to upgrade to version 11.0.0, which fixes the issue.

Credit:

ambesh.infosec () gmail com (reporter)

References:

https://skywalking.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-71216

Apache Allura: exposure of non-public information via search.

This issue affects Apache Allura: through 1.20.0.

Users are recommended to upgrade to version 1.21.0, which fixes the issue.

Apache Allura: stored XSS via SVN code repositories.  Git repositories are not known to be affected.  The vulnerability is likely mitigated via default CSP headers.

This issue affects Apache Allura: through 1.20.0.

Users are recommended to upgrade to version 1.21.0, which fixes the issue.

Apache Allura's webhooks are vulnerable to Server-Side Request Forgery (SSRF).

This issue affects Apache Allura: through 1.20.0.

Users are recommended to upgrade to version 1.21.0, which fixes the issue.

Stored XSS via markdown HTML processing in Apache Allura.

This issue affects Apache Allura: from through 1.20.0.

Users are recommended to upgrade to version 1.21.0, which fixes the issue.

Severity: moderate

Affected versions:

- Apache Allura through 1.20.0

Description:

Apache Allura: exposure of non-public information via search.

This issue affects Apache Allura: through 1.20.0.

Users are recommended to upgrade to version 1.21.0, which fixes the issue.

Credit:

n0mi1k (reporter)

References:

https://allura.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-81270

Severity: low

Affected versions:

- Apache Allura through 1.20.0

Description: This issue affects Apache Allura: through 1.20.0.

Users are recommended to upgrade to version 1.21.0, which fixes the issue.

Credit:

n0mi1k (reporter)

References:

https://allura.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-80190

Severity: important

Affected versions:

- Apache Allura through 1.20.0

Description:

Apache Allura's webhooks are vulnerable to Server-Side Request Forgery (SSRF).

This issue affects Apache Allura: through 1.20.0.

Users are recommended to upgrade to version 1.21.0, which fixes the issue.

Credit:

n0mi1k (reporter)

References:

https://allura.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-80181

Severity: critical

Affected versions:

- Apache Allura through 1.20.0

Description:

Stored XSS via markdown HTML processing in Apache Allura.

This issue affects Apache Allura: from through 1.20.0.

Users are recommended to upgrade to version 1.21.0, which fixes the issue.

Credit:

n0mi1k (reporter)

References:

https://allura.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-80180

There is a lack of XSS escaping in the Spark History Server prior to 3.5.8 which allows a malicious Spark job to generate arbitrary unescaped frontend code which could lead to a minimal privilege escalation in browser. Users are encouraged to upgrade to Spark 3.5.8 or later.

This CVE is marked as "low" since the path to exploit requires both relatively high permissions (ability to launch a Spark job) and requires tricking a user with higher permissions to log in and visit the Spark history web page.

Users are encouraged to upgrade their Spark history servers to Spark 3.5.8 or later.

Severity: low

Affected versions:

- Apache Spark (org.apache.spark:) 3.0.0 before 3.5.8

Description:

There is a lack of XSS escaping in the Spark History Server prior to 3.5.8 which allows a malicious Spark job to generate arbitrary unescaped frontend code which could lead to a minimal privilege escalation in browser. Users are encouraged to upgrade to Spark 3.5.8 or later.

This CVE is marked as "low" since the path to exploit requires both relatively high permissions (ability to launch a Spark job) and requires tricking a user with higher permissions to log in and visit the Spark history web page.

Users are encouraged to upgrade their Spark history servers to Spark 3.5.8 or later.

This issue is being tracked as SPARK-53747

Credit:

Yann Gourio (finder)

References:

https://spark.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-32773 https://issues.apache.org/jira/browse/SPARK-53747

Improper neutralization of input during web page generation in Apache Wicket.

org.apache.wicket.markup.html.form.AbstractSingleSelectChoice, the base class of DropDownChoice, writes the body of the default option — the entry shown when no choice is selected — into the markup as it is, while every other option body in the same select is escaped according to the escape-model-strings setting. The body comes from getNullValidDisplayValue() or getNullKeyDisplayValue(), both of which are protected, so what they return is not necessarily the plain text the default implementation reads from a resource bundle.

An application is affected where it overrides one of those methods and returns a value holding data an attacker can influence, or where its own nullValid or null bundle entry holds such a value. The bundles shipped with Wicket contain plain text. RadioChoice overrides getDefaultChoice to emit no default option and is not affected.

As a workaround, escape the value in the override.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 1.5.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Improper neutralization of input during web page generation in Apache Wicket.

org.apache.wicket.extensions.markup.html.form.palette.component.AbstractOptions, which renders the two option lists of a Palette, escapes the id and the display value of each option according to the escape-model-strings setting, and wrote the attribute names and values returned by getAdditionalAttributes into the <option> tag as they came.

An application is affected where it overrides Palette.getAdditionalAttributesForChoices, Palette.getAdditionalAttributesForSelection or AbstractOptions.getAdditionalAttributes and returns a value holding data an attacker can influence. These methods return null by default, so an application that does not override them is not affected.

As a workaround, escape the values in the override.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 1.4.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Improper neutralization of input during web page generation in Apache Wicket.

org.apache.wicket.markup.head.MetaDataHeaderItem generates <meta> and <link> header tags. It escaped the attribute names it wrote, but ran the attribute values through a replacement of " with \". A backslash before a double quote means nothing in HTML, so a value containing a double quote ends its own attribute and what follows is parsed as further attributes of the generated tag.

An application is affected where it supplies an attribute value holding data an attacker can influence, through addTagAttribute or the forMetaTag and forLinkTag factory methods. A value may be given as an IModel, so it is not necessarily a literal.

There is no setting to change; an application can only avoid supplying a value that contains a double quote. Note that these values have never been escaped effectively: before the change released in 6.24.0, 7.4.0 and 8.0.0 they were written with no escaping at all.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 6.17.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Improper neutralization of input during web page generation in Apache Wicket.

The <wicket:label> tag is provided by org.apache.wicket.markup.html.form.AutoLabelTextResolver, which is registered by default in every WebApplication. The resolver writes the label it finds into the markup as it is, and reads no escaping setting at all, so markup in a label is rendered as markup.

When the label comes from the labelled component's label model, set through FormComponent#setLabel(IModel), it is written to the markup unescaped. An application is affected where the label of a form component holds data an attacker can influence. Wicket cannot determine where a model value comes from, so whether it reaches the page from a request or from storage is a property of the application.

There is no workaround. Unlike every other rendering path in Wicket, the resolver never consulted the escape-model-strings setting, so an application had no way to ask for the label to be escaped.

The body of a <wicket:label> tag is markup by design and is not affected; it remains the supported way to place markup in a label.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 1.5.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Improper neutralization of input during web page generation in Apache Wicket.

org.apache.wicket.markup.html.form.Button clears the escape-model-strings flag in its constructor, so that the value attribute it writes is not encoded twice — ComponentTag already encodes attribute values when it writes the tag. That reasoning holds only for the attribute. When the component is attached to a <button> element rather than an <input>, it writes its model object into the element body instead, and nothing encodes an element body, so markup in the model is rendered as markup.

An application is affected where it renders a Button on a <button> element and that button's model holds data an attacker can influence. Wicket cannot determine where a model value comes from, so whether it reaches the page from a request or from storage is a property of the application. The subclasses that inherit this constructor — AjaxButton, AjaxFallbackButton and WizardButton — are affected on the same terms.

As a workaround, calling setEscapeModelStrings(true) on a button that renders as a <button> element escapes the body correctly, and does not cause double encoding, because the value attribute is written only for <input> elements.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 6.25.0 and 7.5.0 onwards are also affected.

Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

AjaxEditableChoiceLabel in wicket-extensions, when constructed with a non-null IChoiceRenderer, writes the display value obtained from that renderer into the label's markup without applying the HTML escaping Wicket performs by default for component model values. An attacker who can influence the choice or model data rendered by such a label can inject HTML or script that executes in the browser of any user who views the page. The same value is correctly escaped when the component's dropdown editor renders it as an option, so only the label rendering is affected.

AjaxEditableLabel, AjaxEditableChoiceLabel and AjaxEditableMultiLineLabel write the value returned by the protected defaultNullLabel() method into the label's markup the same way when the component's model is empty, while the model value they show otherwise is escaped. The default implementation returns a constant, so an application is affected where it overrides that method and returns a value an attacker can influence.

Neither value could be escaped by configuration, because escapeModelStrings had no effect on any of the three components: it is read by the label they render with rather than by the component itself, and nothing carried the setting across.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases are also affected; the display value from the renderer since 6.22.0 and the null label since 1.4.0. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Severity: moderate

Affected versions:

- Apache Wicket (org.apache.wicket:wicket-extensions) 8.0.0 through 8.18.0 - Apache Wicket (org.apache.wicket:wicket-extensions) 9.0.0 through 9.23.0 - Apache Wicket (org.apache.wicket:wicket-extensions) 10.0.0 through 10.10.0

Description:

AjaxEditableChoiceLabel in wicket-extensions, when constructed with a non-null IChoiceRenderer, writes the display value obtained from that renderer into the label's markup without applying the HTML escaping Wicket performs by default for component model values. An attacker who can influence the choice or model data rendered by such a label can inject HTML or script that executes in the browser of any user who views the page. The same value is correctly escaped when the component's dropdown editor renders it as an option, so only the label rendering is affected.

AjaxEditableLabel, AjaxEditableChoiceLabel and AjaxEditableMultiLineLabel write the value returned by the protected defaultNullLabel() method into the label's markup the same way when the component's model is empty, while the model value they show otherwise is escaped. The default implementation returns a constant, so an application is affected where it overrides that method and returns a value an attacker can influence.

Neither value could be escaped by configuration, because escapeModelStrings had no effect on any of the three components: it is read by the label they render with rather than by the component itself, and nothing carried the setting across.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases are also affected; the display value from the renderer since 6.22.0 and the null label since 1.4.0. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Credit:

Ho1aAs (finder)

References:

https://wicket.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-75802

Severity: moderate

Affected versions:

- Apache Wicket (org.apache.wicket:wicket-core) 8.0.0 through 8.18.0 - Apache Wicket (org.apache.wicket:wicket-core) 9.0.0 through 9.23.0 - Apache Wicket (org.apache.wicket:wicket-core) 10.0.0 through 10.10.0

Description:

Improper neutralization of input during web page generation in Apache Wicket.

org.apache.wicket.markup.html.form.Button clears the escape-model-strings flag in its constructor, so that the value attribute it writes is not encoded twice — ComponentTag already encodes attribute values when it writes the tag. That reasoning holds only for the attribute. When the component is attached to a <button> element rather than an <input>, it writes its model object into the element body instead, and nothing encodes an element body, so markup in the model is rendered as markup.

An application is affected where it renders a Button on a <button> element and that button's model holds data an attacker can influence. Wicket cannot determine where a model value comes from, so whether it reaches the page from a request or from storage is a property of the application. The subclasses that inherit this constructor — AjaxButton, AjaxFallbackButton and WizardButton — are affected on the same terms.

As a workaround, calling setEscapeModelStrings(true) on a button that renders as a <button> element escapes the body correctly, and does not cause double encoding, because the value attribute is written only for <input> elements.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 6.25.0 and 7.5.0 onwards are also affected.

Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Credit:

Emond Papegaaij (finder)

References:

https://wicket.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-76982

Severity: moderate

Affected versions:

- Apache Wicket (org.apache.wicket:wicket-core) 8.0.0 through 8.18.0 - Apache Wicket (org.apache.wicket:wicket-core) 9.0.0 through 9.23.0 - Apache Wicket (org.apache.wicket:wicket-core) 10.0.0 through 10.10.0

Description:

Improper neutralization of input during web page generation in Apache Wicket.

The <wicket:label> tag is provided by org.apache.wicket.markup.html.form.AutoLabelTextResolver, which is registered by default in every WebApplication. The resolver writes the label it finds into the markup as it is, and reads no escaping setting at all, so markup in a label is rendered as markup.

When the label comes from the labelled component's label model, set through FormComponent#setLabel(IModel), it is written to the markup unescaped. An application is affected where the label of a form component holds data an attacker can influence. Wicket cannot determine where a model value comes from, so whether it reaches the page from a request or from storage is a property of the application.

There is no workaround. Unlike every other rendering path in Wicket, the resolver never consulted the escape-model-strings setting, so an application had no way to ask for the label to be escaped.

The body of a <wicket:label> tag is markup by design and is not affected; it remains the supported way to place markup in a label.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 1.5.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Credit:

Ho1aAs (finder)

References:

https://wicket.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-76983

Severity: moderate

Affected versions:

- Apache Wicket (org.apache.wicket:wicket-core) 8.0.0 through 8.18.0 - Apache Wicket (org.apache.wicket:wicket-core) 9.0.0 through 9.23.0 - Apache Wicket (org.apache.wicket:wicket-core) 10.0.0 through 10.10.0

Description:

Improper neutralization of input during web page generation in Apache Wicket.

org.apache.wicket.markup.head.MetaDataHeaderItem generates <meta> and <link> header tags. It escaped the attribute names it wrote, but ran the attribute values through a replacement of " with \". A backslash before a double quote means nothing in HTML, so a value containing a double quote ends its own attribute and what follows is parsed as further attributes of the generated tag.

An application is affected where it supplies an attribute value holding data an attacker can influence, through addTagAttribute or the forMetaTag and forLinkTag factory methods. A value may be given as an IModel, so it is not necessarily a literal.

There is no setting to change; an application can only avoid supplying a value that contains a double quote. Note that these values have never been escaped effectively: before the change released in 6.24.0, 7.4.0 and 8.0.0 they were written with no escaping at all.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 6.17.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Credit:

Emond Papegaaij (finder)

References:

https://wicket.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-76984

Severity: moderate

Affected versions:

- Apache Wicket (org.apache.wicket:wicket-extensions) 8.0.0 through 8.18.0 - Apache Wicket (org.apache.wicket:wicket-extensions) 9.0.0 through 9.23.0 - Apache Wicket (org.apache.wicket:wicket-extensions) 10.0.0 through 10.10.0

Description:

Improper neutralization of input during web page generation in Apache Wicket.

org.apache.wicket.extensions.markup.html.form.palette.component.AbstractOptions, which renders the two option lists of a Palette, escapes the id and the display value of each option according to the escape-model-strings setting, and wrote the attribute names and values returned by getAdditionalAttributes into the <option> tag as they came.

An application is affected where it overrides Palette.getAdditionalAttributesForChoices, Palette.getAdditionalAttributesForSelection or AbstractOptions.getAdditionalAttributes and returns a value holding data an attacker can influence. These methods return null by default, so an application that does not override them is not affected.

As a workaround, escape the values in the override.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 1.4.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Credit:

Emond Papegaaij (finder)

References:

https://wicket.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-76985

Severity: moderate

Affected versions:

- Apache Wicket (org.apache.wicket:wicket-core) 8.0.0 through 8.18.0 - Apache Wicket (org.apache.wicket:wicket-core) 9.0.0 through 9.23.0 - Apache Wicket (org.apache.wicket:wicket-core) 10.0.0 through 10.10.0

Description:

Improper neutralization of input during web page generation in Apache Wicket.

org.apache.wicket.markup.html.form.AbstractSingleSelectChoice, the base class of DropDownChoice, writes the body of the default option — the entry shown when no choice is selected — into the markup as it is, while every other option body in the same select is escaped according to the escape-model-strings setting. The body comes from getNullValidDisplayValue() or getNullKeyDisplayValue(), both of which are protected, so what they return is not necessarily the plain text the default implementation reads from a resource bundle.

An application is affected where it overrides one of those methods and returns a value holding data an attacker can influence, or where its own nullValid or null bundle entry holds such a value. The bundles shipped with Wicket contain plain text. RadioChoice overrides getDefaultChoice to emit no default option and is not affected.

As a workaround, escape the value in the override.

This issue affects Apache Wicket: from 8.0.0 through 8.18.0, from 9.0.0 through 9.23.0, from 10.0.0 through 10.10.0. Older, unsupported releases from 1.5.0 onwards are also affected. Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue.

Credit:

Emond Papegaaij (finder)

References:

https://wicket.apache.org/ https://www.cve.org/CVERecord?id=CVE-2026-76986

ResourceIsolationRequestCycleListener protects a Wicket application against cross-site request forgery by rejecting requests that a resource isolation policy judges to come from another origin. Its default policy, FetchMetadataResourceIsolationPolicy, was derived from a reference implementation written to guard static resources, and it inherited two allowances that are unsafe when the thing being guarded is an action on a page: Every "simple top-level navigation" was allowed. Any GET request carrying Sec-Fetch-Mode: navigate whose Sec-Fetch-Dest was neither object nor embed was allowed, whatever Sec-Fetch-Site said — including cross-site. Wicket invokes component listeners (Link.onClick(), form submits, behaviour callbacks) through ordinary GET navigations, so a page under an attacker's control could navigate the victim's browser to a listener URL and have that listener run inside the victim's authenticated session. Browsers send SameSite=Lax cookies — the effective default when no SameSite attribute is set — on cross-site top-level GET navigations, so the victim's session cookie accompanied the request. Sec-Fetch-Site: same-site was allowed unconditionally. That value means the same registrable domain and scheme but a different origin — another subdomain or another port. Any sibling origin could therefore invoke any listener by any method, POST form submits included, and cookies are always sent on same-site requests regardless of SameSite. A hostile sibling origin obtained through a subdomain takeover, through delegated user content, or through an XSS elsewhere on the site could act as the authenticated user. Users are recommended to upgrade to version 9.24.0 or 10.11.0, which fix the issue. Affected versions

Apache Wicket 9.1.0 through 9.23.0 Apache Wicket 10.0.0 through 10.10.0

Not affected

Any release older than 9.1.0: Apache Wicket 8.x (8.0.0 through 8.17.0). The resource isolation classes do not exist in the 8.x line, which offers only the Origin/Referer-based CsrfPreventionRequestCycleListener. No 8.x release requires a fix. Apache Wicket 9.0.0. ResourceIsolationRequestCycleListener and FetchMetadataResourceIsolationPolicy were introduced by WICKET-6786 and first shipped in 9.1.0 (released 2020-10-07).