CWE-182
Collapse of Data into Unsafe Value
Common consequences1
- Access ControlBypass Protection Mechanism
Potential mitigations4
- Architecture and Design
Avoid making decisions based on names of resources (e.g. files) if those resources can have alternate names.
- Implementation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation
Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked.
Canonicalize the name to match that of the file system's representation of the name. This can sometimes be achieved with an available API (e.g. in Win32 the GetFullPathName function).
CVEs referencing this CWE3
| CVE | Description | Severity | EPSS | Flags | Modified |
|---|---|---|---|---|---|
| CVE-2024-25617 | Squid is an open source caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to a Collapse of Data into Unsafe Value bug ,Squid may be vulnerable to a Denial of Service attack against HTTP header parsing. This problem allows a remote client or a remote server to perform Denial of Service when sending oversized headers in HTTP messages. In versions of Squid prior to 6.5 this can be achieved if the request_header_max_size or reply_header_max_size settings are unchanged from the default. In Squid version 6.5 and later, the default setting of these parameters is safe. Squid will emit a critical warning in cache.log if the administrator is setting these parameters to unsafe values. Squid will not at this time prevent these settings from being changed to unsafe values. Users are advised to upgrade to version 6.5. There are no known workarounds for this vulnerability. This issue is also tracked as SQUID-2024:2 | HIGH7.5 | 89%p100 | 2025-06-25 | |
| CVE-2020-7921 | Improper serialization of internal state in the authorization subsystem in MongoDB Server's authorization subsystem permits a user with valid credentials to bypass IP whitelisting protection mechanisms following administrative action. This issue affects MongoDB Server v4.2 versions prior to 4.2.3; MongoDB Server v4.0 versions prior to 4.0.15; MongoDB Server v4.3 versions prior to 4.3.3and MongoDB Server v3.6 versions prior to 3.6.18. | MEDIUM5.3 | 0.66%p47 | 2026-02-23 | |
| CVE-2026-47241 | ### Summary Several Net::IMAP commands accept a raw string argument which is only validated to prevent CRLF injection and then sent verbatim. If this string is derived from user-controlled input, an attacker can force the next command to be absorbed as a continuation of the first command. This will cause the first command to eventually fail, but also prevents it from returning until another command is sent (from another thread). That other command will not return until the connection is closed. ### Details `Net::IMAP::RawData` was hardened in v0.6.4, v0.5.14, and v0.4.24 to reject string arguments that would smuggle an invalid literal-continuation marker onto the wire (CVE-2026-42257, GHSA-hm49-wcqc-g2xg). But the trailing-marker check uses an incorrect regex which does not match `{0}` or `{0+}`, so an attacker-controlled seach `criteria` or fetch `attr` string ending in `{0}` or `{0+}` passes validation and is sent verbatim. Since these arguments are sent as the last argument in the command, they will be followed by CRLF. Although the CRLF was intended to end the command, the server will interpret it as part of a literal prefix. This consumes the next command the client puts on the socket as additional arguments to the current command. This affects the following command's arguments: * `criteria` for `#search` and `#uid_search` * `search_keys` for `#sort`, `#thread`, `#uid_sort`, and `#uid_thread` * `attr` for `#fetch` and `#uid_fetch` The command which contained the attacker's raw data will not be able to complete until the _next_ command is issued. If commands are only sent from single thread, the first command will hang until the connection times out (most likely by the server closing the connection). If a second command is sent _(from another thread)_, this would allow the server to respond to the first command. This combined command _will_ be invalid: * The `{0}\r\n` literal prohibits other arguments (such as a quoted string) from spanning both commands * It will be sent without the space delimiter which is required between arguments. * The second command's tag will not be a valid argument to any of the vulnerable commands. So the server _should_ respond to the first command with a `BAD` response, which will raise a `BadResponseError`. But, since the server never saw a second command, the second command will never receive a tagged response and the thread that sent it will hang until the connection is closed. ### Impact This will result in unexpected crashes and timeouts, which could be used to create a simple denial of service attack. This attack will present very similarly to common network issues or server issues which also result in commands hanging or unexpectedly raising exceptions. By itself, this does not allow command injection. But the confusion caused by these errors could lead to other downstream issues, especially in a multi-threaded environment. ### Mitigation Update to a patched version of `net-imap` which validates that `RawData` arguments may not end with literal continuation markers. If `net-imap` cannot be upgraded: * Validate that user input to the affected command arguments does not end with `"}"`. * Use of `Timeout` or other standard strategies for slow connections and misbehaving servers will also mitigate the effects of this. _Extra caution is required when issuing commands from multiple threads._ While `net-imap` does have rudimentary support for issuing commands from multiple threads, the user is responsible for synchronizing that commands are issued in a logically coherent order, and for ensuring that commands are only pipelined when it is safe to do so. Practically, this means that many commands cannot be safely pipelined together, and user code will often need to wait for state changing commands to successfully complete before issuing commands that rely on that state change. | NONE | no EPSS | 2026-06-09 |