PatchFirst · Vulnerabilidades recientes
Vulnerabilidades publicadas para Sistemas operativos en los últimos 30 días: 6586. Incluidas en el catálogo KEV: 4.
Vulnerabilidades: 160669
This update for podman fixes the following issues: - CVE-2026-55686: Podman: WORKDIR symlink traversal vulnerability (bsc#1268579). - CVE-2026-57231: specially crafted image can trick podman run into leaking host environment variables into the container (bsc#1269471).
This update for python-PyJWT fixes the following issues: - CVE-2026-101917: attacker traffic can amplify outbound requests to the configured JWKS endpoint (bsc#1283060). - CVE-2026-101918: unauthenticated request can raise an exception that may produce an HTTP 500 response (bsc#1283061). - CVE-2026-102267: forwarded credentials may be disclosed or verification keys may be substituted (bsc#1283064). - CVE-2026-102268: an attacker who knows the public key can forge authenticated HMAC tokens (bsc#1283065). - CVE-2026-102269: raw-token revocation checks can fail to recognize an equivalent modified token (bsc#1283066). - CVE-2026-102270: an attac
This update for amazon-ecs-init fixes the following issues: - CVE-2026-84445: google.golang.org/grpc: DoS via crash due to missing ':authority' and 'Host' headers in gRPC-Go xDS servers (bsc#1279042). - CVE-2026-89090: github.com/aws/aws-sdk-go-v2/aws/protocol/eventstream: malformed EventStream response frames containing a crafted header value type byte outside the valid range can cause the host process to terminate (bsc#1280679). Changes for amazon-ecs-init: - Update to version 1.108.0 * Enhancement - Add ECS-Init install pointer for non-Amazon Linux AMIs to README (#5161) * Enhancement - Remove direct docker run instructions fro
Vite is a frontend tooling framework for JavaScript. From 8.2.0 until 8.2.4 and 8.3.3, the first 4 bytes of files outside of server.fs setting can be returned to the browser by a request containing ?vite-wasm-instance. Requests containing the ?vite-wasm-instance query are handled by the internal Wasm plugin's load hook. The hook removes the query and reads the resulting path directly from disk, but the server.fs checks were not applied. After reading the file, Vite attempts to parse it as WebAssembly. When that parse fails, Node and deno throws an error that contains the first 4 bytes of the file. This vulnerability is fixed in 8.2.4 and 8.3.
Vite is a frontend tooling framework for JavaScript. Prior to 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3, import analysis can record a root-relative browser URL in safeModulePaths instead of the cleaned resolved module identifier. On a network-accessible, non-Windows development server, an imported project file whose URL matches an absolute host path can authorize a later raw-filesystem request for that host file, provided server.fs.deny does not block it. The request can disclose the matching file outside the project root, but it does not allow arbitrary path traversal because the host path must correspond to a project-relative URL authorized by
Vite is a frontend tooling framework for JavaScript. Prior to 6.4.4, 7.3.7, 8.1.6, 8.2.4, and 8.3.3, applications using custom middleware are vulnerable when they pass an unchanged browser request URL to server.transformIndexHtml. getHtmlFilename uses the query-bearing request URL to resolve an existing local file while preserving attacker-supplied leading slashes in the generated proxy module URL. If the transformed HTML contains an inline module script and a victim browser loads the crafted development-server page, the leading double slash makes the browser fetch and execute an attacker-controlled module in the Vite-served page. This execut
filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1.
filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1.
Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. Prior to version 1.18.1, on systems where at least one OCI remote is configured (most common on Fedora systems), a malicious local user in an active local session could use a crafted architecture name to trick the `flatpak-system-helper` process into creating a root-owned directory tree with contents determined by the OCI remote, plus a root-owned `lock` file and `icons` directory, outside the intended root directory. If this vulnerability is combined with other vulnerabilities also fixed in 1.18.1, the combination can lead to local root privi
filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. This issue is fixed in version 4.2.1.
filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.
filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.
filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.
filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.
This update for guava fixes the following issue: - CVE-2026-102554: Allocation of resources without limits or throttling (CWE-770) during Java object deserialization allows an attacker to cause a Denial of Service via OutOfMemoryError (bsc#1284985). Changes for guava: - Adapt the generated OSGi data to reality - Upgrade to guava 33.7.2 * Changes of 33.7.2 + collect: Changed MapMaker, CompactHashMap, and CompactHashSet deserialization to avoid eagerly allocating as much memory as a serialization payload requests (bsc#1284985, CVE-2026-102554) * Changes of 33.7.1 + removes the Multi-Release line from our jar manifest, fixing an iss
filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock can open a crafted SQLite lock database without bounding schema and query work, allowing another local user who can replace the database to make acquisition stall or hang; versions from 3.20.4 expose this on initial per-instance opening, and versions from 3.30.0 repeat the exposure on every acquisition. This issue is fixed in version 4.2.1.
filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock can restore a stale marker by name after moving it aside, allowing another local user with rename access in a non-sticky lock directory to swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory. This issue is fixed in version 4.2.1.
USN-8708-1 fixed a vulnerability in sudo-rs. This update provides the corresponding fix for Ubuntu 26.10. Original advisory details: It was discovered that sudo-rs incorrectly handled time-of-check vs time- of-use conditions in sudoedit. A local attacker with permission to edit specific files using sudoedit could use this issue to place files in arbitrary directories, and possibly escalate their privileges. This issue only affected systems configured to grant fine-grained sudoedit file editing permissions, which is not the default configuration.
filelock is a platform-independent file lock for Python. From 3.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result. This issue is fixed in version 4.2.1.
filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.
Compara tu pila y las versiones instaladas con las bases actuales de vulnerabilidades.