| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| 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. |
| ** 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. |
| 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. |
| ** 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. |
| 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. |
| 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. |
| 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. |
| 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. |
| this attack requires control over the search index, which is considered fully trusted by Lucy. |
| ** UNSUPPORTED WHEN ASSIGNED ** Stack-based Buffer Overflow vulnerability in Apache Lucy.
This issue affects Apache Lucy: 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.
Lucy is now maintained outside of the ASF
at https://github.com/lucysearch . This issue has been fixed in 0.8.0 there.
NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| ** UNSUPPORTED WHEN ASSIGNED ** Deserialization of Untrusted Data vulnerability in Apache Lucy.
This issue affects Apache Lucy: 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.
Lucy is now maintained outside of the ASF at https://github.com/lucysearch . 0.8.0 is no longer affected by this issue, because the offending feature has been removed there.
NOTE: This vulnerability only affects products that are no longer supported by the maintainer. |
| ** UNSUPPORTED WHEN ASSIGNED ** Uncontrolled Recursion vulnerability in Apache Lucy.
This issue affects Apache Lucy: 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 ASF. Lucy is now maintained outside of the ASF at https://github.com/lucysearch |
| SSRF via set_skywalking_url Tool and GraphQL expression injection vulnerability in Apache SkyWalking MCP.
This issue affects Apache SkyWalking MCP: 0.1.0.
Users are recommended to upgrade to version 0.2.0, which fixes this issue. |
| Buffer Over-read vulnerability in Apache HTTP Server via outbound OCSP requests to an attacker controlled OCSP server
This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.
Users are recommended to upgrade to version 2.4.68, which fixes the issue. |
| Heap-based Buffer Overflow vulnerability in Apache HTTP Server with mod_xml2enc, xml2StartParse, and untrusted content
This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.
Users are recommended to upgrade to version 2.4.68, which fixes the issue. |
| A buffer overflow in mod_proxy_html in Apache HTTP Server 2.4.67 and earlier allows an attack by an untrusted backend.
Users are recommended to upgrade to version 2.4.68, which fixes this issue. |
| Heap-based Buffer Overflow vulnerability in mod_proxy_ajp of Apache HTTP Server.
If mod_proxy_ajp connects to a malicious AJP server this AJP server can send a malicious AJP message back to mod_proxy_ajp and cause it to write 4 attacker controlled bytes after the end of a heap based buffer.
This issue affects Apache HTTP Server: through 2.4.66.
Users are recommended to upgrade to version 2.4.67, which fixes the issue. |
| 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. |
| Improper validation of resource URL attributes in Apache Wicket allows an unauthenticated remote attacker to read files from the web application, including files under WEB-INF that the servlet container would not otherwise serve.
The locale, style and variation attributes decoded from a package resource URL are spliced into the resource lookup path without being checked for path separators. The IPackageResourceGuard — whose rejection of .. is one of the two intended controls — is applied to the resource name before those attributes are appended, and WebApplicationPath rejects only paths literally beginning with WEB-INF/. Neither control ever inspects the attacker-controlled portion of the path. On servlet containers that normalize .. in ServletContext.getResource(), a crafted request therefore escapes the intended package directory.
The set of readable files is limited to the file extensions permitted by the configured IPackageResourceGuard. The default SecurePackageResourceGuard permits only js, css, png, jpg, jpeg, gif, ico, cur, map, html, txt, swf, bmp, svg, avif, eot, ttf, woff and woff2, which excludes configuration formats. Applications that have added patterns to the guard, or replaced it with the blocklist-based PackageResourceGuard, can additionally disclose configuration files such as web.xml. Independently of the extension, the lookup performed before the guard runs acts as an existence oracle for arbitrary paths.
This issue affects Apache Wicket 8.18.0 and before, 9.23.0 and before and 10.10.0 and before.
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. |
