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 SkyWalking versions from 9.6.0 through 11.0.0 have a vulnerability where the PagerDuty alarm hook transmits the integration routing key over unencrypted HTTP. Although PagerDuty redirects HTTP requests to HTTPS, the initial POST containing sensitive information is sent in cleartext before the redirect occurs. This exposure could allow interception of the routing key during transmission. Users are advised to upgrade to version 11.0.0 where this issue is fixed.
Apache Allura versions up to 1.20.0 contain a Server-Side Request Forgery (SSRF) vulnerability in its webhook functionality. This vulnerability allows unauthenticated attackers to induce the server to make HTTP requests to arbitrary domains. The issue is fixed in version 1.21.0. The vulnerability has a high severity with a CVSS score of 9.1, indicating critical impact on confidentiality and integrity without requiring user interaction or privileges.
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.
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.
CVE-2026-76986 is a cross-site scripting (XSS) vulnerability in Apache Wicket affecting versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0. The issue arises because the default option body in select components is not escaped properly when overridden by an application, allowing potentially attacker-controlled data to be injected into web pages. Apache Wicket versions 8.19.0, 9.24.0, and 10.11.0 or later fix this issue. The vulnerability has a CVSS score of 6.1, indicating medium severity.
CVE-2026-76985 is a medium severity cross-site scripting (XSS) vulnerability in Apache Wicket affecting versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0. The issue arises when applications override certain methods to add additional attributes to <option> tags in a Palette component without properly escaping attacker-controlled input. This improper neutralization can lead to XSS attacks. Fixed versions are 8.19.0, 9.24.0, and 10.11.0.
CVE-2026-76983 is a cross-site scripting (XSS) vulnerability in Apache Wicket affecting versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0. The issue arises because the <wicket:label> tag renders label content without escaping, allowing untrusted input to be interpreted as markup. This affects applications where form component labels can be influenced by attackers. There is no workaround, but upgrading to Apache Wicket versions 8.19.0, 9.24.0, or 10.11.0 resolves the issue.
CVE-2026-76984 is a cross-site scripting (XSS) vulnerability in Apache Wicket affecting versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0. The issue arises from improper escaping of attribute values in meta and link header tags, allowing injection of malicious content if an attacker can control attribute values containing double quotes. The vulnerability is fixed in versions 8.19.0, 9.24.0, and 10.11.0.
CVE-2026-76982 is a cross-site scripting (XSS) vulnerability in Apache Wicket affecting versions from 8.0.0 through 8.18.0, 9.0.0 through 9.23.0, and 10.0.0 through 10.10.0. The issue arises because the Button component clears the escape-model-strings flag for attribute encoding but does not encode the element body when rendering a <button> element, allowing unescaped markup from the model to be rendered. This can lead to XSS if an attacker can influence the model data rendered inside a <button> element. The vulnerability affects Button and its subclasses AjaxButton, AjaxFallbackButton, and WizardButton. Users are recommended to upgrade to fixed versions 8.19.0, 9.24.0, or 10.11.0.
Apache Wicket contains a cross-site scripting (XSS) vulnerability in AjaxEditableChoiceLabel and related components where HTML escaping is not applied to certain display values. This allows an attacker who can influence the choice or model data to inject malicious scripts that execute in the browser of users viewing the affected pages. The issue affects multiple versions of Apache Wicket and is fixed in versions 8.19.0, 9.24.0, and 10.11.0.
CVE-2026-71378 is a Cross-Site Request Forgery (CSRF) vulnerability in Apache Wicket's ResourceIsolationRequestCycleListener, affecting versions 9.1.0 through 9.23.0 and 10.0.0 through 10.10.0. The default resource isolation policy allows unsafe cross-origin and same-site requests that can be exploited to invoke component listeners within an authenticated session. This can enable an attacker controlling a page or a sibling origin to perform actions on behalf of a user. Versions prior to 9.1.0 are not affected as the vulnerable classes do not exist. The issue is fixed in versions 9.24.0 and 10.11.0.
Apache Wicket enforces the upload limits configured on a form or upload field while parsing a multipart request with Apache Commons FileUpload. If the request body has already been consumed by another component, Commons FileUpload returns no items and Wicket falls back to reading the upload through HttpServletRequest#getParts(). The per-file size limit (for example Form#setFileMaxSize) and the file count limit (Form#setFileCountMax) are not applied to the parts obtained that way, and no exception is raised, so the upload is processed as though those limits had been satisfied. A remote uploader can therefore submit files that are larger, or more numerous, than the application permits, up to whatever the component that parsed the request allows. A part carrying no Content-Type header is additionally read into memory in full during parsing, so the size of that allocation is determined by the request and bounded only by those same external limits.
The total upload size limit (Form#setMaxSize) is not affected. Commons FileUpload compares the declared Content-Length against it before reading the body, so a request declaring an oversized length is rejected before the fallback is reached.
The fallback is reached in deployments where a servlet or filter has already parsed the request body — for example a servlet annotated with @MultipartConfig, Spring Boot's multipart resolver, or any filter that calls HttpServletRequest#getParameter() on a multipart request. It applies to the Wicket components that accept uploads on that path, including Form with FileUploadField, FileUploadToResourceField and AjaxFileDropBehavior. Applications that configure neither a per-file nor a file-count limit are not affected, as Wicket applies neither by default.
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.
Users are recommended to upgrade to version 8.19.0, 9.24.0 or 10.11.0, which fix the issue. Users of Apache Wicket 7.x or older, which are no longer supported, should upgrade to a supported version. As a workaround, configure equivalent limits in the component that parses the request — for example spring.servlet.multipart.max-file-size and max-request-size, or maxFileSize and maxRequestSize in @MultipartConfig or in the web.xml <multipart-config> element.
Apache Wicket versions up to 8.18.0, 9.23.0, and 10.10.0 contain a path traversal vulnerability due to improper validation of resource URL attributes. This flaw allows unauthenticated remote attackers to read certain files from the web application, including some under WEB-INF that are normally protected. The vulnerability arises because attacker-controlled path components are appended after initial security checks, enabling crafted requests to escape intended directory restrictions. The default resource guard limits accessible file types, but custom configurations may expose sensitive configuration files. Fixed versions are 8.19.0, 9.24.0, and 10.11.0.
CVE-2026-58301 is a server-side request forgery (SSRF) vulnerability in Apache Shiro when used with the Jakarta EE integration module. It allows a low-privileged user to craft HTTP requests that cause the server to connect to attacker-controlled URLs and send attacker-controlled data. This affects Apache Shiro versions from 2.0.0-alpha-0 up to and including 3.0.0. The issue is fixed in version 3.0.1 and later. Alternatively, system properties can be set to restrict allowed hosts and ports for form resubmission connections.
CVE-2026-74848 is a high-severity vulnerability in Apache APISIX affecting versions from 2.12.0 through 3.17.0. It involves inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, which can cause clients to receive responses intended for other users on serverless-plugin routes. The issue is fixed in version 3.18.0.
CVE-2026-75005 is an Inefficient Algorithmic Complexity vulnerability in Apache APISIX version 3.17.0. A specially crafted small request targeting graphql-limit-count routes can cause a gateway worker to consume 100% CPU for an extended period. This can degrade service performance or availability. The issue is fixed in Apache APISIX version 3.18.0.
CVE-2026-75020 is an LDAP Injection vulnerability in Apache APISIX that allows a user with valid LDAP credentials to authenticate as a different consumer than intended. This affects versions from 2.11.0 through 3.17.0. The issue is fixed in version 3.18.0. The vulnerability has a high severity score of 7.0.
CVE-2026-63041 is a medium severity vulnerability in Apache APISIX affecting versions from 3.11.0 through 3.17.0. It involves reliance on untrusted inputs in a security decision within the attach-consumer-label plugin, which does not properly sanitize certain values. This flaw can allow an attacker to escalate privileges or bypass authorization. The issue is fixed in Apache APISIX version 3.18.0.