CVE Vulnerabilities


Improper Input Validation

Published: Aug 18, 2003 | Modified: Oct 30, 2018
CVSS 3.x
CVSS 2.x
7.8 HIGH

Cisco IOS 11.x and 12.0 through 12.2 allows remote attackers to cause a denial of service (traffic block) by sending a particular sequence of IPv4 packets to an interface on the device, causing the input queue on that interface to be marked as full.


The product receives input or data, but it does not validate or incorrectly validates that the input has the properties that are required to process the data safely and correctly.

Affected Software

Name Vendor Start Version End Version
Ios Cisco 11.0 11.0
Ios Cisco 11.1 11.1
Ios Cisco 11.1aa 11.1aa
Ios Cisco 11.1ca 11.1ca
Ios Cisco 11.1cc 11.1cc
Ios Cisco 11.2 11.2
Ios Cisco 11.2p 11.2p
Ios Cisco 11.2sa 11.2sa
Ios Cisco 11.3 11.3
Ios Cisco 11.3t 11.3t
Ios Cisco 12.0 12.0
Ios Cisco 12.0da 12.0da
Ios Cisco 12.0db 12.0db
Ios Cisco 12.0dc 12.0dc
Ios Cisco 12.0s 12.0s
Ios Cisco 12.0sc 12.0sc
Ios Cisco 12.0sl 12.0sl
Ios Cisco 12.0sp 12.0sp
Ios Cisco 12.0st 12.0st
Ios Cisco 12.0sx 12.0sx
Ios Cisco 12.0sy 12.0sy
Ios Cisco 12.0sz 12.0sz
Ios Cisco 12.0t 12.0t
Ios Cisco 12.0w5 12.0w5
Ios Cisco 12.0wc 12.0wc
Ios Cisco 12.0wt 12.0wt
Ios Cisco 12.0xa 12.0xa
Ios Cisco 12.0xb 12.0xb
Ios Cisco 12.0xc 12.0xc
Ios Cisco 12.0xd 12.0xd
Ios Cisco 12.0xe 12.0xe
Ios Cisco 12.0xf 12.0xf
Ios Cisco 12.0xg 12.0xg
Ios Cisco 12.0xh 12.0xh
Ios Cisco 12.0xi 12.0xi
Ios Cisco 12.0xj 12.0xj
Ios Cisco 12.0xk 12.0xk
Ios Cisco 12.0xl 12.0xl
Ios Cisco 12.0xm 12.0xm
Ios Cisco 12.0xn 12.0xn
Ios Cisco 12.0xp 12.0xp
Ios Cisco 12.0xq 12.0xq
Ios Cisco 12.0xr 12.0xr
Ios Cisco 12.0xs 12.0xs
Ios Cisco 12.0xu 12.0xu
Ios Cisco 12.0xv 12.0xv
Ios Cisco 12.0xw 12.0xw
Ios Cisco 12.1 12.1
Ios Cisco 12.1aa 12.1aa
Ios Cisco 12.1ax 12.1ax
Ios Cisco 12.1ay 12.1ay
Ios Cisco 12.1da 12.1da
Ios Cisco 12.1db 12.1db
Ios Cisco 12.1dc 12.1dc
Ios Cisco 12.1e 12.1e
Ios Cisco 12.1ea 12.1ea
Ios Cisco 12.1eb 12.1eb
Ios Cisco 12.1ec 12.1ec
Ios Cisco 12.1ev 12.1ev
Ios Cisco 12.1ew 12.1ew
Ios Cisco 12.1ex 12.1ex
Ios Cisco 12.1ey 12.1ey
Ios Cisco 12.1m 12.1m
Ios Cisco 12.1t 12.1t
Ios Cisco 12.1xa 12.1xa
Ios Cisco 12.1xb 12.1xb
Ios Cisco 12.1xc 12.1xc
Ios Cisco 12.1xd 12.1xd
Ios Cisco 12.1xe 12.1xe
Ios Cisco 12.1xf 12.1xf
Ios Cisco 12.1xg 12.1xg
Ios Cisco 12.1xh 12.1xh
Ios Cisco 12.1xi 12.1xi
Ios Cisco 12.1xj 12.1xj
Ios Cisco 12.1xk 12.1xk
Ios Cisco 12.1xl 12.1xl
Ios Cisco 12.1xm 12.1xm
Ios Cisco 12.1xp 12.1xp
Ios Cisco 12.1xq 12.1xq
Ios Cisco 12.1xr 12.1xr
Ios Cisco 12.1xs 12.1xs
Ios Cisco 12.1xt 12.1xt
Ios Cisco 12.1xu 12.1xu
Ios Cisco 12.1xv 12.1xv
Ios Cisco 12.1xw 12.1xw
Ios Cisco 12.1xx 12.1xx
Ios Cisco 12.1xy 12.1xy
Ios Cisco 12.1xz 12.1xz
Ios Cisco 12.1yb 12.1yb
Ios Cisco 12.1yc 12.1yc
Ios Cisco 12.1yd 12.1yd
Ios Cisco 12.1ye 12.1ye
Ios Cisco 12.1yf 12.1yf
Ios Cisco 12.1yh 12.1yh
Ios Cisco 12.1yi 12.1yi
Ios Cisco 12.1yj 12.1yj
Ios Cisco 12.2 12.2
Ios Cisco 12.2b 12.2b
Ios Cisco 12.2bc 12.2bc
Ios Cisco 12.2bw 12.2bw
Ios Cisco 12.2bx 12.2bx
Ios Cisco 12.2bz 12.2bz
Ios Cisco 12.2cx 12.2cx
Ios Cisco 12.2cy 12.2cy
Ios Cisco 12.2da 12.2da
Ios Cisco 12.2dd 12.2dd
Ios Cisco 12.2dx 12.2dx
Ios Cisco 12.2ja 12.2ja
Ios Cisco 12.2mb 12.2mb
Ios Cisco 12.2mc 12.2mc
Ios Cisco 12.2mx 12.2mx
Ios Cisco 12.2s 12.2s
Ios Cisco 12.2sx 12.2sx
Ios Cisco 12.2sy 12.2sy
Ios Cisco 12.2sz 12.2sz
Ios Cisco 12.2t 12.2t
Ios Cisco 12.2xa 12.2xa
Ios Cisco 12.2xb 12.2xb
Ios Cisco 12.2xc 12.2xc
Ios Cisco 12.2xd 12.2xd
Ios Cisco 12.2xe 12.2xe
Ios Cisco 12.2xf 12.2xf
Ios Cisco 12.2xg 12.2xg
Ios Cisco 12.2xh 12.2xh
Ios Cisco 12.2xi 12.2xi
Ios Cisco 12.2xj 12.2xj
Ios Cisco 12.2xk 12.2xk
Ios Cisco 12.2xl 12.2xl
Ios Cisco 12.2xm 12.2xm
Ios Cisco 12.2xn 12.2xn
Ios Cisco 12.2xq 12.2xq
Ios Cisco 12.2xr 12.2xr
Ios Cisco 12.2xs 12.2xs
Ios Cisco 12.2xt 12.2xt
Ios Cisco 12.2xu 12.2xu
Ios Cisco 12.2xw 12.2xw
Ios Cisco 12.2ya 12.2ya
Ios Cisco 12.2yb 12.2yb
Ios Cisco 12.2yc 12.2yc
Ios Cisco 12.2yd 12.2yd
Ios Cisco 12.2yf 12.2yf
Ios Cisco 12.2yg 12.2yg
Ios Cisco 12.2yh 12.2yh
Ios Cisco 12.2yj 12.2yj
Ios Cisco 12.2yk 12.2yk
Ios Cisco 12.2yl 12.2yl
Ios Cisco 12.2ym 12.2ym
Ios Cisco 12.2yn 12.2yn
Ios Cisco 12.2yo 12.2yo
Ios Cisco 12.2yp 12.2yp
Ios Cisco 12.2yq 12.2yq
Ios Cisco 12.2yr 12.2yr
Ios Cisco 12.2ys 12.2ys
Ios Cisco 12.2yt 12.2yt
Ios Cisco 12.2yu 12.2yu
Ios Cisco 12.2yv 12.2yv
Ios Cisco 12.2yw 12.2yw
Ios Cisco 12.2yx 12.2yx
Ios Cisco 12.2yy 12.2yy
Ios Cisco 12.2yz 12.2yz
Ios Cisco 12.2za 12.2za
Ios Cisco 12.2zb 12.2zb
Ios Cisco 12.2zc 12.2zc
Ios Cisco 12.2zd 12.2zd
Ios Cisco 12.2ze 12.2ze
Ios Cisco 12.2zf 12.2zf
Ios Cisco 12.2zg 12.2zg
Ios Cisco 12.2zh 12.2zh
Ios Cisco 12.2zj 12.2zj

