Apache Storm Worker Launcher: Local Privilege Escalation to Root via a Time-of-Check Race in the Worker Launcher

Description The setuid-root `worker-launcher` binary adjusts ownership and permissions of worker directories by walking the tree with FTS and calling `lchown` and `chmod` on each entry's full pathname while running with an effective uid of 0. Both syscalls re-resolve the path at the time of the call, after FTS has classified the entry, and the trees being walked are owned and writable by the untrusted topology user. A tenant running code on a supervisor node could therefore replace an intermediate directory component with a symbolic link between classification and the privileged operation, redirecting the root-owned `lchown` or `chmod` at an arbitrary file on the host. The operation is repeatable at will, since crashing a worker forces a relaunch and blob updates re-run the walk, so a failed attempt costs the attacker nothing. This crosses the boundary that `supervisor.run.worker.as.user` and container isolation are intended to enforce. It is the same defect class as the Hadoop container-executor issues from which this code derives. Mitigation Upgrade to 3.1.0, where the privileged walk operates on file descriptors it has already stat'd rather than on pathnames re-resolved at call time. Users who cannot upgrade immediately should not run untrusted topology code on supervisors configured with `supervisor.run.worker.as.user`, since the launcher is the boundary being crossed. Note that the launcher must be rebuilt and reinstalled after upgrading; replacing the Java artifacts alone is not sufficient. Credit The ASF -- found using Claude agents to study the security of open-source projects, validated and reported by Apache Storm.

In multiple functions of face_status.h, there is a possible way to modify verified biometric enrollment data in shared memory due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

NocoDB before 2026.08.1 Password Reset Token Race Condition

NocoDB before 2026.08.1 contains a race condition vulnerability in users.service.ts that allows holders of a valid reset token to perform multiple password changes by sending concurrent reset requests. Attackers can exploit the window created by slow bcrypt hashing before the token is cleared to overwrite the owner's new password and lock them out.

NocoDB before 2026.08.0 Refresh Token Reuse via Non-Atomic Rotation

NocoDB before 2026.08.0 contains a race condition in refresh-token rotation that allows attackers to reuse tokens because UserRefreshToken.ts never checks the affected-row count. Attackers holding a captured refresh token can present it concurrently with the legitimate user to obtain a valid authenticated session, and no reuse event is recorded.

NocoDB before 2026.06.2 OAuth Refresh Token Rotation Race Condition

NocoDB before 2026.06.2 contains a race condition vulnerability in oauth-token.service.ts that allows attackers to reuse a refresh token by presenting it concurrently during non-atomic rotation. Attackers holding a captured refresh token can race the legitimate client to obtain their own access and refresh tokens, retaining scoped access without triggering reuse detection.

n8n before 2.46.1 Arbitrary File Read via Browser Use browser_upload Tool

n8n before 2.46.1 contains an arbitrary file read vulnerability that allows authenticated members to read server files by supplying absolute paths to the Browser Use browser_upload tool. Attackers with a connected remote browser session can have Playwright read files such as instance configuration from the n8n server and retrieve their contents from the page.

Wasmtime 48.0.0 before 48.0.8 TOCTOU UDP Send Policy Bypass via wasip3 Sockets

Wasmtime's wasmtime-wasi crate 48.0.0 before 48.0.8, 49.0.0 before 49.0.5, and 50.0.0 before 50.0.1 contains a time-of-check/time-of-use race in the wasip3 wasi:sockets udp-socket host implementation that lets guests bypass socket_addr_check send restrictions. A malicious guest can race udp-socket.send against udp-socket.connect to deliver attacker-controlled datagrams to addresses the policy permits only for receiving.

Zipline before 4.7.0 Race Condition in Invite and Quota Limits

Zipline before 4.7.0 contains a race condition vulnerability that allows users to bypass invitation usage limits, upload storage quotas, and shortened-URL quotas through concurrent requests. Attackers can send overlapping registration, upload, or URL creation requests that pass checks against stale state, creating extra accounts and exceeding administrator-configured resource quotas.

Zipline before 4.6.5 TOCTOU Race Condition via /api/setup

