CWE-1322: Use of Blocking Code in Single-threaded,… | Glexia
CWE-1322 (Use of Blocking Code in Single-threaded, Non-blocking Context) weakness overview with consequences, detection methods, mitigations, related CVEs and…
Glexia's Take · Automated analysis
CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context
Use of Blocking Code in Single-threaded, Non-blocking Context represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.
Executive Impact
- Availability: DoS: Resource Consumption (CPU): An unexpected call to blocking code can trigger an infinite loop, or a large loop that causes the software to pause and wait indefinitely.
Developer Pattern
CWE-1322 is the kind of defect developers can usually prevent with explicit validation, safer framework defaults, and tests that exercise hostile input or unsafe state transitions.
Automation confidence
high confidence from CWE-1322, 4.20.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Official CWE Definition
CWE-1322: Use of Blocking Code in Single-threaded, Non-blocking Context
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.
When an attacker can directly invoke the blocking code, or the blocking code can be affected by environmental conditions that can be influenced by an attacker, then this can lead to a denial of service by causing unexpected hang or freeze of the code. Examples of blocking code might be an expensive computation or calling blocking library calls, such as those that perform exclusive file operations or require a successful network operation. Due to limitations in multi-thread models, single-threaded models are used to overcome the resource constraints that are caused by using many threads. In such a model, all code should generally be non-blocking. If blocking code is called, then the event loop will effectively be stopped, which can be undesirable or dangerous. Such models are used in Python asyncio, Vert.x, and Node.js, or other custom event loop code.
Developer And Remediation Guidance
How teams prevent and detect this weakness
Causes
- Missing validation
- Unsafe defaults
- Insufficient authorization or memory-safety invariant
Remediation
- 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.
Detection
- Code review
- SAST
- DAST
- Focused regression tests
Mappings
Related CVEs, CWEs, and ATT&CK context
Related CWEs
ATT&CK Relevance
ATT&CK relevance is shown only when reviewed or responsibly inferred.