Overview 159 matches · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
159matches
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
159
100.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
blocked by ARMR today
159
100.0%
partly blocked
0
0.0%
not blocked
0
0.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
0
0.0%
Forecast only
0
0.0%
No public exploit
159
100.0%
split by
peak 35 / year
20021
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
20031
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
20040
20051
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
20062
Protected by Waratek2
Medium2
blocked by ARMR today2
No public exploit2
20071
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
20080
20092
Protected by Waratek2
Medium2
blocked by ARMR today2
No public exploit2
20102
Protected by Waratek2
Medium2
blocked by ARMR today2
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
20132
Protected by Waratek2
Medium2
blocked by ARMR today2
No public exploit2
20143
Protected by Waratek3
Medium3
blocked by ARMR today3
No public exploit3
20152
Protected by Waratek2
Medium2
blocked by ARMR today2
No public exploit2
201613
Protected by Waratek13
Medium13
blocked by ARMR today13
No public exploit13
20171
Protected by Waratek1
Medium1
blocked by ARMR today1
No public exploit1
201818
Protected by Waratek18
Medium18
blocked by ARMR today18
No public exploit18
201911
Protected by Waratek11
Medium11
blocked by ARMR today11
No public exploit11
202010
Protected by Waratek10
Medium10
blocked by ARMR today10
No public exploit10
20215
Protected by Waratek5
Medium5
blocked by ARMR today5
No public exploit5
202226
Protected by Waratek26
Medium26
blocked by ARMR today26
No public exploit26
20237
Protected by Waratek7
Medium7
blocked by ARMR today7
No public exploit7
20247
Protected by Waratek7
Medium7
blocked by ARMR today7
No public exploit7
20257
Protected by Waratek7
Medium7
blocked by ARMR today7
No public exploit7
202635
Protected by Waratek35
Medium35
blocked by ARMR today35
No public exploit35
2002200420062008201020122014201620182020202220242026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| 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-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-63621 | Medium | 2026-08-24 | Protected by Waratek | No public exploit | Improper Input Validation, Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') vulnerability in Apache Camel Knative component The Knative consumer in camel-knative maps inbound CloudEvent attributes onto Camel message headers. In binary content mode the HTTP-header path filters Camel-internal headers through KnativeHttpHeaderFilterStrategy, but in structured content mode (Content-Type application/cloudevents+json) the CloudEvent extension fields are read directly from the JSON body and every extension key is copied into the Exchange headers without applying any HeaderFilterStrategy (CloudEventProcessors, spec versions 1.0, 1.0.1 and 1.0.2). As a result, an unauthenticated attacker can inject Camel-internal headers (e.g. CamelHttpUri, CamelHttpPath, CamelFileName) via a structured-mode CloudEvent request, matched case-insensitively against Camel's header map. When a route forwards messages from a Knative consumer to a header-driven component such as camel-http or camel-file, the injected headers override configured values, enabling server-side request forgery (SSRF), path traversal or message-dispatch redirection depending on the route. This is an incomplete fix of the inbound header filtering previously added for the binary content-mode path, and is the same pattern addressed in camel-cxf/camel-knative (CVE-2026-47323), camel-undertow (CVE-2025-30177), the broader incoming-header filter (CVE-2025-27636 and CVE-2025-29891), and the non-HTTP strategies (CVE-2026-40453). This issue affects Apache Camel: from 3.15.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.21.0. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.18.x LTS releases stream, then they are suggested to upgrade to 4.18.4. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. The non-LTS releases 4.15.0 through 4.17.0 and 4.19.0 through 4.21.0 are affected but do not receive a maintenance fix; users on those versions should upgrade to 4.18.4 or 4.22.0. |
| CVE-2026-60093 | Medium | 2026-08-24 | Protected by Waratek | No public exploit | Relative path traversal vulnerability in Apache Camel Azure-Storage Datalake component This issue affects Apache Camel: from 4.0.0 before 4.14.9, from 4.15.0 before 4.18.4, from 4.19.0 before 4.22.0. The camel-azure-storage-datalake component can download an Azure Data Lake Storage Gen2 file to the local filesystem through its downloadToFile operation, writing into the directory named by the fileDir endpoint option. DataLakeFileOperations.downloadToFile built the local target by joining fileDir with the remote path name exactly as the Azure SDK reported it (new File(fileDir, fileClientWrapper.getFileName())) and passed the result straight to the SDK download call, with no lexical normalization and no check that the resolved location stayed inside fileDir. The remote name is not route-controlled data: the consumer enumerates the filesystem in DataLakeConsumer.createBatchExchangesFromPath, which lists paths and creates one exchange per entry from PathItem.getName() verbatim, applying no name filtering by default. A path name containing parent-directory segments therefore resolved to a location outside the configured fileDir, letting anyone able to influence the names present in the consumed Data Lake filesystem cause Camel to create or overwrite a file at a location of their choosing, with the privileges of the Camel process. Depending on what the process can write to, overwriting a file outside the download directory can escalate beyond the loss of integrity of that file. The fileDir option is an ordinary common-group configuration parameter and carries no security marker, so nothing signalled to users that its value was not being enforced as a containment boundary. Camel's other file-download consumers - camel-file, camel-ftp, camel-smb, camel-mina-sftp and camel-azure-files - already constrained their local downloads to the configured directory using a path-segment boundary check; the camel-azure-storage-datalake download path was not covered by that work. Users are recommended to upgrade to version 4.22.0, which fixes the issue. If users are on the 4.14.x LTS releases stream, then they are suggested to upgrade to 4.14.9. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.4. For deployments that cannot upgrade immediately, constrain the names the consumer will act on using the regex endpoint option, which is applied to each listed path name as a full-string match, so that only simple single-segment names are accepted and any name carrying a path separator or a parent-directory segment is filtered out before an exchange is created. Alternatively, avoid the downloadToFile operation on untrusted filesystems and write the payload from the route under a file name the route itself controls, rather than one taken from the remote listing. As defence in depth, treat the object names in any externally writable Data Lake filesystem as untrusted input and do not derive local filesystem paths from them. |
| 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-53698 | Medium | 2026-06-10 | Protected by Waratek | No public exploit | Silverpeas through 6.4.6 mishandles the "Personal space" feature that is selected when no componentId is set. |
| 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-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-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-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-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-1584 | Medium | 2025-02-23 | Protected by Waratek | No public exploit | A vulnerability classified as problematic was found in opensolon Solon up to 3.0.8. This vulnerability affects unknown code of the file solon-projects/solon-web/solon-web-staticfiles/src/main/java/org/noear/solon/web/staticfiles/StaticMappings.java. The manipulation leads to path traversal: '../filedir'. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. Upgrading to version 3.0.9 is able to address this issue. The name of the patch is f46e47fd1f8455b9467d7ead3cdb0509115b2ef1. It is recommended to upgrade the affected component. |
| 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-52012 | Medium | 2025-01-27 | Protected by Waratek | No public exploit | Relative Path Traversal vulnerability in Apache Solr. Solr instances running on Windows are vulnerable to arbitrary filepath write-access, due to a lack of input-sanitation in the "configset upload" API. Commonly known as a "zipslip", maliciously constructed ZIP files can use relative filepaths to write data to unanticipated parts of the filesystem. This issue affects Apache Solr: from 6.6 through 9.7.0. Users are recommended to upgrade to version 9.8.0, which fixes the issue. Users unable to upgrade may also safely prevent the issue by using Solr's "Rule-Based Authentication Plugin" to restrict access to the configset upload API, so that it can only be accessed by a trusted set of administrators/users. |
| 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-1459 | Medium | 2024-02-12 | Protected by Waratek | No public exploit | A path traversal vulnerability was found in Undertow. This issue may allow a remote attacker to append a specially-crafted sequence to an HTTP request for an application deployed to JBoss EAP, which may permit access to privileged or restricted files and directories. |
| 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-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-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-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-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. |
| CVE-2020-4782 | Medium | 2020-10-28 | 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. An attacker could send a specially-crafted URL request containing "dot dot" sequences (/../) to view arbitrary files on the system. |
| CVE-2020-2293 | Medium | 2020-10-08 | Protected by Waratek | No public exploit | Jenkins Persona Plugin 2.4 and earlier allows users with Overall/Read permission to read arbitrary files on the Jenkins controller. |
| CVE-2020-2278 | Medium | 2020-09-16 | Protected by Waratek | No public exploit | Jenkins Storable Configs Plugin 1.0 and earlier does not restrict the user-specified file name, allowing attackers with Job/Configure permission to replace any other '.xml' file on the Jenkins controller with a job config.xml file's content. |
| CVE-2020-2277 | Medium | 2020-09-16 | Protected by Waratek | No public exploit | Jenkins Storable Configs Plugin 1.0 and earlier allows users with Job/Read permission to read arbitrary files on the Jenkins controller. |
| CVE-2020-2275 | Medium | 2020-09-16 | Protected by Waratek | No public exploit | Jenkins Copy data to workspace Plugin 1.0 and earlier does not limit which directories can be copied from the Jenkins controller to job workspaces, allowing attackers with Job/Configure permission to read arbitrary files on the Jenkins controller. |
| CVE-2020-2254 | Medium | 2020-09-16 | Protected by Waratek | No public exploit | Jenkins Blue Ocean Plugin 1.23.2 and earlier provides an undocumented feature flag that, when enabled, allows an attacker with Job/Configure or Job/Create permission to read arbitrary files on the Jenkins controller file system. |
| CVE-2019-17572 | Medium | 2020-05-14 | Protected by Waratek | No public exploit | In Apache RocketMQ 4.2.0 to 4.6.0, when the automatic topic creation in the broker is turned on by default, an evil topic like “../../../../topic2020” is sent from rocketmq-client to the broker, a topic folder will be created in the parent directory in brokers, which leads to a directory traversal vulnerability. Users of the affected versions should apply one of the following: Upgrade to Apache RocketMQ 4.6.1 or later. |
| CVE-2020-7647 | Medium | 2020-05-11 | Protected by Waratek | No public exploit | All versions before 1.6.7 and all versions after 2.0.0 inclusive and before 2.8.2 of io.jooby:jooby and org.jooby:jooby are vulnerable to Directory Traversal via two separate vectors. |
| CVE-2020-2139 | Medium | 2020-03-09 | Protected by Waratek | No public exploit | An arbitrary file write vulnerability in Jenkins Cobertura Plugin 1.15 and earlier allows attackers able to control the coverage report file contents to overwrite any file on the Jenkins master file system. |
| CVE-2019-16540 | Medium | 2019-11-21 | Protected by Waratek | No public exploit | A path traversal vulnerability in Jenkins Support Core Plugin 2.63 and earlier allows attackers with Overall/Read permission to delete arbitrary files on the Jenkins master. |
| CVE-2019-10436 | Medium | 2019-10-16 | Protected by Waratek | No public exploit | An arbitrary file read vulnerability in Jenkins Google OAuth Credentials Plugin 0.9 and earlier allowed attackers able to configure jobs and credentials in Jenkins to obtain the contents of any file on the Jenkins master. |
| CVE-2019-4442 | Medium | 2019-09-17 | 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 file system. An attacker could send a specially-crafted URL request to view arbitrary files on the system but not content. IBM X-Force ID: 163226. |