CWE-1088, Synchronous Access of Remote Resource without Timeout, applies when code makes a synchronous call to a remote resource but sets no timeout, or sets it to infinite.
Almost any service that talks to another service can hit this. Web handlers that call an API, workers that fetch a URL, and applications that query a remote database all qualify. MITRE allows this entry for mapping real world vulnerabilities.
How it happens
Many HTTP and database clients default to waiting forever, or to a very long wait. The developer writes the call, it works in testing, and no one thinks about the day the remote side stops responding.
# Vulnerable pattern: no timeout, the call can block forever
import requests
def fetch_profile(url):
return requests.get(url).json()
If the remote host accepts the connection and then never answers, this thread waits indefinitely. Enough stuck threads and the service stops serving anyone.
# Fix: always set a timeout (connect, read) in seconds
import requests
def fetch_profile(url):
r = requests.get(url, timeout=(3, 10))
r.raise_for_status()
return r.json()
The same pattern appears in every language. In Java, set connect and read timeouts on the HTTP client. In Go, set a timeout on the client or use a context with a deadline. In Node, pass an abort signal or a timeout option.
What an attacker gains
MITRE lists reduced reliability: an outage of the remote resource can cause the product to hang. If an attacker can reach the code, they can turn that into a denial of service.
Two real examples appear in the record. CVE-2024-8062 is described as an API endpoint that performs a HEAD request without a timeout, allowing attackers to cause the server to hang. CVE-2024-8061 is described as a development product for AI that can make requests to external servers without timeouts and does not respond to other requests while waiting, allowing denial of service.
The attack idea is the same in both: point the server at something slow, and the server does the rest of the damage to itself. Any feature that fetches a user supplied URL deserves extra attention.
How to find it
- Search the code for outbound calls and check each one for a timeout argument.
- Read the default settings of your HTTP and database clients. Do not assume they are safe.
- In tests, point the code at a server that accepts connections and never replies. A hang tells you the timeout is missing.
- Watch for thread pool exhaustion and rising request latency in production, which are the symptoms.
- A dynamic scan of the API, or a code scan that lists outbound calls, can help build the list.
How to fix it
The record lists no formal mitigations, so these are standard practice.
- Set an explicit connect timeout and read timeout on every remote call.
- Choose values from real latency data, with room for normal spikes but not minutes.
- Add a total deadline for the whole operation, not only for each socket step.
- Limit retries and add backoff, so a slow dependency is not hit harder.
- Use a circuit breaker so repeated failures stop calls for a while.
- Isolate pools, so one slow dependency cannot use every worker thread.
- For user supplied URLs, restrict destinations and cap response size and time.
Try it yourself
Walk through an API security scan and see what the findings look like.
Click through it at your own pace, or open it full screen.
Quick check
Why is a long timeout nearly as bad as none?
Threads still pile up while they wait. A slow dependency can exhaust workers well before a multi minute timeout fires.
Which calls need a timeout?
Every synchronous call to something outside your process: HTTP requests, database queries, message broker calls, DNS lookups and file reads on network storage.
