Common Weakness Enumeration (CWE)

Obscuring a password with a trivial encoding does not protect the password.

The authentication scheme or implementation uses key data elements that are assumed to be immutable, but can be controlled or modified by the attacker.

The product uses a transmission protocol that does not include a mechanism for verifying the integrity of the data during transmission, such as a checksum.

The product attempts to drop privileges but does not check or incorrectly checks to see if the drop succeeded.

The product specifies a regular expression in a way that causes data to be improperly matched or compared.

The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are explicitly allowed by policy because the inputs are assumed to be safe, but the list is too permissive - that is, it allows an input that is unsafe, leading to resultant weaknesses.

The product, when processing trusted data, accepts any untrusted data that is also included with the trusted data, treating the untrusted data as if it were trusted.

When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.

The product protects a primary channel, but it does not use the same level of protection for an alternate channel.

The product receives data from an upstream component, but does not completely filter special elements before sending it to a downstream component.

The product performs authentication based on the name of a resource being accessed, or the name of the actor performing the access, but it does not properly check all possible names for that resource or actor.

The product writes to a buffer using an index or pointer that references a memory location prior to the beginning of the buffer.

The product stores sensitive information in cleartext in memory.

The product does not properly protect an assumed-immutable element from being modified by an attacker.

The product implements an IOCTL with functionality that should be restricted, but it does not properly enforce access control for the IOCTL.

The product does not adequately filter user-controlled input for special elements with control implications.

When trying to keep information confidential, an attacker can often infer some of the information by using statistics.

The product performs multiple related behaviors, but the behaviors are performed in the wrong order in ways which may produce resultant weaknesses.

The elevated privilege level required to perform operations such as chroot() should be dropped immediately after the operation is performed.

The product establishes a communication channel with an endpoint and receives a message from that endpoint, but it does not sufficiently ensure that the message was not modified during transmission.

The product uses a WebSocket, but it does not properly verify that the source of data or communication is valid.

This entry has been deprecated. It originally came from PLOVER, which sometimes defined "other" and "miscellaneous" categories in order to satisfy exhaustiveness requirements for taxonomies. Within the context of CWE, the use of a more abstract entry is preferred in mapping situations. CWE-75 is a more appropriate mapping.

The product implements an authentication technique, but it skips a step that weakens the technique.

The product does not sufficiently protect all possible paths that a user can take to access restricted functionality or resources.

The product does not check for an error after calling a function that can return with a NULL pointer if the function fails, which leads to a resultant NULL pointer dereference.