| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper Verification of Source of a Communication Channel in Work Desktop for Mac versions 10.8.1.46 and earlier
allows attackers to execute arbitrary commands via unauthorized access to the Agent service.
This has been remediated in Work Desktop for Mac version 10.8.2.33. |
| A code execution vulnerability exists in the Xiaomi shop applicationproduct. The vulnerability is caused by improper input validation and can be exploited by attackers to execute malicious code. |
| An intent redriction vulnerability exists in the Xiaomi quick App framework application product. The vulnerability is caused by improper input validation and can be exploited by attackers tointent redriction. |
| An code execution vulnerability exists in the Xiaomi smarthome application product. The vulnerability is caused by improper input validation and can be exploited by attackers to execute malicious code. |
| parseWildcardRules in Gin-Gonic CORS middleware before 1.6.0 mishandles a wildcard at the end of an origin string, e.g., https://example.community/* is allowed when the intention is that only https://example.com/* should be allowed, and http://localhost.example.com/* is allowed when the intention is that only http://localhost/* should be allowed. |
| In Sipwise rtpengine before 13.4.1.1, an origin-validation error in the endpoint-learning logic of the media-relay core allows remote attackers to inject or intercept RTP/SRTP media streams via RTP packets (except when the relay is configured for strict source and learning disabled). Version 13.4.1.1 fixes the heuristic mode by limiting exposure to the first five packets, and introduces a recrypt flag that fully prevents SRTP attacks when both mitigations are enabled. |
| An improper verification of a loaded library in Zscaler Client Connector on Mac < 4.2.0.241 may allow a local attacker to elevate their privileges. |
| The security settings in the SAP Business One Integration Framework are not adequately checked, allowing attackers to bypass the 403 Forbidden error and access restricted pages. This leads to low impact on confidentiality of the application, there is no impact on integrity and availability. |
| Hosts listed in TrustedOrigins implicitly allow requests from the corresponding HTTP origins, allowing network MitMs to perform CSRF attacks. After the CVE-2025-24358 fix, a network attacker that places a form at http://example.com can't get it to submit to https://example.com because the Origin header is checked with sameOrigin against a synthetic URL. However, if a host is added to TrustedOrigins, both its HTTP and HTTPS origins will be allowed, because the schema of the synthetic URL is ignored and only the host is checked. For example, if an application is hosted on https://example.com and adds example.net to TrustedOrigins, a network attacker can serve a form at http://example.net to perform the attack. Applications should migrate to net/http.CrossOriginProtection, introduced in Go 1.25. If that is not an option, a backport is available as a module at filippo.io/csrf, and a drop-in replacement for the github.com/gorilla/csrf API is available at filippo.io/csrf/gorilla. |
| A vulnerability in the Device Analytics action frame processing of Cisco Wireless Access Point (AP) Software could allow an unauthenticated, adjacent attacker to inject wireless 802.11 action frames with arbitrary information.
This vulnerability is due to insufficient verification checks of incoming 802.11 action frames. An attacker could exploit this vulnerability by sending 802.11 Device Analytics action frames with arbitrary parameters. A successful exploit could allow the attacker to inject Device Analytics action frames with arbitrary information, which could modify the Device Analytics data of valid wireless clients that are connected to the same wireless controller. |
| Side-channel information leakage in Navigation in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Medium) |
| Insufficient policy enforcement in History Navigation in Google Chrome prior to 147.0.7727.55 allowed a remote attacker who convinced a user to engage in specific UI gestures to inject arbitrary scripts or HTML (UXSS) via a crafted HTML page. (Chromium security severity: Low) |
| Inappropriate implementation in Navigation in Google Chrome prior to 147.0.7727.55 allowed a remote attacker who had compromised the renderer process to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low) |
| Insufficient validation of untrusted input in WebSockets in Google Chrome prior to 147.0.7727.55 allowed a remote attacker who had compromised the renderer process to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low) |
| MLFlow versions up to and including 3.4.0 are vulnerable to DNS rebinding attacks due to a lack of Origin header validation in the MLFlow REST server. This vulnerability allows malicious websites to bypass Same-Origin Policy protections and execute unauthorized calls against REST endpoints. An attacker can query, update, and delete experiments via the affected endpoints, leading to potential data exfiltration, destruction, or manipulation. The issue is resolved in version 3.5.0. |
| An issue was discovered in the ALFA Windows 10 driver 1030.36.604 for AWUS036ACH. The WEP, WPA, WPA2, and WPA3 implementations accept fragmented plaintext frames in a protected Wi-Fi network. An adversary can abuse this to inject arbitrary data frames independent of the network configuration. |
| An issue was discovered in the ALFA Windows 10 driver 6.1316.1209 for AWUS036H. The Wi-Fi implementation does not verify the Message Integrity Check (authenticity) of fragmented TKIP frames. An adversary can abuse this to inject and possibly decrypt packets in WPA or WPA2 networks that support the TKIP data-confidentiality protocol. |
| An issue was discovered in the ALFA Windows 10 driver 6.1316.1209 for AWUS036H. The WEP, WPA, WPA2, and WPA3 implementations accept plaintext frames in a protected Wi-Fi network. An adversary can abuse this to inject arbitrary data frames independent of the network configuration. |
| Cocos AI is a confidential computing system for AI. The current implementation of attested TLS (aTLS) in CoCoS is vulnerable to a relay attack affecting all versions from v0.4.0 through v0.8.2. This vulnerability is present in both the AMD SEV-SNP and Intel TDX deployment targets supported by CoCoS. In the affected design, an attacker may be able to extract the ephemeral TLS private key used during the intra-handshake attestation. Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. A client will accept the connection under false assumptions about the endpoint it is communicating with — the attestation report cannot distinguish the genuine attested service from the attacker's relay. This undermines the intended authentication guarantees of attested TLS. A successful attack may allow an attacker to impersonate an attested CoCoS service and access data or operations that the client intended to send only to the genuine attested endpoint. Exploitation requires the attacker to first extract the ephemeral TLS private key, which is possible through physical access to the server hardware, transient execution attacks, or side-channel attacks. Note that the aTLS implementation was fully redesigned in v0.7.0, but the redesign does not address this vulnerability. The relay attack weakness is architectural and affects all releases in the v0.4.0–v0.8.2 range. This vulnerability class was formally analyzed and demonstrated across multiple attested TLS implementations, including CoCoS, by researchers whose findings were disclosed to the IETF TLS Working Group. Formal verification was conducted using ProVerif. As of time of publication, there is no patch available. No complete workaround is available. The following hardening measures reduce but do not eliminate the risk: Keep TEE firmware and microcode up to date to reduce the key-extraction surface; define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers; and/or enable mutual aTLS with CA-signed certificates where deployment architecture permits. |
| Prowise Reflect version 1.0.9 contains a remote keystroke injection vulnerability that allows attackers to send keyboard events through an exposed WebSocket on port 8082. Attackers can craft malicious web pages to inject keystrokes, opening applications and typing arbitrary text by sending specific WebSocket messages. |
