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.
How it's found
Use of Blocking Code in Single-threaded, Non-blocking Context is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.
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.
Consequences
- 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.
Mitigations
- 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.
Where this fits in a TurboPentest engagement
This weakness is not covered by the automated black-box pentest. IntegSec pentesters cover it in a manual engagement.
Frequently asked questions
What is 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.
How do you find Use of Blocking Code in Single-threaded, Non-blocking Context?
Use of Blocking Code in Single-threaded, Non-blocking Context is typically found by tracing untrusted input from where it enters the system to the point where it is used without the check or neutralization this weakness describes, combining manual code review with dynamic testing.
What is the impact of CWE-1322?
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.
Does TurboPentest test for Use of Blocking Code in Single-threaded, Non-blocking Context?
This weakness is not covered by the automated black-box pentest. IntegSec pentesters cover it in a manual engagement.
Related CWEs
Written and reviewed by
Michel Chamberland - Founder & CEO, IntegSec
CISSP, OSCP, OSCE, CEH, GIAC, CCSK · 20+ years in offensive security
Michel has spent 20+ years on offensive security teams including IBM X-Force Red and Trustwave SpiderLabs, leading penetration tests, red team engagements, and breach response for Fortune 500 customers. He is the founder of IntegSec and the architect of TurboPentest.
Find these issues before an attacker does
TurboPentest runs an agentic AI pentest against your target and reports findings with proof, from $99 per target.
Start a pentest