Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

In Apache CXF, STSTokenValidator checks whether a SAML assertion is signed by a trusted certificate before deciding to send it to the STS. That result was stored in one object shared by all requests, so one request could read another's result. A remote, unauthenticated attacker could send a forged assertion signed with an untrusted certificate while legitimate requests were being processed, and it could be accepted as trusted without ever reaching the STS. Only services that use STSTokenValidator to validate SAML tokens without alwaysValidateToSts set are affected.  Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.Show less

Improper Verification of Cryptographic Signature vulnerability in Apache CXF's JAX-RS XML Security module. The JAX-RS XML Signature interceptors (XmlSigInHandler, XmlSigInInterceptor and the streaming XmlSecInInterceptor) did not ensure that the XML passed to the application was covered by the signature. An attacker with any document signed by a trusted key could wrap it in unsigned content, which the application would then treat as signed. Users are recommended to upgrade to versions 4.2.4 or 4.1.9 or 3.6.13, which fix this issue.Show less

The ITE IT8xxx2 SHI host-command backend (subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c) copied the 8-byte host-command request header from the SPI Rx FIFO directly into the shared receive buffer data->in_msg and only afterwards checked the protocol version and the derived packet length. The interrupt handler also accepted a chip-select assertion and an Rx-valid-length (RVLI) interrupt in any driver state other than SHI_STATE_DISABLED, so a new header could be parsed while the host-command thread was still processing the previous request out of the very same buffer. The host processor is the SPI controller and drives both chip select and the clock. After sending a well-formed request it can immediately de-assert chip select — which returns the driver to the ready state and re-enables the FIFO — and start a second transaction carrying a header with data_len = 0xFFFF. Those eight bytes are written into in_msg before the oversized length is rejected, so they land in a buffer whose contents verify_rx() in subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c has already validated. If this lands in the window before the host-command thread executes args.input_buf_size = rx_header->data_len, the framework hands the registered command handler a 65535-byte input length over a 256-byte buffer. The result is an out-of-bounds read of up to roughly 64 KiB beyond the request buffer: command handlers that copy or echo input_buf_size bytes disclose adjacent embedded-controller memory back to the host or overflow the response buffer, and a read past the end of SRAM faults the controller. The same race also allows cmd_id and cmd_ver to be swapped after checksum verification and after handler lookup. Exploitation requires the ability to drive the inter-processor SHI bus (a compromised host OS or physical access to the SPI lines) and winning a timing race, which the SPI controller can retry indefinitely. The fix parses the header into a local struct ec_host_cmd_request_header and copies it into in_msg only after the length has been bounded by sizeof(data->in_msg), and ignores chip-select and RVLI interrupts outside SHI_STATE_READY_TO_RECV/SHI_STATE_RECEIVING. A residual, bounded race remains: an end-of-transaction interrupt still resets the state to ready while the host-command thread owns the buffer, so a valid second request can still overwrite the in-flight request's contents, unlike the NPCX backend which parks in SHI_STATE_CNL_RESP_NOT_RDY while the buffer is in use.Show less

HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.Show less

A race condition and thread-safety vulnerability exists in the web management daemon of Brocade Fabric OS versions before 10.0.1. When handling user authentication requests across a multi-threaded execution pool, this race condition causes PAM modules to process stale or incorrect client IP addresses and switch context numbers. This leads to inaccurate audit records and potential access control bypasses where AAA evaluation or Calling-Station-ID ACL policies rely on client IP attributes.Show less

A race condition vulnerability exists in the request processing logic of the REST management interface on Brocade Fabric OS versions before 10.0.1. When handling concurrent incoming network management FCIP requests, a timing window exists between when a request populates the address variable and when the service constructs and returns the response context. As a result, the first request adopts the modified context, causing the service to return sensitive management details or configuration data belonging to the second context back to the original requester.Show less

MISP contains a race condition in the email-based one-time password (OTP) login flow. When two HTTP requests carrying the same valid OTP are submitted concurrently, both can successfully authenticate and establish a session. The root cause is that the OTP value is read from the shared store, validated, and then deleted in separate non-atomic steps, allowing a second in-flight request to read the same value before the first request's deletion takes effect. Preconditions: - The target MISP instance has email OTP login enabled. - The attacker possesses a valid, unexpired OTP (e.g., via email interception or social engineering). - The attacker can issue two HTTP POST requests in close temporal proximity. Impact: - The one-time-use guarantee of the OTP is violated; a single code can yield two authenticated sessions. - This weakens the authentication control and may facilitate unauthorized access if the OTP is shared or intercepted. Affected versions: <2.5.48Show less

Obot 0.25.0 before 0.25.6 and 0.26.0 before 0.26.1 contains a race condition in auth provider group refreshes that can restore group memberships just revoked in the identity provider. When overlapping refreshes for the same user commit out of order, stale memberships are persisted and the user retains revoked group-based access for about ten minutes.Show less

Backstage is an open framework for building developer portals. Prior to 3.3.1, 3.4.1, 4.0.3 and 4.1.0, the @backstage/plugin-scaffolder-backend package is affected by improper task state validation in scaffolder backend. An authenticated user with permission to create and access Scaffolder tasks may, under specific timing and deployment conditions, affect files accessible to the Backstage backend. If backend application files are writable, the confidentiality, integrity, and availability of the backend may be compromised. This issue is fixed in versions 3.3.1, 3.4.1, 4.0.3 and 4.1.0.Show less

In ep_free of eventpoll.c, there is a possible use-after-free due to a race condition. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Show less

Race condition in Chromoting in Google Chrome prior to 155.0.8059.39 allowed a remote attacker leveraging social engineering to potentially bypass system access restrictions via crafted network traffic. (Chromium security severity: Low)Show less

Race condition in Fonts in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: High)Show less

Race condition in Fonts in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to potentially execute arbitrary code outside the sandbox via a crafted HTML page. (Chromium security severity: Medium)Show less