Extended Description

Input validation is a frequently-used technique for checking potentially dangerous inputs in order to ensure that the inputs are safe for processing within the code, or when communicating with other components. When software does not validate input properly, an attacker is able to craft the input in a form that is not expected by the rest of the application. This will lead to parts of the system receiving unintended input, which may result in altered control flow, arbitrary control of a resource, or arbitrary code execution. Input validation is not the only technique for processing input, however. Other techniques attempt to transform potentially-dangerous input into something safe, such as filtering (CWE-790) - which attempts to remove dangerous inputs - or encoding/escaping (CWE-116), which attempts to ensure that the input is not misinterpreted when it is included in output to another component. Other techniques exist as well (see CWE-138 for more examples.) Input validation can be applied to:

Data can be simple or structured. Structured data can be composed of many nested layers, composed of combinations of metadata and raw data, with other simple or structured data. Many properties of raw data or metadata may need to be validated upon entry into the code, such as:

Implied or derived properties of data must often be calculated or inferred by the code itself. Errors in deriving properties may be considered a contributing factor to improper input validation.

Note that “input validation” has very different meanings to different people, or within different classification schemes. Caution must be used when referencing this CWE entry or mapping to it. For example, some weaknesses might involve inadvertently giving control to an attacker over an input when they should not be able to provide an input at all, but sometimes this is referred to as input validation. Finally, it is important to emphasize that the distinctions between input validation and output escaping are often blurred, and developers must be careful to understand the difference, including how input validation is not always sufficient to prevent vulnerabilities, especially when less stringent data types must be supported, such as free-form text. Consider a SQL injection scenario in which a person’s last name is inserted into a query. The name “O’Reilly” would likely pass the validation step since it is a common last name in the English language. However, this valid name cannot be directly inserted into the database because it contains the “'” apostrophe character, which would need to be escaped or otherwise transformed. In this case, removing the apostrophe might reduce the risk of SQL injection, but it would produce incorrect behavior because the wrong name would be recorded.

Potential Mitigations

  • 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.
  • For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
  • Even though client-side checks provide minimal benefits with respect to server-side security, they are still useful. First, they can support intrusion detection. If the server receives input that should have been rejected by the client, then it may be an indication of an attack. Second, client-side error-checking can provide helpful feedback to the user about the expectations for valid input. Third, there may be a reduction in server-side processing time for accidental input errors, although this is typically a small savings.
  • Inputs should be decoded and canonicalized to the application’s current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
  • Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.