584 results (0.053 seconds)

CVSS: 8.3EPSS: 0%CPEs: 1EXPL: 0

Inappropriate implementation in Views in Google Chrome on Windows prior to 131.0.6778.69 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. • https://chromereleases.googleblog.com/2024/11/stable-channel-update-for-desktop_12.html https://issues.chromium.org/issues/370856871 •

CVSS: 2.3EPSS: 0%CPEs: 1EXPL: 0

The cap-std project is organized around the eponymous `cap-std` crate, and develops libraries to make it easy to write capability-based code. cap-std's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted filesystem paths could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them provide access peripheral devices connected to the computer, or network resources mapped to those devices. ... La implementación del sandbox del sistema de archivos de cap-std en Windows bloquea el acceso a nombres de archivos de dispositivos especiales como "COM1", "COM2", "LPT0", "LPT1", etc., sin embargo, no bloquea el acceso a los nombres de archivos de dispositivos especiales que utilizan dígitos en superíndice, como "COM¹", "COM²", "LPT?"... Las rutas del sistema de archivos no confiables podrían eludir el sandbox y acceder a los dispositivos a través de esos nombres de archivos de dispositivos especiales con dígitos en superíndice, y a través de ellos proporcionar acceso a dispositivos periféricos conectados a la computadora o recursos de red asignados a esos dispositivos. • https://en.wikipedia.org/wiki/ISO/IEC_8859-1 https://github.com/bytecodealliance/cap-std/commit/dcc3818039761331fbeacbb3a40c542b65b5ebf7 https://github.com/bytecodealliance/cap-std/pull/371 https://github.com/bytecodealliance/cap-std/security/advisories/GHSA-hxf5-99xg-86hw https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •

CVSS: 2.3EPSS: 0%CPEs: 3EXPL: 0

Wasmtime's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. • https://en.wikipedia.org/wiki/ISO/IEC_8859-1 https://github.com/bytecodealliance/cap-std/pull/371 https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-c2f5-jxjv-2hh8 https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file#naming-conventions • CWE-67: Improper Handling of Windows Device Names CWE-184: Incomplete List of Disallowed Inputs •

CVSS: 1.0EPSS: 0%CPEs: 7EXPL: 0

On macOS, built-in builders (such as `builtin:fetchurl`, exposed to users with `import <nix/fetchurl.nix>`) were not executed in the macOS sandbox. Thus, these builders (which are running under the `nixbld*` users) had read access to world-readable paths and write access to world-writable paths outside of the sandbox. ... The Nix sandbox is not primarily intended as a security mechanism, but as an aid to improve reproducibility and purity of Nix builds. • https://github.com/NixOS/nix/commit/597fcc98e18e3178734d06a9e7306250e8cb8d74 https://github.com/NixOS/nix/security/advisories/GHSA-wf4c-57rh-9pjg • CWE-693: Protection Mechanism Failure •

CVSS: 9.8EPSS: 0%CPEs: -EXPL: 0

ServiceNow has addressed an input validation vulnerability that was identified in the Now Platform. This vulnerability could enable an unauthenticated user to remotely execute code within the context of the Now Platform. ServiceNow deployed an update to hosted instances and ServiceNow provided the update to our partners and self-hosted customers. Further, the vulnerability is addressed in the listed patches and hot fixes. • https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1706070 • CWE-94: Improper Control of Generation of Code ('Code Injection') •