Total
19304 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2020-4189 | 2 Ibm, Linux | 2 Security Guardium, Linux Kernel | 2026-06-17 | 4.0 MEDIUM | 4.3 MEDIUM |
| IBM Security Guardium 11.2 discloses sensitive information in the response headers that could be used in further attacks against the system. IBM X-Force ID: 174850. | |||||
| CVE-2020-4183 | 2 Ibm, Linux | 2 Security Guardium, Linux Kernel | 2026-06-17 | 4.3 MEDIUM | 6.1 MEDIUM |
| IBM Security Guardium 11.1 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 174739. | |||||
| CVE-2020-4173 | 2 Ibm, Linux | 3 Infosphere Guardium Activity Monitor, Security Guardium Insights, Linux Kernel | 2026-06-17 | 4.3 MEDIUM | 4.3 MEDIUM |
| IBM Guardium Activity Insights 10.6 and 11.0 does not set the secure attribute on authorization tokens or session cookies. Attackers may be able to get the cookie values by sending a http:// link to a user or by planting this link in a site the user goes to. The cookie will be sent to the insecure link and the attacker can then obtain the cookie value by snooping the traffic. IBM X-Force ID: 174682. | |||||
| CVE-2020-4170 | 2 Ibm, Linux | 2 Security Guardium Insights, Linux Kernel | 2026-06-17 | 4.3 MEDIUM | 4.3 MEDIUM |
| IBM Security Guardium Insights 2.0.1 is vulnerable to cross-site request forgery which could allow an attacker to execute malicious and unauthorized actions transmitted from a user that the website trusts. IBM X-Force ID: 174406. | |||||
| CVE-2020-4165 | 2 Ibm, Linux | 2 Security Guardium Insights, Linux Kernel | 2026-06-17 | 3.5 LOW | 5.4 MEDIUM |
| IBM Security Guardium Insights 2.0.1 could allow a remote attacker to hijack the clicking action of the victim. By persuading a victim to visit a malicious Web site, a remote attacker could exploit this vulnerability to hijack the victim's click actions and possibly launch further attacks against the victim. IBM X-Force ID: 174401. | |||||
| CVE-2020-4161 | 3 Ibm, Linux, Microsoft | 4 Aix, Db2, Linux Kernel and 1 more | 2026-06-17 | 4.0 MEDIUM | 6.5 MEDIUM |
| IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 11.5 could allow an authenticated attacker to cause a denial of service due to incorrect handling of certain commands. IBM X-Force ID: 174341. | |||||
| CVE-2020-4135 | 4 Ibm, Linux, Microsoft and 1 more | 5 Aix, Db2, Linux Kernel and 2 more | 2026-06-17 | 5.0 MEDIUM | 7.5 HIGH |
| IBM DB2 for Linux, UNIX and Windows (includes DB2 Connect Server) 9.7, 10.1, 10.5, 11.1, and 11.5 could allow an unauthenticated user to send specially crafted packets to cause a denial of service from excessive memory usage. | |||||
| CVE-2020-4006 | 3 Linux, Microsoft, Vmware | 7 Linux Kernel, Windows, Cloud Foundation and 4 more | 2026-06-17 | 9.0 HIGH | 9.1 CRITICAL |
| VMware Workspace One Access, Access Connector, Identity Manager, and Identity Manager Connector address have a command injection vulnerability. | |||||
| CVE-2020-3956 | 2 Linux, Vmware | 3 Linux Kernel, Photon Os, Vcloud Director | 2026-06-17 | 6.5 MEDIUM | 8.8 HIGH |
| VMware Cloud Director 10.0.x before 10.0.0.2, 9.7.0.x before 9.7.0.5, 9.5.0.x before 9.5.0.6, and 9.1.0.x before 9.1.0.4 do not properly handle input leading to a code injection vulnerability. An authenticated actor may be able to send malicious traffic to VMware Cloud Director which may lead to arbitrary remote code execution. This vulnerability can be exploited through the HTML5- and Flex-based UIs, the API Explorer interface and API access. | |||||
| CVE-2020-3757 | 6 Adobe, Apple, Google and 3 more | 10 Flash Player, Macos, Chrome Os and 7 more | 2026-06-17 | 9.3 HIGH | 8.8 HIGH |
| Adobe Flash Player versions 32.0.0.321 and earlier, 32.0.0.314 and earlier, 32.0.0.321 and earlier, and 32.0.0.255 and earlier have a type confusion vulnerability. Successful exploitation could lead to arbitrary code execution. | |||||
| CVE-2020-36790 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nvmet: fix a memory leak We forgot to free new_model_number | |||||
| CVE-2020-36789 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but not always, the case), the 'WARN_ON(in_irq)' in net/core/skbuff.c#skb_release_head_state() might be triggered, under network congestion circumstances, together with the potential risk of a NULL pointer dereference. The root cause of this issue is the call to kfree_skb() instead of dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog(). This patch prevents the skb to be freed within the call to netif_rx() by incrementing its reference count with skb_get(). The skb is finally freed by one of the in-irq-context safe functions: dev_consume_skb_any() or dev_kfree_skb_any(). The "any" version is used because some drivers might call can_get_echo_skb() in a normal context. The reason for this issue to occur is that initially, in the core network stack, loopback skb were not supposed to be received in hardware IRQ context. The CAN stack is an exeption. This bug was previously reported back in 2017 in [1] but the proposed patch never got accepted. While [1] directly modifies net/core/dev.c, we try to propose here a smoother modification local to CAN network stack (the assumption behind is that only CAN devices are affected by this issue). [1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com | |||||
| CVE-2020-36786 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: media: [next] staging: media: atomisp: fix memory leak of object flash In the case where the call to lm3554_platform_data_func returns an error there is a memory leak on the error return path of object flash. Fix this by adding an error return path that will free flash and rename labels fail2 to fail3 and fail1 to fail2. | |||||
| CVE-2020-36784 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: i2c: cadence: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. | |||||
| CVE-2020-36783 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: i2c: img-scb: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions img_i2c_xfer and img_i2c_init. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. | |||||
| CVE-2020-36782 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. | |||||
| CVE-2020-36781 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix reference leak when pm_runtime_get_sync fails In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count is not expected to be incremented on return. However, pm_runtime_get_sync will increment pm reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. | |||||
| CVE-2020-36780 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: i2c: sprd: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in sprd_i2c_master_xfer() and sprd_i2c_remove(). However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. | |||||
| CVE-2020-36779 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in these stm32f7_i2c_xx serious functions. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. | |||||
| CVE-2020-36778 | 1 Linux | 1 Linux Kernel | 2026-06-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: i2c: xiic: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in xiic_xfer and xiic_i2c_remove. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. | |||||