Total
55 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-54956 | 2025-08-03 | N/A | N/A | ||
| The gh package before 1.5.0 for R delivers an HTTP response in a data structure that includes the Authorization header from the corresponding HTTP request. | |||||
| CVE-2025-54352 | 2025-07-21 | N/A | N/A | ||
| WordPress 3.5 through 6.8.2 allows remote attackers to guess titles of private and draft posts via pingback.ping XML-RPC requests. NOTE: the Supplier is not changing this behavior. | |||||
| CVE-2025-54310 | 2025-07-18 | N/A | N/A | ||
| qBittorrent before 5.1.2 does not prevent access to a local file that is referenced in a link URL. This affects rsswidget.cpp and searchjobwidget.cpp. | |||||
| CVE-2025-41645 | 2025-05-13 | N/A | 8.6 HIGH | ||
| An unauthenticated remote attacker could use a demo account of the portal to hijack devices that were created in that account by mistake. | |||||
| CVE-2025-46553 | 2025-05-05 | N/A | N/A | ||
| @misskey-dev/summaly is a tool for getting a summary of a web page. Starting in version 3.0.1 and prior to version 5.2.1, a logic error in the main `summaly` function causes the `allowRedirects` option to never be passed to any plugins, and as a result, isn't enforced. Misskey will follow redirects, despite explicitly requesting not to. Version 5.2.1 contains a patch for the issue. | |||||
| CVE-2024-29018 | 1 Mobyproject | 1 Moby | 2025-04-09 | N/A | 7.5 HIGH |
| Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby's networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well. When containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs. Containers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly. In addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver. When a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container's network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself. As a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved. Many systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected. Because `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers. Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address. Moby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container's network namespace. | |||||
| CVE-2021-22900 | 2 Ivanti, Pulsesecure | 2 Connect Secure, Pulse Connect Secure | 2025-03-21 | 6.5 MEDIUM | 7.2 HIGH |
| A vulnerability allowed multiple unrestricted uploads in Pulse Connect Secure before 9.1R11.4 that could lead to an authenticated administrator to perform a file write via a maliciously crafted archive upload in the administrator web interface. | |||||
| CVE-2025-26698 | 2025-02-26 | N/A | N/A | ||
| Incorrect resource transfer between spheres issue exists in RevoWorks SCVX and RevoWorks Browser. If exploited, malicious files may be downloaded to the system where using the product. | |||||
| CVE-2023-22950 | 1 Tigergraph | 1 Tigergraph | 2025-02-07 | N/A | 6.5 MEDIUM |
| An issue was discovered in TigerGraph Enterprise Free Edition 3.x. Data loading jobs in gsql_server, created by any user with designer permissions, can read sensitive data from arbitrary locations. | |||||
| CVE-2023-31115 | 1 Samsung | 4 Exynos 5123, Exynos 5123 Firmware, Exynos 5300 and 1 more | 2025-01-07 | N/A | 7.5 HIGH |
| An issue was discovered in the Shannon RCS component in Samsung Exynos Modem 5123 and 5300. Incorrect resource transfer between spheres can cause changes to the activation mode of RCS via a crafted application. | |||||
| CVE-2023-31114 | 1 Samsung | 4 Exynos 5123, Exynos 5123 Firmware, Exynos 5300 and 1 more | 2025-01-07 | N/A | 9.1 CRITICAL |
| An issue was discovered in the Shannon RCS component in Samsung Exynos Modem 5123 and 5300. Incorrect resource transfer between spheres can cause unintended querying of the SIM status via a crafted application. | |||||
| CVE-2024-42158 | 1 Linux | 1 Linux Kernel | 2024-08-02 | N/A | 4.1 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: s390/pkey: Use kfree_sensitive() to fix Coccinelle warnings Replace memzero_explicit() and kfree() with kfree_sensitive() to fix warnings reported by Coccinelle: WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1506) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1643) WARNING opportunity for kfree_sensitive/kvfree_sensitive (line 1770) | |||||
| CVE-2020-15892 | 1 Dlink | 2 Dap-1520, Dap-1520 Firmware | 2023-11-08 | 7.5 HIGH | 9.8 CRITICAL |
| An issue was discovered in apply.cgi on D-Link DAP-1520 devices before 1.10b04Beta02. Whenever a user performs a login action from the web interface, the request values are being forwarded to the ssi binary. On the login page, the web interface restricts the password input field to a fixed length of 15 characters. The problem is that validation is being done on the client side, hence it can be bypassed. When an attacker manages to intercept the login request (POST based) and tampers with the vulnerable parameter (log_pass), to a larger length, the request will be forwarded to the webserver. This results in a stack-based buffer overflow. A few other POST variables, (transferred as part of the login request) are also vulnerable: html_response_page and log_user. | |||||
| CVE-2022-46173 | 1 Elrond | 1 Elrond Go | 2023-11-07 | N/A | 6.5 MEDIUM |
| Elrond-GO is a go implementation for the Elrond Network protocol. Versions prior to 1.3.50 are subject to a processing issue where nodes are affected when trying to process a cross-shard relayed transaction with a smart contract deploy transaction data. The problem was a bad correlation between the transaction caches and the processing component. If the above-mentioned transaction was sent with more gas than required, the smart contract result (SCR transaction) that should have returned the leftover gas, would have been wrongly added to a cache that the processing unit did not consider. The node stopped notarizing metachain blocks. The fix was actually to extend the SCR transaction search in all other caches if it wasn't found in the correct (expected) sharded-cache. There are no known workarounds at this time. This issue has been patched in version 1.3.50. | |||||
| CVE-2022-20658 | 1 Cisco | 2 Unified Contact Center Express, Unified Contact Center Management Portal | 2023-11-07 | 8.5 HIGH | 9.6 CRITICAL |
| A vulnerability in the web-based management interface of Cisco Unified Contact Center Management Portal (Unified CCMP) and Cisco Unified Contact Center Domain Manager (Unified CCDM) could allow an authenticated, remote attacker to elevate their privileges to Administrator. This vulnerability is due to the lack of server-side validation of user permissions. An attacker could exploit this vulnerability by submitting a crafted HTTP request to a vulnerable system. A successful exploit could allow the attacker to create Administrator accounts. With these accounts, the attacker could access and modify telephony and user resources across all the Unified platforms that are associated to the vulnerable Cisco Unified CCMP. To successfully exploit this vulnerability, an attacker would need valid Advanced User credentials. | |||||
| CVE-2020-5188 | 1 Dnnsoftware | 1 Dotnetnuke | 2023-11-07 | 4.0 MEDIUM | 6.5 MEDIUM |
| DNN (formerly DotNetNuke) through 9.4.4 has Insecure Permissions. | |||||
| CVE-2020-15257 | 3 Debian, Fedoraproject, Linuxfoundation | 3 Debian Linux, Fedora, Containerd | 2023-11-07 | 3.6 LOW | 5.2 MEDIUM |
| containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. Access controls for the shim’s API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges. This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon as they are released. It should be noted that containers started with an old version of containerd-shim should be stopped and restarted, as running containers will continue to be vulnerable even after an upgrade. If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the "host" network namespace, for example with docker run --net=host or hostNetwork: true in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to deny unix addr=@**, to your policy. It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container. | |||||
| CVE-2023-44100 | 1 Huawei | 2 Emui, Harmonyos | 2023-10-16 | N/A | 7.5 HIGH |
| Broadcast permission control vulnerability in the Bluetooth module.Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2023-44104 | 1 Huawei | 2 Emui, Harmonyos | 2023-10-16 | N/A | 7.5 HIGH |
| Broadcast permission control vulnerability in the Bluetooth module.Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2019-13263 | 1 Dlink | 2 Dir-825\/ac G1, Dir-825\/ac G1 Firmware | 2023-04-27 | 5.8 MEDIUM | 8.8 HIGH |
| D-link DIR-825AC G1 devices have Insufficient Compartmentalization between a host network and a guest network that are established by the same device. A DHCP Request is sent to the router with a certain Transaction ID field. Following the DHCP protocol, the router responds with an ACK or NAK message. Studying the NAK case revealed that the router erroneously sends the NAK to both Host and Guest networks with the same Transaction ID as found in the DHCP Request. This allows encoding of data to be sent cross-router into the 32-bit Transaction ID field. | |||||