Use of Blocking Code in Single-threaded, Non-blocking Context
CWE-1322
The product uses a non-blocking model that relies on a single threaded process for features such as scalability, but it contains code that can block when it is invoked.
We track 2 vulnerabilities of this type. 100% are rated high or critical, and the average CVSS score is 7.5.
How this weakness is prevented
- Implementation: Generally speaking, blocking calls should be replaced with non-blocking alternatives that can be used asynchronously. Expensive computations should be passed off to worker threads, although the correct approach depends on the framework being used.
- Implementation: For expensive computations, consider breaking them up into multiple smaller computations. Refer to the documentation of the framework being used for guidance.
Latest Use of Blocking Code in Single-threaded, Non-blocking Context vulnerabilities
- 7.5 High severity
Red Hat Edge Manager 1: Use of Blocking Code in Single-threaded, Non-blocking Context
A flaw was found in flightctl. A TLS handshake is performed synchronously in the HTTP server’s connection-context callback without a deadline. A network-reachable unauthenticated client can stall the handshake and prevent the affected listener from accepting n
- 7.5 High severity
@fastify/busboy: Loop with Unreachable Exit Condition
@fastify/busboy is a multipart form-data parser. In versions 3.1.0 through 3.2.0, a remote unauthenticated attacker can stall the Node.js event loop by sending a multipart request whose boundary is crafted to a specific length. The vendored streaming search st