Zipline before 4.6.5 contains a TOCTOU race condition in the POST /api/setup endpoint that allows unauthenticated attackers to create multiple SUPERADMIN accounts by racing concurrent requests before the firstSetup flag is reset. Attackers can send simultaneous requests with spoofed X-Forwarded-For headers during the argon2 hashing window to gain full administrative control of the instance.

OpenMage magento-lts before 20.19.0 Race Condition in Coupon Usage Limits

OpenMage magento-lts before 20.19.0 and 21.0.0-beta1 before 21.0.0-beta3 contains a race condition in shopping cart price rule usage limits, because Mage_SalesRule_Model_Validator checks coupon limits without locking and the usage counters are later incremented non-atomically. Unauthenticated attackers, including guest shoppers, can submit concurrent checkouts to redeem a limited coupon more times than its cap allows.

Paaster: TOCTOU race condition defeats the 'burn after reading' guarantee on view-once pastes

Paaster is a pastebin application. Prior to version 3.3.0, Paaster's "view once" (burn-after-reading) paste mode can be bypassed with concurrent requests. The check that's supposed to enforce single-use is a plain read followed by a separate write, with no atomicity, so multiple simultaneous requests can all see the paste as "not yet read" and all successfully retrieve it. This issue has been patched in version 3.3.0.

Zipline before 4.8.0 maxViews Limit Bypass via Race Condition

Zipline before 4.8.0 contains a race condition vulnerability in src/server/routes/raw/[id].ts that allows remote attackers to bypass file maxViews limits through non-atomic view counting. Attackers holding a file link can send parallel requests that read the same pre-increment count, viewing view-limited or delete-on-max-views files beyond their limit.

Dell Display and Peripheral Manager (DDPM Windows), versions prior to 2.4.0.17, contain a Time-of-check Time-of-use (TOCTOU) Condition vulnerability. A low privileged attacker with local access could potentially exploit this vulnerability, leading to Code execution.

A time-of-check to time-of-use (TOCTOU) race condition in the AMD SEV Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative privileges to bypass security checks on scatter lists, potentially resulting in loss of guest integrity.

Improper access control within the AMD Secure Encrypted Virtualization (SEV) firmware could allow an attacker with administrative privileges to tamper with memory, potentially resulting in loss of guest memory integrity.

In handle_chan_msg of tipc_virtio_dev.c, there is a possible way to bypass memory tag access controls via concurrent shared memory modification due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

In multiple locations, there is a possible way to modify authenticated coprocessor firmware in shared memory before loading due to a race condition. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Windows Security Account Manager Remote Protocol Security Feature Bypass Vulnerability

Time-of-check time-of-use (toctou) race condition in Windows Security Account Manager allows an unauthorized attacker to bypass a security feature over a network.

iio: event: Fix event FIFO reset race

In the Linux kernel, the following vulnerability has been resolved: iio: event: Fix event FIFO reset race `iio_event_getfd()` creates the event file descriptor with `anon_inode_getfd()`, which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller. The IIO code resets the event FIFO after `anon_inode_getfd()` has returned, but before `IIO_GET_EVENT_FD_IOCTL` has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a `read()` on it as soon as the fd has been installed. This means the `kfifo_to_user()` in `iio_event_chrdev_read()` can run in parallel with the `kfifo_reset_out()` in `iio_event_getfd()`. The kfifo documentation says that `kfifo_reset_out()` is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as `kfifo_reset()`. If that happens, `kfifo_to_user()` can advance the FIFO `out` index based on state from before the reset, after the reset has already moved the `out` index to the current `in` index. That can leave the FIFO with an `out` index past the `in` index. A later `read()` can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace. Move the FIFO reset before `anon_inode_getfd()`. At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.

APT RCE via hard link reuse

On Debian, Ubuntu, and derivative Linux distributions, an on-path attacker who can manipulate the HTTP traffic (including a malicious mirror or proxy) between an APT client and an archive server triggered by a package install can trick the client into installing an attacker-controlled unverified package and achieve remote code execution with root privileges. The vulnerability is caused by the reuse of hard links and requires the client to follow redirects and retry the download of package files. It requires the client to have a non-zero Acquire::Retries configuration setting; the value 3 is the default starting with Debian 12 (bookworm) and Ubuntu 22.04 LTS (Jammy Jellyfish), so older releases are unaffected in a default configuration