Overview 181 matches · 5 exploited · 0 CISA KEV · 26 public PoC · 11 EPSS ≥ 0.5
Protected by Waratek
181
100.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
blocked by ARMR today
181
100.0%
partly blocked
0
0.0%
not blocked
0
0.0%
not established
0
0.0%
unrecorded
0
0.0%
split by
peak 36 / year
20021
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
20031
Protected by Waratek1
Medium1
blocked by ARMR today1
Working exploit published1
20040
20050
20062
Protected by Waratek2
Medium2
blocked by ARMR today2
Working exploit published1
No public exploit1
20070
20084
Protected by Waratek4
Medium4
blocked by ARMR today4
Exploited1
Working exploit published3
20094
Protected by Waratek4
Medium4
blocked by ARMR today4
Working exploit published2
No public exploit2
20103
Protected by Waratek3
Medium3
blocked by ARMR today3
Working exploit published1
No public exploit2
20111
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
20121
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
20134
Protected by Waratek4
Medium4
blocked by ARMR today4
Exploited2
No public exploit2
20145
Protected by Waratek5
Medium5
blocked by ARMR today5
Working exploit published1
Proof of concept only1
No public exploit3
20156
Protected by Waratek6
Medium6
blocked by ARMR today6
Exploited1
Working exploit published2
No public exploit3
20163
Protected by Waratek3
Medium3
blocked by ARMR today3
Working exploit published1
No public exploit2
20173
Protected by Waratek3
Medium3
blocked by ARMR today3
Working exploit published2
No public exploit1
201820
Protected by Waratek20
Medium20
blocked by ARMR today20
Working exploit published2
No public exploit18
201913
Protected by Waratek13
Medium13
blocked by ARMR today13
Exploited1
Working exploit published2
No public exploit10
202011
Protected by Waratek11
Medium11
blocked by ARMR today11
Working exploit published1
No public exploit10
20216
Protected by Waratek6
Medium6
blocked by ARMR today6
Working exploit published1
No public exploit5
202227
Protected by Waratek27
Medium27
blocked by ARMR today27
Proof of concept only1
No public exploit26
202311
Protected by Waratek11
Medium11
blocked by ARMR today11
Proof of concept only2
Forecast only1
No public exploit8
20247
Protected by Waratek7
Medium7
blocked by ARMR today7
Working exploit published1
No public exploit6
202512
Protected by Waratek12
Medium12
blocked by ARMR today12
Working exploit published1
Proof of concept only6
No public exploit5
202636
Protected by Waratek36
Medium36
blocked by ARMR today36
Proof of concept only4
No public exploit32
2002200420062008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2026-75598 | Medium | 2026-11-06 | Protected by Waratek | Proof of concept only | The Gradle Shadow plugin creates fat or uber JARs and supports file transformation and package relocation. Prior to version 9.6.0, Shadow does not independently validate ZIP entry names before writing them to its output archive. A malicious dependency can cause traversal entry names to be preserved when the applicable archive-processing path does not reject them. Some affected Shadow implementations process dependency archives directly, so upgrading Gradle alone does not universally prevent this behavior. If the resulting archive is extracted without path traversal protection, attacker-controlled files can be written outside the intended destination. This issue is fixed in version 9.6.0. |
| CVE-2026-63436 | Medium | 2026-11-03 | Protected by Waratek | Proof of concept only | zt-zip is a Java library that provides convenience methods for ZIP archive manipulation. Prior to 1.18.0, the Zips.get(zip).unpack().destination(outputDir).process() fluent API in src/main/java/org/zeroturnaround/zip/Zips.java constructs output files directly from ZIP entry names without applying the destination-boundary validation used by ZipUtil.unpack(...). A crafted entry containing parent-directory traversal can therefore write outside outputDir through both the normal copy branch and the ZipEntryTransformer branch. Applications that extract untrusted archives only through ZipUtil.unpack(...) are unaffected because that API already calls checkDestinationFileForTraversal. This issue is fixed in version 1.18.0. |
| CVE-2026-117626 | Medium | 2026-10-28 | Protected by Waratek | No public exploit | Jenkins 2.587 and earlier, LTS 2.580.1 and earlier improperly identifies file paths attempting path traversal in the file browser for workspaces and $JENKINS_HOME/userContent/, allowing attackers with Overall/Read permission to obtain the names, sizes, and last modification times of files in the $JENKINS_HOME, and attackers with Item/Workspace permission to obtain the names of jobs that have a workspace on the same agent. |
| CVE-2026-95629 | Medium | 2026-10-26 | Protected by Waratek | No public exploit | Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer runs the external docling tool in CLI mode, the default, and tells it where to write the converted document through the --output flag. When the CamelDoclingOutputFilePath header was set, addOutputDirectoryArguments handed its value to that flag verbatim: the value was not normalized, an absolute path or a path containing .. segments was accepted as given, and no endpoint option could confine it to a directory. The custom-argument validation added by the fix for CVE-2026-40047 refuses the --output and -o flags in the CamelDoclingCustomArguments header and tells callers to choose the output directory with this header instead, so the one value that decides where docling writes reached the command line without any of the checks applied to custom arguments. Docling writes the conversion result, as Markdown, HTML, JSON or text, into that directory, naming the file after the input file, and the producer afterwards removes only its own temporary directory, so the file is left in place. A party able to set the header could therefore have conversion output created in any directory the Camel process can write to. The content of such a file is the conversion of the document carried by the message, so it is shaped by whoever supplies that document without being written byte for byte, and when the document content arrives in the message body the producer stores it under a random temporary name, which the output file then carries. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. The docling-serve mode does not use the header. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The fix adds an outputBaseDirectory endpoint option that is unset by default, so after upgrading, set it on every docling endpoint whose CamelDoclingOutputFilePath header can carry a value influenced from outside the deployment; without it the header is normalized but can still name any directory. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingOutputFilePath header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the output directory. |
| CVE-2026-95628 | Medium | 2026-10-26 | Protected by Waratek | No public exploit | Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.2. DoclingProducer builds the command line of the external docling tool and appends to it the custom arguments supplied in the CamelDoclingCustomArguments header, a list of strings whose flags the fix for CVE-2026-40047 restricted to an allowlist. That fix also introduced validatePathSafety to keep path-like argument values inside the intended directory, but the method only looked for relative traversal: it rejected a value containing a traversal sequence such as ../ and a value whose normalized form still held a .. element. It never checked whether a value was an absolute path, and an absolute path without traversal segments contains neither, so it passed unchanged. Every path-like value went through this check, whether it was a separate list element following its flag or was attached to the flag after an equals sign, so an absolute path was accepted in either form, for example as the directory given to the allowlisted --artifacts-path flag, which tells docling where to find its model artifacts. Such a value reached the docling command line as given, so a party able to choose the custom arguments could point the docling process at any directory the Camel process can access, outside the working directory that the check was meant to keep path values in, which is the outcome the CVE-2026-40047 fix set out to prevent. Only the CLI mode, which is the default, passes custom arguments to docling. The header belongs to the Camel header namespace, which consumers applying Camel's default header filtering, such as the JMS and Kafka consumers, remove from incoming messages, so the issue is reached where a route forwards externally influenced values into the header or where a consumer maps incoming headers without that filtering. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not build the CamelDoclingCustomArguments header from values that originate outside the deployment, remove that header from messages that arrive from outside before they reach a docling endpoint, and make sure that consumers which map incoming message headers drop the Camel header namespace, so that only the route itself chooses the custom arguments. |
| CVE-2026-110748 | Medium | 2026-10-26 | Protected by Waratek | No public exploit | This issue affects Apache SIS from version 0.7 through 1.6 inclusive. When a data file contains links to other files, Apache SIS opened these files regardless their paths. It was possible, for example, to specify a path to a local file. However, these files were always expected to be in some specific formats and the reading stops at the first parsing error, which makes this vulnerability unlikely to leak sensitive information. The impacted formats are: * Geographic Markup Language (GML) with `xlink:href` attributes for other files in GML format. * Well Known Text (WKT) with parameter elements for datum shift grids in NADCON, NTv2 or RGF93 formats. * Landsat scene with paths to files for each band in the GeoTIFF format. Users are recommended to upgrade to version 1.7, which fixes the issue by restricting the paths to the same directory as the file containing the references to other files, or to a predetermined directory for datum shift grids. |
| CVE-2026-78163 | Medium | 2026-10-19 | Protected by Waratek | No public exploit | Server-Side Request Forgery (SSRF), Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') and Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Camel Docling component. This issue affects Apache Camel: from 4.15.0 before 4.18.5, from 4.19.0 before 4.22.1. DoclingProducer decided what a String message body meant by inspecting its prefix. A body starting with http:// or https:// was handed to Docling as a remote URL to fetch, a body starting with / or containing a backslash was read from the local filesystem, and anything else was written to a temporary file and converted as document content. The mode was chosen implicitly and no endpoint option allowed a route author to pin the component to a single interpretation, so a route that means convert whatever text arrives in the body silently became a fetcher of remote resources or a reader of local files whenever the text happened to begin with one of those prefixes. The only guard applied to the derived value was a size check, and that check was wrapped in an existence test, so a path that resolved to nothing, or to a pseudo-file reporting a size of zero, passed without being checked at all. Five call sites reached the two sinks: the CLI mode appended the value as the final positional argument of the docling subprocess, and the docling-serve mode passed it either to HttpSource for the backend to fetch or to Files.readAllBytes so that the content could be base64-encoded and uploaded. Because the exchange body is never filtered by a HeaderFilterStrategy, unlike the Camel header namespace, a sender able to place text in a message that a route forwards into a docling endpoint could reach both sinks without any opt-in from the deployment. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.1. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier reached end of life before this issue was resolved and will not receive a fix, so deployments on those lines must move to a supported release. For deployments that cannot upgrade immediately, do not route message bodies that originate outside the deployment into a docling endpoint, and pass the document through a typed body such as File, byte[] or InputStream, or through the CamelDoclingInputFilePath header, so that the body is never subject to prefix interpretation. |
| CVE-2026-79715 | Medium | 2026-10-13 | Protected by Waratek | No public exploit | IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.9 could allow a local attacker to traverse directories on the system. An attacker could use a specially crafted application archive to write files outside the intended directory. |
| CVE-2026-104721 | Medium | 2026-10-02 | Protected by Waratek | No public exploit | Path-traversal vulnerability in QOS.CH Sarl Logback-classic on Java (logback-classic module) allows path-traversal vulnerability. More specifically, an MDC-based discriminator value flows unsanitized into a nested FileAppender path, letting an attacker who influences that MDC value (e.g. via an HTTP header) create and append log files outside the intended directory. This issue affects Logback-classic: from 0.9.14 through 1.6.4. This vulnerability is similar to CVE-2026-19880 but involves other attack techniques. |
| CVE-2026-103884 | Medium | 2026-10-01 | Protected by Waratek | No public exploit | A flaw was found in the X.509 client certificate authenticator of Keycloak. When CRL Distribution Point checking is enabled, the server fails to properly validate the file paths provided in a client certificate. An attacker can provide a specially crafted certificate that causes the server to attempt to read sensitive files from the local system or exhaust memory by loading extremely large files, potentially leading to information disclosure or a system crash. |
| CVE-2026-65829 | Medium | 2026-09-22 | Protected by Waratek | No public exploit | MPXJ is an open source library to read and write project plans from a variety of file formats and databases. From 7.3.0 until 16.5.0, reading a suitably crafted Primavera P3 PRX or SureTrak STX file can cause MPXJ to write files to arbitrary locations in the filesystem. This issue is fixed in version 16.5.0. |
| CVE-2026-81829 | Medium | 2026-09-17 | Protected by Waratek | No public exploit | A flaw was found in SmallRye JWT's AwsAlbKeyResolver, which is used by applications to verify JSON Web Tokens signed by AWS Application Load Balancers. When the AWS_ALB key provider is configured, the resolver constructs the key-fetch URL by directly concatenating the attacker-controlled kid header value from an inbound JWT without sanitizing path traversal characters or query-string separators. This allows an unauthenticated remote attacker to force the application server to issue GET requests to arbitrary paths on the same origin as the configured key endpoint. As a result, non-public endpoints or internal data reachable on that origin may be read by the attacker before JWT signature verification takes place. |
| CVE-2026-92131 | Medium | 2026-09-16 | Protected by Waratek | No public exploit | Jenkins Pipeline: Groovy Libraries Plugin 805.va_fc79344957d and earlier does not restrict the library path provided to the library Pipeline step to a relative path inside the SCM checkout, and follows symbolic links to locations outside of the SCM checkout when retrieving the library, resulting in a path traversal vulnerability, allowing attackers able to configure Pipelines to read files in a resources directory and to delete files in a test directory on the Jenkins controller file system. |
| CVE-2026-69201 | Medium | 2026-09-15 | Protected by Waratek | No public exploit | Http4s is a Scala interface for HTTP services. Prior to 0.23.35 and 1.0.0-M47, ResourceService and WebjarService decode each URL path segment but reject only segments exactly equal to an empty string, a dot, or two dots. A request containing percent-encoded slash or backslash separators can turn an accepted segment into a parent-directory traversal after decoding, allowing access to classpath or WebJar resources outside the configured base when a directory-backed classpath is served and the backend preserves the encoded separator. The patch rejects decoded segments containing slash or backslash in ResourceService and WebjarService, and applies the same guard to the non-exploitable FileService for consistency. This issue is fixed in versions 0.23.35 and 1.0.0-M47. |
| CVE-2026-82426 | Medium | 2026-09-14 | Protected by Waratek | No public exploit | Description Nimbus accepted the `uploadedJarLocation` argument of `submitTopology` / `submitTopologyWithOpts` as a server-side path and opened it directly, without checking that it referred to a file the caller had actually uploaded. The intended flow is that a client first calls `beginFileUpload`, which returns a path inside the Nimbus inbox, and uploads the jar in chunks to that location; nothing bound submission to that flow, and the `uploaders` map populated by `beginFileUpload` was never consulted at submit time. An authenticated user with topology submission rights could therefore submit any path readable by the Nimbus daemon user as their topology jar. Nimbus copied the file into the topology's jar blob, and the blob ACL grants the submitting subject read access, so the contents could then be retrieved with the ordinary blob download RPCs. Candidate targets include the Nimbus Kerberos keytab, Thrift and UI TLS private keys, and `storm.yaml` with the ZooKeeper authentication payload. Possession of the Nimbus keytab turns an ordinary tenant into a cluster administrator. In a deployment configured as the documentation recommends, submission is available to every authenticated principal when `nimbus.users` is unset, so no elevated privilege is required. Mitigation Upgrade to 3.1.0, where the submitted location is canonicalised and must resolve inside the Nimbus inbox. Users who cannot upgrade immediately should restrict topology submission to trusted principals via `nimbus.users` or `nimbus.groups`, and should treat any file readable by the Nimbus daemon user as potentially exposed to submitters: rotate the Nimbus keytab and any TLS private keys or ZooKeeper credentials reachable from that account. Local mode is unaffected. Credit Independently reported to the Apache Storm PMC by n0mi1k, with a proof of concept. Also found by the ASF using Claude agents to study the security of open-source projects, validated and reported by Apache Storm. |
| CVE-2026-55846 | Medium | 2026-09-14 | Protected by Waratek | Proof of concept only | Allure 2 is the version 2.x branch of Allure Report, a multi-language test reporting tool. Prior to 2.39.0, the HTTP server started by allure serve and allure open uses URI.getPath() in Commands.setUpServer() in allure-commandline/src/main/java/io/qameta/allure/Commands.java and passes the percent-decoded request path to reportDirectory.resolve() without normalizing the result or confirming that it remains inside that directory. An unauthenticated client that can reach the server can submit parent-directory segments, including percent-encoded segments, and cause serveFile() to return any regular file readable by the Allure process. The server binds to localhost by default, but the --host option can expose it to other systems, and local users, adjacent containers, or browser-origin attacks may reach a local listener. This can disclose credentials, configuration, source code, build secrets, and other CI/CD data. This issue is fixed in version 2.39.0. |
| CVE-2026-19729 | Medium | 2026-09-09 | Protected by Waratek | No public exploit | A flaw was found in the key provider component of the keycloak-services library, which is the core engine for the Red Hat Build of Keycloak. The issue occurs because a previous fix for path probing was incomplete, allowing a realm administrator to still submit arbitrary filesystem paths as keystore parameters. This can be used to determine the existence and readability of files on the server, potentially exposing sensitive system information. |
| CVE-2026-49833 | Medium | 2026-09-02 | Protected by Waratek | No public exploit | DSpace open source software is a repository application which provides durable access to digital resources. From versions 8.0-rc1 to before 8.4, 9.0-rc1 to before 9.3, and 10-rc1 to before 10.0, a path traversal vulnerability is possible via the COAR Notify / LDN service in DSpace. The attacker MUST already have DSpace administrator credentials in order to perform the attack. When reading a file input stream of an "inbound pattern" / "template", used to generate an LDN message, the LDN class does not check for path traversal or restrict the templates to a known base path. This could allow an untrusted file from elsewhere in the file system (e.g. an export log, a bitstream path, a temporary file) to be read and interpreted as an Apache Velocity template. This issue has been patched in versions 8.4, 9.3, and 10.0. |
| CVE-2026-49831 | Medium | 2026-09-02 | Protected by Waratek | No public exploit | DSpace open source software is a repository application which provides durable access to digital resources. Prior to versions 7.6.7, 8.4, 9.3, and 10.0, the Curation Task feature allows an output path to be used by the reporter (-r parameter), typically used to stream results and status of curation task operations. It is not restricted to any particular base path, meaning that any path writable by the DSpace (often 'tomcat') user is allowed. This constitutes a Path Traversal Vulnerability in the curate script. This issue has been patched in versions 7.6.7, 8.4, 9.3, and 10.0. |
| CVE-2026-70449 | Medium | 2026-08-31 | Protected by Waratek | No public exploit | 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. |
| CVE-2026-59280 | Medium | 2026-08-27 | Protected by Waratek | No public exploit | Applications using Spring Framework's FreeMarker integration may be vulnerable to a path traversal attack when a controller returns a view name derived from untrusted input and FreeMarker is configured to resolve templates through SpringTemplateLoader. Spring Framework 7.0.0 - 7.0.8 Spring Framework 6.2.0 - 6.2.19 Spring Framework 6.1.0 - 6.1.28 Spring Framework 6.0.0 - 6.0.30 Spring Framework 5.3.0 - 5.3.49 Spring Framework 5.2.25.RELEASE and earlier |
| CVE-2026-19880 | Medium | 2026-08-14 | Protected by Waratek | No public exploit | Path-traversal vulnerability in QOS.CH Sarl Logback-classic on Java (logback-classic module) allows path-traversal vulnerability. More specifically, an MDC-based discriminator value flows unsanitized into a nested FileAppender path, letting an attacker who influences that MDC value (e.g. via an HTTP header) create and append log files outside the intended directory. This issue affects Logback-classic: from 0.9.14 through 1.6.2. |
| CVE-2026-70428 | Medium | 2026-08-05 | Protected by Waratek | No public exploit | Jenkins 2.575 and earlier, LTS 2.568.1 and earlier improperly identifies file paths attempting path traversal in file parameter names, allowing attackers with Item/Configure and Item/Build permission to write files to arbitrary locations on the controller file system. |
| CVE-2026-17614 | Medium | 2026-08-04 | Protected by Waratek | No public exploit | A path traversal flaw was found in WildFly's domain mode implementation. The LocalFileRepository.getFile() and getConfigurationFile() methods in wildfly-core/deployment-repository do not validate that the resolved file path remains within the configured repository or configuration root directories. A remote attacker who has obtained the slave host controller secret or compromised a slave host controller can supply a crafted relative path containing directory traversal sequences (e.g., ../../etc/passwd) via the slave-DC wire protocol, causing the Domain Controller to resolve and serve arbitrary files readable by the DC process. This leads to unauthorized disclosure of sensitive information such as configuration files, keystores, and system credentials. |
| CVE-2026-66755 | Medium | 2026-07-30 | Protected by Waratek | No public exploit | Relative Path Traversal in the ISA-Tab parser in Apache Software Foundation Apache Tika from 1.8 through 3.3.1, and 4.0.0-alpha-1, allows an attacker who can place files in a directory that the application subsequently parses to read arbitrary files accessible to the Tika process and have their contents emitted into the extracted text output, via a "Study Assay File Name" value in the ISA-Tab investigation file that traverses outside the dataset directory. Users are recommended to upgrade to version 3.3.2 or 4.0.0-beta-1, which fixes this issue. |
| CVE-2026-26032 | Medium | 2026-07-15 | Protected by Waratek | No public exploit | The PackagerResolver of Apache Ivy is able to download online artifacts and to (re)package them in a format defined by a packager.xml file. This repackaging is done by an Ant script, which is stored in a subdirectory of the configured "buildRoot" directory. This subdirectory is calculated based on modules coordinates, like the organisation, name or version. If one of the coordinates contains "../" sequences - which are valid characters for Ivy coordinates in general- it is possible to break out of the configured "buildRoot" directory where other files can be overwritten. In order to exploit this vulnerability an attacker needs to have access to a packager repository and add or modify the coordinates in ivy.xml files to have such "../" sequences. Users of Apache Ivy 2.0.0 to 2.5.3 (inclusive) should upgrade to Ivy 2.6.0. |
| CVE-2026-9083 | Medium | 2026-06-25 | Protected by Waratek | No public exploit | A flaw was found in Keycloak. A realm administrator with the "manage-realm" role can exploit this vulnerability by submitting an arbitrary filesystem path as a keystore parameter when creating a key provider component. This allows the administrator to probe arbitrary filesystem paths, determining which files exist and are readable by the Keycloak process. This information disclosure could be used to identify high-value targets for follow-on attacks. |
| CVE-2026-41843 | Medium | 2026-06-09 | Protected by Waratek | No public exploit | Spring MVC and WebFlux applications are vulnerable to Path Traversal attacks when resolving static resources. Affected versions: Spring Framework 7.0.0 through 7.0.7; 6.2.0 through 6.2.18; 6.1.0 through 6.1.27; 5.3.0 through 5.3.48. |
| CVE-2026-41863 | Medium | 2026-05-25 | Protected by Waratek | No public exploit | Spring AI's support for Anthropic's Skills API used LLM-influenced filenames unsanitized in Path.resolve before writing files to disk. This could allow a malicious user to write files outside the intended target directory, including restricted directories. Affected versions: Spring AI: 1.1.0 through 1.1.x |
| CVE-2026-43975 | Medium | 2026-05-06 | Protected by Waratek | No public exploit | FolderUploadsFileManager in Apache Wicket does not validate or sanitize the uploadFieldId parameter or the clientFileName before constructing file paths, allowing an unauthenticated attacker to write arbitrary files outside the intended upload directory or read files from arbitrary locations on the server. This issue affects Apache Wicket: from 8.0.0 through 8.17.0, from 9.0.0 through 9.22.0, from 10.0.0 through 10.8.0. Users are recommended to upgrade to version 10.9.0, which fixes the issue. |
| CVE-2026-33929 | Medium | 2026-04-14 | Protected by Waratek | No public exploit | Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache PDFBox Examples. This issue affects the ExtractEmbeddedFiles example in Apache PDFBox: from 2.0.24 through 2.0.36, from 3.0.0 through 3.0.7. Users are recommended to update to version 2.0.37 or 3.0.8 once available. Until then, they should apply the fix provided in GitHub PR 427. The ExtractEmbeddedFiles example contained a path traversal vulnerability (CWE-22) mentioned in CVE-2026-23907. However the change in the releases 2.0.36 and 3.0.7 is flawed because it doesn't consider the file path separator. Because of that, a user having writing rights on /home/ABC could be victim to a malicious PDF resulting in a write attempt to any path starting with /home/ABC, e.g. "/home/ABCDEF". Users who have copied this example into their production code should apply the mentioned change. The example has been changed accordingly and is available in the project repository. |
| CVE-2026-35583 | Medium | 2026-04-07 | Protected by Waratek | No public exploit | Emissary is a P2P based data-driven workflow engine. Prior to 8.39.0, the configuration API endpoint (/api/configuration/{name}) validated configuration names using a blacklist approach that checked for \, /, .., and trailing .. This could potentially be bypassed using URL-encoded variants, double-encoding, or Unicode normalization to achieve path traversal and read configuration files outside the intended directory. This vulnerability is fixed in 8.39.0. |
| CVE-2026-33227 | Medium | 2026-04-07 | Protected by Waratek | No public exploit | Improper validation and restriction of a classpath path name vulnerability in Apache ActiveMQ Client, Apache ActiveMQ Broker, Apache ActiveMQ All, Apache ActiveMQ Web, Apache ActiveMQ. In two instances (when creating a Stomp consumer and also browsing messages in the Web console) an authenticated user provided "key" value could be constructed to traverse the classpath due to path concatenation. As a result, the application is exposed to a classpath path resource loading vulnerability that could potentially be chained together with another attack to lead to exploit. This issue affects Apache ActiveMQ Client: before 5.19.3, from 6.0.0 before 6.2.2; Apache ActiveMQ Broker: before 5.19.3, from 6.0.0 before 6.2.2; Apache ActiveMQ All: before 5.19.3, from 6.0.0 before 6.2.2; Apache ActiveMQ Web: before 5.19.3, from 6.0.0 before 6.2.2; Apache ActiveMQ: before 5.19.3, from 6.0.0 before 6.2.2. Users are recommended to upgrade to version 5.19.4 or 6.2.3, which fixes the issue. Note: 5.19.3 and 6.2.2 also fix this issue, but that is limited to non-Windows environments due to a path separator resolution bug fixed in 5.19.4 and 6.2.3. |
| CVE-2025-66249 | Medium | 2026-03-13 | Protected by Waratek | No public exploit | Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache Livy. This issue affects Apache Livy: from 0.3.0 before 0.9.0. The vulnerability can only be exploited with non-default Apache Livy Server settings. If the configuration value "livy.file.local-dir-whitelist" is set to a non-default value, the directory checking can be bypassed. Users are recommended to upgrade to version 0.9.0, which fixes the issue. |
| CVE-2026-23907 | Medium | 2026-03-10 | Protected by Waratek | No public exploit | This issue affects the ExtractEmbeddedFiles example in Apache PDFBox: from 2.0.24 through 2.0.35, from 3.0.0 through 3.0.6. The ExtractEmbeddedFiles example contains a path traversal vulnerability (CWE-22) because the filename that is obtained from PDComplexFileSpecification.getFilename() is appended to the extraction path. Users who have copied this example into their production code should review it to ensure that the extraction path is acceptable. The example has been changed accordingly, now the initial path and the extraction paths are converted into canonical paths and it is verified that extraction path contains the initial path. The documentation has also been adjusted. |
| CVE-2026-28208 | Medium | 2026-02-26 | Protected by Waratek | Proof of concept only | Junrar is an open source java RAR archive library. Prior to version 7.5.8, a backslash path traversal vulnerability in `LocalFolderExtractor` allows an attacker to write arbitrary files with attacker-controlled content anywhere on the filesystem when a crafted RAR archive is extracted on Linux/Unix. This can often lead to remote code execution (e.g., overwriting shell profiles, source code, cron jobs, etc). Version 7.5.8 has a fix for the issue. |
| CVE-2025-13266 | Medium | 2025-11-17 | Protected by Waratek | Proof of concept only | A security vulnerability has been detected in wwwlike vlife up to 2.0.1. This issue affects the function create of the file vlife-base/src/main/java/cn/wwwlike/sys/api/SysFileApi.java of the component VLifeApi. Such manipulation of the argument fileName leads to path traversal. It is possible to launch the attack remotely. The exploit has been disclosed publicly and may be used. |
| CVE-2025-13265 | Medium | 2025-11-17 | Protected by Waratek | Proof of concept only | A weakness has been identified in lsfusion platform up to 6.1. This vulnerability affects the function unpackFile of the file server/src/main/java/lsfusion/server/physics/dev/integration/external/to/file/ZipUtils.java. This manipulation causes path traversal. It is possible to initiate the attack remotely. |
| CVE-2025-13262 | Medium | 2025-11-17 | Protected by Waratek | Proof of concept only | A vulnerability was determined in lsfusion platform up to 6.1. Affected by this vulnerability is the function UploadFileRequestHandler of the file platform/web-client/src/main/java/lsfusion/http/controller/file/UploadFileRequestHandler.java. Executing manipulation of the argument sid can lead to path traversal. The attack can be executed remotely. The exploit has been publicly disclosed and may be utilized. |
| CVE-2025-13261 | Medium | 2025-11-17 | Protected by Waratek | Proof of concept only | A vulnerability was found in lsfusion platform up to 6.1. Affected is the function DownloadFileRequestHandler of the file web-client/src/main/java/lsfusion/http/controller/file/DownloadFileRequestHandler.java. Performing manipulation of the argument Version results in path traversal. Remote exploitation of the attack is possible. The exploit has been made public and could be used. |
| CVE-2025-62254 | Medium | 2025-10-23 | Protected by Waratek | No public exploit | The ComboServlet in Liferay Portal 7.4.0 through 7.4.3.111, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.2, 2023.Q3.1 through 2023.Q3.5, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not limit the number or size of the files it will combine, which allows remote attackers to create very large responses that lead to a denial of service attack via the URL query string. |
| CVE-2025-11849 | Medium | 2025-10-17 | Protected by Waratek | Proof of concept only | Versions of the package mammoth from 0.3.25 and before 1.11.0; versions of the package mammoth from 0.3.25 and before 1.11.0; versions of the package mammoth before 1.11.0; versions of the package org.zwobble.mammoth:mammoth before 1.11.0 are vulnerable to Directory Traversal due to the lack of path or file type validation when processing a docx file containing an image with an external link (r:link attribute instead of embedded r:embed). The library resolves the URI to a file path and after reading, the content is encoded as base64 and included in the HTML output as a data URI. An attacker can read arbitrary files on the system where the conversion is performed or cause an excessive resources consumption by crafting a docx file that links to special device files such as /dev/random or /dev/zero. |
| CVE-2025-43813 | Medium | 2025-09-29 | Protected by Waratek | No public exploit | Possible path traversal vulnerability and denial-of-service in the ComboServlet in Liferay Portal 7.4.0 through 7.4.3.107, and older unsupported versions, and Liferay DXP 2023.Q4.0 through 2023.Q4.4, 2023.Q3.1 through 2023.Q3.8, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions allows remote attackers to access arbitrary CSS and JSS files and load the files multiple times via the query string in a URL. |
| CVE-2025-41242 | Medium | 2025-08-18 | Protected by Waratek | Working exploit published | Spring Framework MVC applications can be vulnerable to a “Path Traversal Vulnerability” when deployed on a non-compliant Servlet container. An application can be vulnerable when all the following are true: * the application is deployed as a WAR or with an embedded Servlet container * the Servlet container does not reject suspicious sequences https://jakarta.ee/specifications/servlet/6.1/jakarta-servlet-spec-6.1.html#uri-path-canonicalization * the application serves static resources https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-config/static-resources.html#page-title with Spring resource handling We have verified that applications deployed on Apache Tomcat or Eclipse Jetty are not vulnerable, as long as default security features are not disabled in the configuration. Because we cannot check exploits against all Servlet containers and configuration variants, we strongly recommend upgrading your application. |
| CVE-2025-53622 | Medium | 2025-07-15 | Protected by Waratek | No public exploit | DSpace open source software is a repository application which provides durable access to digital resources. Prior to versions 7.6.4, 8.2, and 9.1, a path traversal vulnerability is possible during the import of an archive (in Simple Archive Format), either from command-line (`./dspace import` command) or from the "Batch Import (Zip)" user interface feature. An attacker may craft a malicious Simple Archive Format (SAF) package where the `contents` file references any system files (using relative traversal sequences) which are readable by the Tomcat user. If such a package is imported, this will result in sensitive content disclose, including retrieving arbitrary files or configurations from the server where DSpace is running. The Simple Archive Format (SAF) importer / Batch Import (Zip) is only usable by site administrators (from user interface / REST API) or system administrators (from command-line). Therefore, to exploit this vulnerability, the malicious payload would have to be provided by an attacker and trusted by an administrator (who would trigger the import). The fix is included in DSpace 7.6.4, 8.2 and 9.1. For those who cannot upgrade immediately, it is possible to manually patch the DSpace backend. (No changes are necessary to the frontend.) A pull request exists which can be used to patch systems running DSpace 7.6.x, 8.x or 9.0. Although it is not possible to fully protect the system via workarounds, one may can apply a best practice. Administrators must carefully inspect any SAF archives (they did not construct themselves) before importing, paying close attention to the `contents` file to validate it does not reference files outside of the SAF archives. |
| CVE-2025-46096 | Medium | 2025-06-13 | Protected by Waratek | Proof of concept only | Directory Traversal vulnerability in solon v.3.1.2 allows a remote attacker to conduct XSS attacks via the solon-faas-luffy component |
| CVE-2025-32950 | Medium | 2025-04-22 | Protected by Waratek | No public exploit | Jmix is a set of libraries and tools to speed up Spring Boot data-centric application development. In versions 1.0.0 to 1.6.1 and 2.0.0 to 2.3.4, attackers could manipulate the FileRef parameter to access files on the system where the Jmix application is deployed, provided the application server has the necessary permissions. This can be accomplished either by modifying the FileRef directly in the database or by supplying a harmful value in the fileRef parameter of the `/files` endpoint of the generic REST API. This issue has been patched in versions 1.6.2 and 2.4.0. A workaround is provided on the Jmix documentation website. |
| CVE-2025-24961 | Medium | 2025-02-03 | Protected by Waratek | No public exploit | org.gaul S3Proxy implements the S3 API and proxies requests. Users of the filesystem and filesystem-nio2 storage backends could unintentionally expose local files to users. This issue has been addressed in version 2.6.0. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
| CVE-2024-42499 | Medium | 2024-11-15 | Protected by Waratek | No public exploit | Improper limitation of a pathname to a restricted directory ('Path Traversal') issue exists in FitNesse releases prior to 20241026. If this vulnerability is exploited, an attacker may be able to know whether a file exists at a specific path, and/or obtain some part of the file contents under specific conditions. |
| CVE-2024-49771 | Medium | 2024-10-28 | Protected by Waratek | No public exploit | MPXJ is an open source library to read and write project plans from a variety of file formats and databases. The patch for the historical vulnerability CVE-2020-35460 in MPXJ is incomplete as there is still a possibility that a malicious path could be constructed which would not be picked up by the original fix and allow files to be written to arbitrary locations. The issue is addressed in MPXJ version 13.5.1. |
| CVE-2024-31860 | Medium | 2024-04-09 | Protected by Waratek | No public exploit | Improper Input Validation vulnerability in Apache Zeppelin. By adding relative path indicators(E.g ..), attackers can see the contents for any files in the filesystem that the server account can access. This issue affects Apache Zeppelin: from 0.9.0 before 0.11.0. Users are recommended to upgrade to version 0.11.0, which fixes the issue. |
| CVE-2024-25125 | Medium | 2024-02-14 | Protected by Waratek | No public exploit | Digdag is an open source tool that to build, run, schedule, and monitor complex pipelines of tasks across various platforms. Treasure Data's digdag workload automation system is susceptible to a path traversal vulnerability if it's configured to store log files locally. This issue may lead to information disclosure and has been addressed in release version 0.10.5.1. Users are advised to upgrade. There are no known workarounds for this vulnerability. |
| CVE-2024-24565 | Medium | 2024-01-30 | Protected by Waratek | Working exploit published | CrateDB is a distributed SQL database that makes it simple to store and analyze massive amounts of data in real-time. There is a COPY FROM function in the CrateDB database that is used to import file data into database tables. This function has a flaw, and authenticated attackers can use the COPY FROM function to import arbitrary file content into database tables, resulting in information leakage. This vulnerability is patched in 5.3.9, 5.4.8, 5.5.4, and 5.6.1. |
| CVE-2024-23900 | Medium | 2024-01-24 | Protected by Waratek | No public exploit | Jenkins Matrix Project Plugin 822.v01b_8c85d16d2 and earlier does not sanitize user-defined axis names of multi-configuration projects, allowing attackers with Item/Configure permission to create or replace any config.xml files on the Jenkins controller file system with content not controllable by the attackers. |
| CVE-2023-46749 | Medium | 2024-01-15 | Protected by Waratek | No public exploit | Apache Shiro before 1.13.0 or 2.0.0-alpha-4, may be susceptible to a path traversal attack that results in an authentication bypass when used together with path rewriting Mitigation: Update to Apache Shiro 1.13.0+ or 2.0.0-alpha-4+, or ensure `blockSemicolon` is enabled (this is the default). |
| CVE-2023-46655 | Medium | 2023-10-25 | Protected by Waratek | No public exploit | Jenkins CloudBees CD Plugin 1.1.32 and earlier follows symbolic links to locations outside of the directory from which artifacts are published during the 'CloudBees CD - Publish Artifact' post-build step, allowing attackers able to configure jobs to publish arbitrary files from the Jenkins controller file system to the previously configured CloudBees CD server. |
| CVE-2023-41930 | Medium | 2023-09-06 | Protected by Waratek | No public exploit | Jenkins Job Configuration History Plugin 1227.v7a_79fc4dc01f and earlier does not restrict the 'name' query parameter when rendering a history entry, allowing attackers to have Jenkins render a manipulated configuration history that was not created by the plugin. |
| CVE-2023-37960 | Medium | 2023-07-12 | Protected by Waratek | No public exploit | Jenkins MathWorks Polyspace Plugin 1.0.5 and earlier allows attackers with Item/Configure permission to send emails with arbitrary files from the Jenkins controller file systems. |
| CVE-2023-35887 | Medium | 2023-07-10 | Protected by Waratek | No public exploit | Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Software Foundation Apache MINA. In SFTP servers implemented using Apache MINA SSHD that use a RootedFileSystem, logged users may be able to discover "exists/does not exist" information about items outside the rooted tree via paths including parent navigation ("..") beyond the root, or involving symlinks. This issue affects Apache MINA: from 1.0 before 2.10. Users are recommended to upgrade to 2.10 |
| CVE-2023-33544 | Medium | 2023-06-01 | Protected by Waratek | Proof of concept only | hawtio 2.17.2 is vulnerable to Path Traversal. it is possible to input malicious zip files, which can result in the high-risk files after decompression being stored in any location, even leading to file overwrite. |
| CVE-2023-32985 | Medium | 2023-05-16 | Protected by Waratek | Forecast only | Jenkins Sidebar Link Plugin 2.2.1 and earlier does not restrict the path of files in a method implementing form validation, allowing attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. |
| CVE-2023-2196 | Medium | 2023-05-16 | Protected by Waratek | No public exploit | A missing permission check in Jenkins Code Dx Plugin 3.1.0 and earlier allows attackers with Item/Read permission to check for the existence of an attacker-specified file path on an agent file system. |
| CVE-2022-43771 | Medium | 2023-04-03 | Protected by Waratek | No public exploit | Hitachi Vantara Pentaho Business Analytics Server versions before 9.4.0.0 and 9.3.0.1, including 8.3.x, using the Pentaho Data Access plugin exposes a service endpoint for CSV import which allows a user supplied path to access resources that are out of bounds. |
| CVE-2023-24815 | Medium | 2023-02-09 | Protected by Waratek | Proof of concept only | Vert.x-Web is a set of building blocks for building web applications in the java programming language. When running vertx web applications that serve files using `StaticHandler` on Windows Operating Systems and Windows File Systems, if the mount point is a wildcard (`*`) then an attacker can exfiltrate any class path resource. When computing the relative path to locate the resource, in case of wildcards, the code: `return "/" + rest;` from `Utils.java` returns the user input (without validation) as the segment to lookup. Even though checks are performed to avoid escaping the sandbox, given that the input was not sanitized `\` are not properly handled and an attacker can build a path that is valid within the classpath. This issue only affects users deploying in windows environments and upgrading is the advised remediation path. There are no known workarounds for this vulnerability. |
| CVE-2023-24455 | Medium | 2023-01-26 | Protected by Waratek | No public exploit | Jenkins visualexpert Plugin 1.3 and earlier does not restrict the names of files in methods implementing form validation, allowing attackers with Item/Configure permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. |
| CVE-2023-24449 | Medium | 2023-01-26 | Protected by Waratek | No public exploit | Jenkins PWauth Security Realm Plugin 0.4 and earlier does not restrict the names of files in methods implementing form validation, allowing attackers with Overall/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. |
| CVE-2022-34662 | Medium | 2022-11-01 | Protected by Waratek | No public exploit | When users add resources to the resource center with a relation path will cause path traversal issues and only for logged-in users. You could upgrade to version 3.0.0 or higher |
| CVE-2022-26884 | Medium | 2022-10-28 | Protected by Waratek | No public exploit | Users can read any files by log server, Apache DolphinScheduler users should upgrade to version 2.0.6 or higher. |
| CVE-2022-41235 | Medium | 2022-09-21 | Protected by Waratek | No public exploit | Jenkins WildFly Deployer Plugin 1.0.2 and earlier implements functionality that allows agent processes to read arbitrary files on the Jenkins controller file system. |
| CVE-2022-41231 | Medium | 2022-09-21 | Protected by Waratek | No public exploit | Jenkins Build-Publisher Plugin 1.22 and earlier allows attackers with Item/Configure permission to create or replace any config.xml file on the Jenkins controller file system by providing a crafted file name to an API endpoint. |
| CVE-2021-3856 | Medium | 2022-08-26 | Protected by Waratek | No public exploit | ClassLoaderTheme and ClasspathThemeResourceProviderFactory allows reading any file available as a resource to the classloader. By sending requests for theme resources with a relative path from an external HTTP client, the client will receive the content of random files if available. |
| CVE-2019-25075 | Medium | 2022-08-23 | Protected by Waratek | No public exploit | HTML injection combined with path traversal in the Email service in Gravitee API Management before 1.25.3 allows anonymous users to read arbitrary files via a /management/users/register request. |
| CVE-2022-36007 | Medium | 2022-08-15 | Protected by Waratek | Proof of concept only | Venice is a Clojure inspired sandboxed Lisp dialect with excellent Java interoperability. A partial path traversal issue exists within the functions `load-file` and `load-resource`. These functions can be limited to load files from a list of load paths. Assuming Venice has been configured with the load paths: `[ "/Users/foo/resources" ]` When passing **relative** paths to these two vulnerable functions everything is fine: `(load-resource "test.png")` => loads the file "/Users/foo/resources/test.png" `(load-resource "../resources-alt/test.png")` => rejected, outside the load path When passing **absolute** paths to these two vulnerable functions Venice may return files outside the configured load paths: `(load-resource "/Users/foo/resources/test.png")` => loads the file "/Users/foo/resources/test.png" `(load-resource "/Users/foo/resources-alt/test.png")` => loads the file "/Users/foo/resources-alt/test.png" !!! The latter call suffers from the _Partial Path Traversal_ vulnerability. This issue’s scope is limited to absolute paths whose name prefix matches a load path. E.g. for a load-path `"/Users/foo/resources"`, the actor can cause loading a resource also from `"/Users/foo/resources-alt"`, but not from `"/Users/foo/images"`. Versions of Venice before and including v1.10.17 are affected by this issue. Upgrade to Venice >= 1.10.18, if you are on a version < 1.10.18. There are currently no known workarounds. |
| CVE-2022-36894 | Medium | 2022-07-27 | Protected by Waratek | No public exploit | An arbitrary file write vulnerability in Jenkins CLIF Performance Testing Plugin 64.vc0d66de1dfb_f and earlier allows attackers with Overall/Read permission to create or replace arbitrary files on the Jenkins controller file system with attacker-specified content. |
| CVE-2022-36890 | Medium | 2022-07-27 | Protected by Waratek | No public exploit | Jenkins Deployer Framework Plugin 85.v1d1888e8c021 and earlier does not restrict the name of files in methods implementing form validation, allowing attackers with Item/Read permission to check for the existence of an attacker-specified file path on the Jenkins controller file system. |
| CVE-2022-34173 | Medium | 2022-06-23 | Protected by Waratek | No public exploit | In Jenkins 2.340 through 2.355 (both inclusive) the tooltip of the build button in list views supports HTML without escaping the job display name, resulting in a cross-site scripting (XSS) vulnerability exploitable by attackers with Job/Configure permission. |
| CVE-2022-34172 | Medium | 2022-06-23 | Protected by Waratek | No public exploit | In Jenkins 2.340 through 2.355 (both inclusive) symbol-based icons unescape previously escaped values of 'tooltip' parameters, resulting in a cross-site scripting (XSS) vulnerability. |
| CVE-2022-34171 | Medium | 2022-06-23 | Protected by Waratek | No public exploit | In Jenkins 2.321 through 2.355 (both inclusive) and LTS 2.332.1 through LTS 2.332.3 (both inclusive) the HTML output generated for new symbol-based SVG icons includes the 'title' attribute of 'l:ionicon' (until Jenkins 2.334) and 'alt' attribute of 'l:icon' (since Jenkins 2.335) without further escaping, resulting in a cross-site scripting (XSS) vulnerability. |
| CVE-2022-34170 | Medium | 2022-06-23 | Protected by Waratek | No public exploit | In Jenkins 2.320 through 2.355 (both inclusive) and LTS 2.332.1 through LTS 2.332.3 (both inclusive) the help icon does not escape the feature name that is part of its tooltip, effectively undoing the fix for SECURITY-1955, resulting in a cross-site scripting (XSS) vulnerability exploitable by attackers with Job/Configure permission. |
| CVE-2022-30949 | Medium | 2022-05-17 | Protected by Waratek | No public exploit | Jenkins REPO Plugin 1.14.0 and earlier allows attackers able to configure pipelines to check out some SCM repositories stored on the Jenkins controller's file system using local paths as SCM URLs, obtaining limited information about other projects' SCM contents. |
| CVE-2022-28157 | Medium | 2022-03-29 | Protected by Waratek | No public exploit | Jenkins Pipeline: Phoenix AutoTest Plugin 1.3 and earlier allows attackers with Item/Configure permission to upload arbitrary files from the Jenkins controller via FTP to an attacker-specified FTP server. |
| CVE-2022-28156 | Medium | 2022-03-29 | Protected by Waratek | No public exploit | Jenkins Pipeline: Phoenix AutoTest Plugin 1.3 and earlier allows attackers with Item/Configure permission to copy arbitrary files and directories from the Jenkins controller to the agent workspace. |
| CVE-2022-28148 | Medium | 2022-03-29 | Protected by Waratek | No public exploit | The file browser in Jenkins Continuous Integration with Toad Edge Plugin 2.3 and earlier may interpret some paths to files as absolute on Windows, resulting in a path traversal vulnerability allowing attackers with Item/Read permission to obtain the contents of arbitrary files on Windows controllers. |
| CVE-2022-28146 | Medium | 2022-03-29 | Protected by Waratek | No public exploit | Jenkins Continuous Integration with Toad Edge Plugin 2.3 and earlier allows attackers with Item/Configure permission to read arbitrary files on the Jenkins controller by specifying an input folder on the Jenkins controller as a parameter to its build steps. |
| CVE-2022-27208 | Medium | 2022-03-15 | Protected by Waratek | No public exploit | Jenkins Kubernetes Continuous Deploy Plugin 2.3.1 and earlier allows users with Credentials/Create permission to read arbitrary files on the Jenkins controller. |
| CVE-2022-27203 | Medium | 2022-03-15 | Protected by Waratek | No public exploit | Jenkins Extended Choice Parameter Plugin 346.vd87693c5a_86c and earlier allows attackers with Item/Configure permission to read values from arbitrary JSON and Java properties files on the Jenkins controller. |
| CVE-2022-0673 | Medium | 2022-02-18 | Protected by Waratek | No public exploit | A flaw was found in LemMinX in versions prior to 0.19.0. Cache poisoning of external schema files due to directory traversal. |
| CVE-2022-25188 | Medium | 2022-02-15 | Protected by Waratek | No public exploit | Jenkins Fortify Plugin 20.2.34 and earlier does not sanitize the appName and appVersion parameters of its Pipeline steps, allowing attackers with Item/Configure permission to write or overwrite .xml files on the Jenkins controller file system with content not controllable by the attacker. |
| CVE-2022-25178 | Medium | 2022-02-15 | Protected by Waratek | No public exploit | Jenkins Pipeline: Shared Groovy Libraries Plugin 552.vd9cc05b8a2e1 and earlier does not restrict the names of resources passed to the libraryResource step, allowing attackers able to configure Pipelines permission to read arbitrary files on the Jenkins controller file system. |
| CVE-2022-23620 | Medium | 2022-02-09 | Protected by Waratek | No public exploit | XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions AbstractSxExportURLFactoryActionHandler#processSx does not escape anything from SSX document references when serializing it on filesystem, it is possible to for the HTML export process to contain reference elements containing filesystem syntax like "../", "./". or "/" in general. The referenced elements are not properly escaped. This issue has been resolved in version 13.6-rc-1. This issue can be worked around by limiting or disabling document export. |
| CVE-2022-22931 | Medium | 2022-02-07 | Protected by Waratek | No public exploit | Fix of CVE-2021-40525 do not prepend delimiters upon valid directory validations. Affected implementations include: - maildir mailbox store - Sieve file repository This enables a user to access other users data stores (limited to user names being prefixed by the value of the username being used). |
| CVE-2022-22932 | Medium | 2022-01-26 | Protected by Waratek | No public exploit | Apache Karaf obr:* commands and run goal on the karaf-maven-plugin have partial path traversal which allows to break out of expected folder. The risk is low as obr:* commands are not very used and the entry is set by user. This has been fixed in revision: https://gitbox.apache.org/repos/asf?p=karaf.git;h=36a2bc4 https://gitbox.apache.org/repos/asf?p=karaf.git;h=52b70cf Mitigation: Apache Karaf users should upgrade to 4.2.15 or 4.3.6 or later as soon as possible, or use correct path. JIRA Tickets: https://issues.apache.org/jira/browse/KARAF-7326 |
| CVE-2022-23113 | Medium | 2022-01-12 | Protected by Waratek | No public exploit | Jenkins Publish Over SSH Plugin 1.22 and earlier performs a validation of the file name specifying whether it is present or not, resulting in a path traversal vulnerability allowing attackers with Item/Configure permission to discover the name of the Jenkins controller files. |
| CVE-2021-21683 | Medium | 2021-10-06 | Protected by Waratek | No public exploit | The file browser in Jenkins 2.314 and earlier, LTS 2.303.1 and earlier may interpret some paths to files as absolute on Windows, resulting in a path traversal vulnerability allowing attackers with Overall/Read permission (Windows controller) or Job/Workspace permission (Windows agents) to obtain the contents of arbitrary files. |
| CVE-2020-6950 | Medium | 2021-06-02 | Protected by Waratek | Working exploit published | Directory traversal in Eclipse Mojarra before 2.3.14 allows attackers to read arbitrary files via the loc parameter or con parameter. |
| CVE-2021-32643 | Medium | 2021-05-27 | Protected by Waratek | No public exploit | Http4s is a Scala interface for HTTP services. `StaticFile.fromUrl` can leak the presence of a directory on a server when the `URL` scheme is not `file://`, and the URL points to a fetchable resource under its scheme and authority. The function returns `F[None]`, indicating no resource, if `url.getFile` is a directory, without first checking the scheme or authority of the URL. If a URL connection to the scheme and URL would return a stream, and the path in the URL exists as a directory on the server, the presence of the directory on the server could be inferred from the 404 response. The contents and other metadata about the directory are not exposed. This affects http4s versions: 0.21.7 through 0.21.23, 0.22.0-M1 through 0.22.0-M8, 0.23.0-M1, and 1.0.0-M1 through 1.0.0-M22. The [patch](https://github.com/http4s/http4s/commit/52e1890665410b4385e37b96bc49c5e3c708e4e9) is available in the following versions: v0.21.24, v0.22.0-M9, v0.23.0-M2, v1.0.0-M23. As a workaround users can avoid calling `StaticFile.fromUrl` with non-file URLs. |
| CVE-2021-29425 | Medium | 2021-04-13 | Protected by Waratek | No public exploit | In Apache Commons IO before 2.7, When invoking the method FileNameUtils.normalize with an improper input string, like "//../foo", or "\\..\foo", the result would be the same value, thus possibly providing access to files in the parent directory, but not further above (thus "limited" path traversal), if the calling code would use the result to construct a path value. |
| CVE-2020-5016 | Medium | 2021-03-10 | Protected by Waratek | No public exploit | IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 could allow a remote attacker to traverse directories on the system. When application security is disabled and JAX-RPC applications are present, an attacker could send a specially-crafted URL request containing "dot dot" sequences (/../) to view arbitrary xml files on the system. This does not occur if Application security is enabled. IBM X-Force ID: 193556. |
| CVE-2021-22114 | Medium | 2021-03-01 | Protected by Waratek | No public exploit | Addresses partial fix in CVE-2018-1263. Spring-integration-zip, versions prior to 1.0.4, exposes an arbitrary file write vulnerability, that can be achieved using a specially crafted zip archive (affects other archives as well, bzip2, tar, xz, war, cpio, 7z), that holds path traversal filenames. So when the filename gets concatenated to the target extraction directory, the final path ends up outside of the target folder. |
| CVE-2020-35460 | Medium | 2020-12-14 | Protected by Waratek | No public exploit | common/InputStreamHelper.java in Packwood MPXJ before 8.3.5 allows directory traversal in the zip stream handler flow, leading to the writing of files to arbitrary locations. |