WaratekVRT Sign in

Critical CWE-434 CVEs

13 CVEs, 2 exploited, 9 protected by Waratek

Reset
More filters (1)
Columns
CWE CWE-434✕
Overview 13 matches · 9 protected · 2 exploited · 1 CISA KEV · 3 public PoC · 3 EPSS ≥ 0.5
13matches 9protected69.2% 2exploited15.4% 1CISA KEV7.7% 3public PoC23.1% 3EPSS ≥ 0.523.1%
Protected by Waratek 9 69.2% Rule in development 0 0.0% Mitigation candidate 1 7.7% No exploit published 3 23.1%
Critical 13 100.0% High 0 0.0% Medium 0 0.0% Low 0 0.0% None 0 0.0% Unknown 0 0.0%
blocked by ARMR today 9 69.2% partly blocked 0 0.0% not blocked 4 30.8% not established 0 0.0% unrecorded 0 0.0%
Exploited 2 15.4% Working exploit published 0 0.0% Proof of concept only 1 7.7% Forecast only 1 7.7% No public exploit 9 69.2%
split by peak 3 / year
No exploit published: 3Mitigation candidate: 1Protected by Waratek: 9 Critical: 13 not blocked: 4blocked by ARMR today: 9 No public exploit: 9Forecast only: 1Proof of concept only: 1Exploited: 2
20161 Protected by Waratek1 Critical1 blocked by ARMR today1 Exploited1 20170 20180 20191 Mitigation candidate1 Critical1 not blocked1 Proof of concept only1 20200 20213 Protected by Waratek3 Critical3 blocked by ARMR today3 Forecast only1 No public exploit2 20221 Protected by Waratek1 Critical1 blocked by ARMR today1 No public exploit1 20233 Protected by Waratek2 No exploit published1 Critical3 blocked by ARMR today2 not blocked1 No public exploit3 20241 Protected by Waratek1 Critical1 blocked by ARMR today1 Exploited1 20250 20263 Protected by Waratek1 No exploit published2 Critical3 blocked by ARMR today1 not blocked2 No public exploit3
20162017201820192020202120222023202420252026
13 matches Sign in to download these CVEs as CSV or JSON, or to follow them in a feed.
CVE Severity Published▾ Status Exploitation Description
CVE-2026-3418 Critical 2026-08-06 No exploit published No public exploit The System REST API accepts user-supplied file uploads without enforcing sufficient validation on the file type or destination, allowing files to be written to arbitrary server-accessible locations. Exploitation requires authenticated administrative access with publisher privileges. Successful exploitation permits an authenticated publisher to upload files to server-accessible locations. Depending on the deployment environment and how uploaded files are handled, this could lead to the execution of uploaded content, potentially resulting in remote code execution.
CVE-2026-24014 Critical 2026-07-06 Protected by Waratek No public exploit Apache IoTDB DataNode’s internal RPC interface for creating Trigger instances uses the uploaded Trigger JAR name to build a file path without sufficient validation. If the internal DataNode RPC port is exposed to an untrusted network, an attacker may use path traversal sequences in the JAR name to write files outside the intended Trigger installation directory. This could allow arbitrary file write with the permissions of the IoTDB process. This issue affects Apache IoTDB: from 1.3.3 before 2.0.8. Users are recommended to upgrade to version 2.0.8, which fixes the issue.
CVE-2025-13590 Critical 2026-02-19 No exploit published No public exploit A malicious actor with administrative privileges can upload an arbitrary file to a user-controlled location within the deployment via a system REST API. Successful uploads may lead to remote code execution. By leveraging the vulnerability, a malicious actor may perform Remote Code Execution by uploading a specially crafted payload.
CVE-2024-53677 Critical 2024-12-11 Protected by Waratek Exploited File upload logic in Apache Struts is flawed. An attacker can manipulate file upload params to enable paths traversal and under some circumstances this can lead to uploading a malicious file which can be used to perform Remote Code Execution. This issue affects Apache Struts: from 2.0.0 before 6.4.0. Users are recommended to upgrade to version 6.4.0 at least and migrate to the new file upload mechanism https://struts.apache.org/core-developers/file-upload . If you are not using an old file upload logic based on FileuploadInterceptor your application is safe. You can find more details in  https://cwiki.apache.org/confluence/display/WW/S2-067
CVE-2022-45802 Critical 2023-05-01 Protected by Waratek No public exploit Streampark allows any users to upload a jar as application, but there is no mandatory verification of the uploaded file type, causing users to upload some high-risk files, and may upload them to any directory, Users of the affected versions should upgrade to Apache StreamPark 2.0.0 or later
CVE-2023-27603 Critical 2023-04-10 Protected by Waratek No public exploit In Apache Linkis <=1.3.1, due to the Manager module engineConn material upload does not check the zip path, This is a Zip Slip issue, which will lead to a potential RCE vulnerability. We recommend users upgrade the version of Linkis to version 1.3.2.
CVE-2023-27602 Critical 2023-04-10 No exploit published No public exploit In Apache Linkis <=1.3.1, The PublicService module uploads files without restrictions on the path to the uploaded files, and file types. We recommend users upgrade the version of Linkis to version 1.3.2.  For versions <=1.3.1, we suggest turning on the file path check switch in linkis.properties `wds.linkis.workspace.filesystem.owner.check=true` `wds.linkis.workspace.filesystem.path.check=true`
CVE-2022-34115 Critical 2022-07-22 Protected by Waratek No public exploit DataEase v1.11.1 was discovered to contain a arbitrary file write vulnerability via the parameter dataSourceId.
CVE-2021-21350 Critical 2021-03-23 Protected by Waratek No public exploit XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker to execute arbitrary code only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16.
CVE-2021-21347 Critical 2021-03-23 Protected by Waratek No public exploit XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16.
CVE-2021-21344 Critical 2021-03-23 Protected by Waratek Forecast only XStream is a Java library to serialize objects to XML and back again. In XStream before version 1.4.16, there is a vulnerability which may allow a remote attacker to load and execute arbitrary code from a remote host only by manipulating the processed input stream. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types. If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16.
CVE-2019-12409 Critical 2019-11-18 Mitigation candidate Proof of concept only The 8.1.1 and 8.2.0 releases of Apache Solr contain an insecure setting for the ENABLE_REMOTE_JMX_OPTS configuration option in the default solr.in.sh configuration file shipping with Solr. If you use the default solr.in.sh file from the affected releases, then JMX monitoring will be enabled and exposed on RMI_PORT (default=18983), without any authentication. If this port is opened for inbound traffic in your firewall, then anyone with network access to your Solr nodes will be able to access JMX, which may in turn allow them to upload malicious code for execution on the Solr server.
CVE-2016-3088 Critical 2016-06-01 Protected by Waratek Exploited The Fileserver web application in Apache ActiveMQ 5.x before 5.14.0 allows remote attackers to upload and execute arbitrary files via an HTTP PUT followed by an HTTP MOVE request.