| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Improper Verification of Cryptographic Signature and Improper Certificate Validation in the OPC UA driver of Apache PLC4X (PLC4J) allows an attacker in a network position between client and server to impersonate the OPC UA server and to read, forge or modify secure-channel traffic, including user credential ssent by the client.
The defect manifests differently depending on the version:
- In 0.9.0 through 0.11.0 a failed message-signature check is only logged and never enforced, and there is no mechanism to verify the server certificate: it is taken from the unauthenticated GetEndpoints discovery response and used to encrypt the user's password.
- In 0.12.0 through 0.13.1 the signature check is inverted (valid signatures are rejected, invalid ones accepted), and server certificates are accepted without a trust anchor by default.
- In all affected versions the default security policy is None. Starting with 0.12.0 the driver additionally continues silently at a weaker security policy than the one configured, and starting with 0.13.0 endpoint selection prefers the weakest matching endpoint.
Users checking only for one of these mechanisms may wrongly conclude they are unaffected.
This issue affects Apache PLC4X: from 0.9.0 before 1.0.0.
Users are recommended to upgrade to version 1.0.0, which fixes the issue. Version 1.0.0 verifies message signatures correctly, refuses to connect unless the server certificate can be verified against a configured trust store or pinned certificate, defaults to Basic256Sha256 with SignAndEncrypt, and fails the
connection if the negotiated security policy is weaker than the configured one. |
| A flaw was found in Moodle. The XML grade import feature lacks proper Cross-Site Request Forgery (CSRF) token validation. By tricking an authenticated user with grade management permissions into visiting a malicious webpage, an attacker can trigger unauthorized requests on the victim's behalf. This flaw allows a remote attacker to set or overwrite student grades without authorization. |
| UnoPim versions before 2.0.1 and 2.1.1 trust all connecting clients as proxies and honor the X-Forwarded-Host header without validation, allowing unauthenticated attackers to inject arbitrary origins into admin layout pages. Attackers can set X-Forwarded-Host to redirect JavaScript asset loading to their server, and when responses are cached by shared proxies, subsequent administrators execute attacker-supplied code in their authenticated sessions. |
| Incorrect authorization in MediaCapture in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to obtain cross-origin data via a crafted Chrome extension. (Chromium security severity: Medium) |
| Improper input validation in Auth in Google Chrome prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process and leveraged social engineering to obtain sensitive information via a crafted HTML page. (Chromium security severity: Medium) |
| Missing authorization in Contextual Tasks in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) |
| Incorrect authorization in BrowserTag in Google Chrome prior to 154.0.8037.57 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) |
| Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5, responses served through protocol.registerFileProtocol or protocol.registerHttpProtocol for a custom scheme registered with supportFetchAPI enabled but corsEnabled disabled could remain script-readable across origins. This residual issue completes the remediation for CVE-2026-70604. Applications are affected only when they expose such a scheme and load untrusted content in the same session. Schemes intentionally registered with corsEnabled enabled remain cross-origin readable by design. This issue is fixed in versions 41.10.6, 42.9.2, 43.4.1, and 44.0.0-beta.5. |
| Incorrect authorization in DevTools in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted Chrome extension. (Chromium security severity: Low) |
| Confused deputy in DevTools in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Missing authorization in V8 in Google Chrome prior to 154.0.8037.57 allowed a remote attacker to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Incorrect authorization in PictureInPicture in Google Chrome prior to 154.0.8037.57 allowed a remote attacker leveraging social engineering to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Two issues in the ThreadX loadable-module loader, reached when a device loads an attacker-controlled module object via `_txm_module_manager_memory_load` / `_txm_module_manager_in_place_load` — APIs that take ONLY a base pointer, no image length, so every size/offset field in `TXM_MODULE_PREAMBLE` is fully attacker-trusted: (1) a heap OOB **read** (`code_size` trusted as the source-image length in the code-copy loop), and (2) a control-flow-integrity / defense-in-depth gap (module entry/start/callback/stop pointers computed as `code_start + preamble_offset` with only a `!= 0` check, and the preamble `checksum` never verified). No controlled OOB write was found (honest — the copy destination is overflow-guarded). |
| Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From 42.3.3 until 42.10.0, 43.5.0, and 44.0.0-beta.6, Electron's sandboxed preload code cache did not verify that a cached entry matched the preload it was served for. A compromised renderer could write attacker-controlled cache data and cause Electron to reuse it for a later load, executing the renderer's code in the more privileged preload context. The issue affects applications that load untrusted content. This issue is fixed in versions 42.10.0, 43.5.0, and 44.0.0-beta.6. |
| JupyterLab is an extensible environment for interactive and reproducible computing, based on the Jupyter Notebook Architecture. From JupyterLab 4.5.0 until 4.5.11 and 4.6.4, from Notebook 7.5.0 until 7.6.3, and from JupyterLite Core 0.7.0 until 0.8.4, the system clipboard cell-paste path accepts attacker-controlled cell JSON without clearing metadata.trusted. When useSystemClipboardForCells is active and pasteCodeCellsWithoutOutput is disabled, a pasted code cell can mark HTML output as trusted, bypass output sanitization, and execute script in the authenticated JupyterLab origin without executing the cell. Markdown and raw cells are not affected because their output is sanitized. This issue is fixed in JupyterLab 4.5.11 and 4.6.4, Notebook 7.6.3, and JupyterLite Core 0.8.4. |
| Missing authorization in CORS in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Medium) |
| Missing authorization in Payments in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| Incorrect authorization in SiteIsolation in Google Chrome prior to 154.0.8037.92 allowed a remote attacker who had compromised the renderer process to bypass web origin policy via a crafted HTML page. (Chromium security severity: Low) |
| mcp-chrome-bridge through 1.0.31 contains an origin validation error in the native-server HTTP API that allows attackers to bypass CORS restrictions. Attackers can craft malicious web pages that make cross-origin requests to the local server and invoke browser automation tools including script execution, page content reading, and screenshot capture. |
| The device's update mechanism includes conditions that allow unauthorized software packages to be accepted as authentic. During the boot process, the stock done function disables signature verification in the OPKG configuration before restoring optional packages from a writable, unsigned feed. Separately, the publicly distributed SDK contains the production private key whose corresponding public key is trusted by both stable and beta firmware builds. Either issue undermines package authenticity, and together they allow an attacker to provide packages that appear valid to the system. Even if signature enforcement is restored, the exposed production key enables an attacker to generate signatures that the device will continue to trust. An attacker who can supply a malicious package may be able to execute arbitrary code with root privileges during installation. |
