Filtered by vendor Cloudflare
Subscriptions
Total
44 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2022-4457 | 1 Cloudflare | 1 Warp | 2024-08-03 | 5.5 Medium |
| Due to a misconfiguration in the manifest file of the WARP client for Android, it was possible to a perform a task hijacking attack. An attacker could create a malicious mobile application which could hijack legitimate app and steal potentially sensitive information when installed on the victim's device. | ||||
| CVE-2022-3616 | 1 Cloudflare | 1 Octorpki | 2024-08-03 | 5.4 Medium |
| Attackers can create long chains of CAs that would lead to OctoRPKI exceeding its max iterations parameter. In consequence it would cause the program to crash, preventing it from finishing the validation and leading to a denial of service. Credits to Donika Mirdita and Haya Shulman - Fraunhofer SIT, ATHENE, who discovered and reported this vulnerability. | ||||
| CVE-2022-3512 | 1 Cloudflare | 1 Warp | 2024-08-03 | 6.7 Medium |
| Using warp-cli command "add-trusted-ssid", a user was able to disconnect WARP client and bypass the "Lock WARP switch" feature resulting in Zero Trust policies not being enforced on an affected endpoint. | ||||
| CVE-2022-3337 | 1 Cloudflare | 1 Warp Mobile Client | 2024-08-03 | 6.7 Medium |
| It was possible for a user to delete a VPN profile from WARP mobile client on iOS platform despite the Lock WARP switch https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/warp-settings/#lock-warp-switch feature being enabled on Zero Trust Platform. This led to bypassing policies and restrictions enforced for enrolled devices by the Zero Trust platform. | ||||
| CVE-2022-3320 | 1 Cloudflare | 1 Warp | 2024-08-03 | 6.7 Medium |
| It was possible to bypass policies configured for Zero Trust Secure Web Gateway by using warp-cli 'set-custom-endpoint' subcommand. Using this command with an unreachable endpoint caused the WARP Client to disconnect and allowed bypassing administrative restrictions on a Zero Trust enrolled endpoint. | ||||
| CVE-2022-3322 | 1 Cloudflare | 1 Warp Mobile Client | 2024-08-03 | 6.7 Medium |
| Lock Warp switch is a feature of Zero Trust platform which, when enabled, prevents users of enrolled devices from disabling WARP client. Due to insufficient policy verification by WARP iOS client, this feature could be bypassed by using the "Disable WARP" quick action. | ||||
| CVE-2022-3321 | 1 Cloudflare | 1 Warp Mobile Client | 2024-08-03 | 6.7 Medium |
| It was possible to bypass Lock WARP switch feature https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/warp-settings/#lock-warp-switch on the WARP iOS mobile client by enabling both "Disable for cellular networks" and "Disable for Wi-Fi networks" switches at once in the application settings. Such configuration caused the WARP client to disconnect and allowed the user to bypass restrictions and policies enforced by the Zero Trust platform. | ||||
| CVE-2022-2529 | 1 Cloudflare | 1 Goflow | 2024-08-03 | 7.5 High |
| sflow decode package does not employ sufficient packet sanitisation which can lead to a denial of service attack. Attackers can craft malformed packets causing the process to consume large amounts of memory resulting in a denial of service. | ||||
| CVE-2022-2225 | 1 Cloudflare | 1 Warp | 2024-08-03 | 8.1 High |
| By using warp-cli subcommands (disable-ethernet, disable-wifi), it was possible for a user without admin privileges to bypass configured Zero Trust security policies (e.g. Secure Web Gateway policies) and features such as 'Lock WARP switch'. | ||||
| CVE-2022-2147 | 1 Cloudflare | 1 Warp | 2024-08-03 | 6.5 Medium |
| Cloudflare Warp for Windows from version 2022.2.95.0 contained an unquoted service path which enables arbitrary code execution leading to privilege escalation. The fix was released in version 2022.3.186.0. | ||||
| CVE-2022-2145 | 1 Cloudflare | 1 Warp | 2024-08-03 | 5.8 Medium |
| Cloudflare WARP client for Windows (up to v. 2022.5.309.0) allowed creation of mount points from its ProgramData folder. During installation of the WARP client, it was possible to escalate privileges and overwrite SYSTEM protected files. | ||||
| CVE-2023-7079 | 1 Cloudflare | 1 Wrangler | 2024-08-02 | 6.4 Medium |
| Sending specially crafted HTTP requests and inspector messages to Wrangler's dev server could result in any file on the user's computer being accessible over the local network. An attacker that could trick any user on the local network into opening a malicious website could also read any file. | ||||
| CVE-2023-7080 | 1 Cloudflare | 1 Wrangler | 2024-08-02 | 8.5 High |
| The V8 inspector intentionally allows arbitrary code execution within the Workers sandbox for debugging. wrangler dev would previously start an inspector server listening on all network interfaces. This would allow an attacker on the local network to connect to the inspector and run arbitrary code. Additionally, the inspector server did not validate Origin/Host headers, granting an attacker that can trick any user on the local network into opening a malicious website the ability to run code. If wrangler dev --remote was being used, an attacker could access production resources if they were bound to the worker. This issue was fixed in wrangler@3.19.0 and wrangler@2.20.2. Whilst wrangler dev's inspector server listens on local interfaces by default as of wrangler@3.16.0, an SSRF vulnerability in miniflare https://github.com/cloudflare/workers-sdk/security/advisories/GHSA-fwvg-2739-22v7 (CVE-2023-7078) allowed access from the local network until wrangler@3.18.0. wrangler@3.19.0 and wrangler@2.20.2 introduced validation for the Origin/Host headers. | ||||
| CVE-2023-6180 | 1 Cloudflare | 1 Boring | 2024-08-02 | 5.3 Medium |
| The tokio-boring library in version 4.0.0 is affected by a memory leak issue that can lead to excessive resource consumption and potential DoS by resource exhaustion. The set_ex_data function used by the library did not deallocate memory used by pre-existing data in memory each time after completing a TLS connection causing the program to consume more resources with each new connection. | ||||
| CVE-2023-6193 | 1 Cloudflare | 1 Quiche | 2024-08-02 | 5.3 Medium |
| quiche v. 0.15.0 through 0.19.0 was discovered to be vulnerable to unbounded queuing of path validation messages, which could lead to excessive resource consumption. QUIC path validation (RFC 9000 Section 8.2) requires that the recipient of a PATH_CHALLENGE frame responds by sending a PATH_RESPONSE. An unauthenticated remote attacker can exploit the vulnerability by sending PATH_CHALLENGE frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that PATH_RESPONSE frames can only be sent at the slower rate than they are received; leading to storage of path validation data in an unbounded queue. Quiche versions greater than 0.19.0 address this problem. | ||||
| CVE-2023-3036 | 1 Cloudflare | 1 Cfnts | 2024-08-02 | 8.6 High |
| An unchecked read in NTP server in github.com/cloudflare/cfnts prior to commit 783490b https://github.com/cloudflare/cfnts/commit/783490b913f05e508a492cd7b02e3c4ec2297b71 enabled a remote attacker to trigger a panic by sending an NTSAuthenticator packet with extension length longer than the packet contents. | ||||
| CVE-2023-3040 | 1 Cloudflare | 1 Lua-resty-json | 2024-08-02 | 3.7 Low |
| A debug function in the lua-resty-json package, up to commit id 3ef9492bd3a44d9e51301d6adc3cd1789c8f534a (merged in PR #14) contained an out of bounds access bug that could have allowed an attacker to launch a DoS if the function was used to parse untrusted input data. It is important to note that because this debug function was only used in tests and demos, it was not exploitable in a normal environment. | ||||
| CVE-2023-2512 | 1 Cloudflare | 1 Workerd | 2024-08-02 | 6.5 Medium |
| Prior to version v1.20230419.0, the FormData API implementation was subject to an integer overflow. If a FormData instance contained more than 2^31 elements, the forEach() method could end up reading from the wrong location in memory while iterating over elements. This would most likely lead to a segmentation fault, but could theoretically allow arbitrary undefined behavior. In order for the bug to be exploitable, the process would need to be able to allocate 160GB of RAM. Due to this, the bug was never exploitable on the Cloudflare Workers platform, but could theoretically be exploitable on deployments of workerd running on machines with a huge amount of memory. Moreover, in order to be remotely exploited, an attacker would have to upload a single form-encoded HTTP request of at least tens of gigabytes in size. The application code would then have to use request.formData() to parse the request and formData.forEach() to iterate over this data. Due to these limitations, the exploitation likelihood was considered Low. A fix that addresses this vulnerability has been released in version v1.20230419.0 and users are encouraged to update to the latest version available. | ||||
| CVE-2023-1862 | 1 Cloudflare | 1 Warp | 2024-08-02 | 7.3 High |
| Cloudflare WARP client for Windows (up to v2023.3.381.0) allowed a malicious actor to remotely access the warp-svc.exe binary due to an insufficient access control policy on an IPC Named Pipe. This would have enabled an attacker to trigger WARP connect and disconnect commands, as well as obtaining network diagnostics and application configuration from the target's device. It is important to note that in order to exploit this, a set of requirements would need to be met, such as the target's device must've been reachable on port 445, allowed authentication with NULL sessions or otherwise having knowledge of the target's credentials. | ||||
| CVE-2023-1732 | 1 Cloudflare | 1 Circl | 2024-08-02 | 5.3 Medium |
| When sampling randomness for a shared secret, the implementation of Kyber and FrodoKEM, did not check whether crypto/rand.Read() returns an error. In rare deployment cases (error thrown by the Read() function), this could lead to a predictable shared secret. The tkn20 and blindrsa components did not check whether enough randomness was returned from the user provided randomness source. Typically the user provides crypto/rand.Reader, which in the vast majority of cases will always return the right number random bytes. In the cases where it does not, or the user provides a source that does not, the blinding for blindrsa is weak and integrity of the plaintext is not ensured in tkn20. | ||||