The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere.

Primary

Architecture and Design
OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.

Confidentiality
Read Application Data
An attacker with access to the system could read sensitive information stored in cleartext (i.e., unencrypted). Even if the information is encoded in a way that is not human-readable, certain techniques could determine which encoding is being used, then decode the information.

Automated Static Analysis
Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
High

Implementation
System Configuration
Operation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to encrypt the data at rest. [REF-1297] [REF-1299] [REF-1301]

Implementation
System Configuration
Operation
In some systems/environments such as cloud, the use of "double encryption" (at both the software and hardware layer) might be required, and the developer might be solely responsible for both layers, instead of shared responsibility with the administrator of the broader system/environment.

The following code excerpt stores a plaintext user account ID in a browser cookie.

response.addCookie( new Cookie("userAccountID", acctID);

Because the account ID is in plaintext, the user's account information is exposed if their computer is compromised by an attacker.

This code writes a user's login information to a cookie so the user does not have to login again later.

function persistLogin($username, $password){$data = array("username" => $username, "password"=> $password);setcookie ("userdata", $data);}

The code stores the user's username and password in plaintext in a cookie on the user's machine. This exposes the user's login information if their computer is compromised by an attacker. Even if the user's machine is not compromised, this weakness combined with cross-site scripting (CWE-79) could allow an attacker to remotely copy the cookie.
Also note this example code also exhibits Plaintext Storage in a Cookie (CWE-315).

The following code attempts to establish a connection, read in a password, then store it to a buffer.

server.sin_family = AF_INET; hp = gethostbyname(argv[1]);if (hp==NULL) error("Unknown host");memcpy( (char *)&server.sin_addr,(char *)hp->h_addr,hp->h_length);if (argc < 3) port = 80;else port = (unsigned short)atoi(argv[3]);server.sin_port = htons(port);if (connect(sock, (struct sockaddr *)&server, sizeof server) < 0) error("Connecting");...while ((n=read(sock,buffer,BUFSIZE-1))!=-1) {

write(dfd,password_buffer,n);...

While successful, the program does not encrypt the data before writing it to a buffer, possibly exposing it to unauthorized actors.

The following examples show a portion of properties and configuration files for Java and ASP.NET applications. The files include username and password information but they are stored in cleartext.
This Java example shows a properties file with a cleartext username / password pair.

# Java Web App ResourceBundle properties file
...webapp.ldap.username=secretUsernamewebapp.ldap.password=secretPassword...

The following example shows a portion of a configuration file for an ASP.Net application. This configuration file includes username and password information for a connection to a database but the pair is stored in cleartext.

...<connectionStrings><add name="ud_DEV" connectionString="connectDB=uDB; uid=db2admin; pwd=password; dbalias=uDB;" providerName="System.Data.Odbc" /></connectionStrings>...

Username and password information should not be included in a configuration file or a properties file in cleartext as this will allow anyone who can read the file access to the resource. If possible, encrypt this information.

In 2022, the OT:ICEFALL study examined products by 10 different Operational Technology (OT) vendors. The researchers reported 56 vulnerabilities and said that the products were "insecure by design" [REF-1283]. If exploited, these vulnerabilities often allowed adversaries to change how the products operated, ranging from denial of service to changing the code that the products executed. Since these products were often used in industries such as power, electrical, water, and others, there could even be safety implications.
At least one OT product stored a password in plaintext.

In 2021, a web site operated by PeopleGIS stored data of US municipalities in Amazon Web Service (AWS) Simple Storage Service (S3) buckets.

A security researcher found 86 S3 buckets that could be accessed without authentication (CWE-306) and stored data unencrypted (CWE-312). These buckets exposed over 1000 GB of data and 1.6 million files including physical addresses, phone numbers, tax documents, pictures of driver's license IDs, etc. [REF-1296] [REF-1295]

While it was not publicly disclosed how the data was protected after discovery, multiple options could have been considered.

The sensitive information could have been protected by ensuring that the buckets did not have public read access, e.g., by enabling the s3-account-level-public-access-blocks-periodic rule to Block Public Access. In addition, the data could have been encrypted at rest using the appropriate S3 settings, e.g., by enabling server-side encryption using the s3-bucket-server-side-encryption-enabled setting. Other settings are available to further prevent bucket data from being leaked. [REF-1297]

Consider the following PowerShell command examples for encryption scopes of Azure storage objects. In the first example, an encryption scope is set for the storage account.

New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption

The result (edited and formatted for readability) might be:

ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount

Name
State
Source
RequireInfrastructureEncryption

testscope
Enabled
Microsoft.Storage

However, the empty string under RequireInfrastructureEncryption indicates this service was not enabled at the time of creation, because the -RequireInfrastructureEncryption argument was not specified in the command.
Including the -RequireInfrastructureEncryption argument addresses the issue:

New-AzStorageEncryptionScope -ResourceGroupName "MyResourceGroup" -AccountName "MyStorageAccount" -EncryptionScopeName testscope -StorageEncryption -RequireInfrastructureEncryption

This produces the report:

ResourceGroupName: MyResourceGroup, StorageAccountName: MyStorageAccount

Name
State
Source
RequireInfrastructureEncryption

testscope
Enabled
Microsoft.Keyvault
True

In a scenario where both software and hardware layer encryption is required ("double encryption"), Azure's infrastructure encryption setting can be enabled via the CLI or Portal. An important note is that infrastructure hardware encryption cannot be enabled or disabled after a blob is created. Furthermore, the default value for infrastructure encryption is disabled in blob creations.

CVE-2022-26390
wireless battery product stores credentials and Personal Health Information (PHI) without encryption
https://www.cve.org/CVERecord?id=CVE-2022-26390

CVE-2022-30275
Remote Terminal Unit (RTU) uses a driver that relies on a password stored in plaintext.
https://www.cve.org/CVERecord?id=CVE-2022-30275

CVE-2009-2272
password and username stored in cleartext in a cookie
https://www.cve.org/CVERecord?id=CVE-2009-2272

CVE-2009-1466
password stored in cleartext in a file with insecure permissions
https://www.cve.org/CVERecord?id=CVE-2009-1466

CVE-2009-0152
chat program disables SSL in some circumstances even when the user says to use SSL.
https://www.cve.org/CVERecord?id=CVE-2009-0152

CVE-2009-1603
Chain: product uses an incorrect public exponent when generating an RSA key, which effectively disables the encryption
https://www.cve.org/CVERecord?id=CVE-2009-1603

CVE-2009-0964
storage of unencrypted passwords in a database
https://www.cve.org/CVERecord?id=CVE-2009-0964

CVE-2008-6157
storage of unencrypted passwords in a database
https://www.cve.org/CVERecord?id=CVE-2008-6157

CVE-2008-6828
product stores a password in cleartext in memory
https://www.cve.org/CVERecord?id=CVE-2008-6828

CVE-2008-1567
storage of a secret key in cleartext in a temporary file
https://www.cve.org/CVERecord?id=CVE-2008-1567

CVE-2008-0174
SCADA product uses HTTP Basic Authentication, which is not encrypted
https://www.cve.org/CVERecord?id=CVE-2008-0174

CVE-2007-5778
login credentials stored unencrypted in a registry key
https://www.cve.org/CVERecord?id=CVE-2007-5778

CVE-2001-1481
Plaintext credentials in world-readable file.
https://www.cve.org/CVERecord?id=CVE-2001-1481

CVE-2005-1828
Password in cleartext in config file.
https://www.cve.org/CVERecord?id=CVE-2005-1828

CVE-2005-2209
Password in cleartext in config file.
https://www.cve.org/CVERecord?id=CVE-2005-2209

CVE-2002-1696
Decrypted copy of a message written to disk given a combination of options and when user replies to an encrypted message.
https://www.cve.org/CVERecord?id=CVE-2002-1696

CVE-2004-2397
Plaintext storage of private key and passphrase in log file when user imports the key.
https://www.cve.org/CVERecord?id=CVE-2004-2397

CVE-2002-1800
Admin password in plaintext in a cookie.
https://www.cve.org/CVERecord?id=CVE-2002-1800

CVE-2001-1537
Default configuration has cleartext usernames/passwords in cookie.
https://www.cve.org/CVERecord?id=CVE-2001-1537

CVE-2001-1536
Usernames/passwords in cleartext in cookies.
https://www.cve.org/CVERecord?id=CVE-2001-1536

CVE-2005-2160
Authentication information stored in cleartext in a cookie.
https://www.cve.org/CVERecord?id=CVE-2005-2160

Plaintext Storage of Sensitive Information

SFP23
Exposed Data

Part 4-2
Req CR 4.1 a)

Part 3-3
Req SR 4.1

Allowed
This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.

Different people use "cleartext" and "plaintext" to mean the same thing: the lack of encryption. However, within cryptography, these have more precise meanings. Plaintext is the information just before it is fed into a cryptographic algorithm, including already-encrypted text. Cleartext is any information that is unencrypted, although it might be in an encoded form that is not easily human-readable (such as base64 encoding).
When organizations adopt cloud services, it can be easier for attackers to access the data from anywhere on the Internet.

PLOVER
2006-07-19
Draft 3
2006-07-19

Eric Dalci
Cigital
2008-07-01
updated Time_of_Introduction

CWE Content Team
MITRE
2008-09-08
updated Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2009-01-12
updated Description, Name

CWE Content Team
MITRE
2010-02-16
updated References

CWE Content Team
MITRE
2010-06-21
updated Relationships

CWE Content Team
MITRE
2011-06-01
updated Common_Consequences

CWE Content Team
MITRE
2012-05-11
updated Common_Consequences, Demonstrative_Examples, Observed_Examples, References, Related_Attack_Patterns, Relationships

CWE Content Team
MITRE
2013-02-21
updated Applicable_Platforms, References

CWE Content Team
MITRE
2013-07-17
updated Description, Relationships, Terminology_Notes

CWE Content Team
MITRE
2014-07-30
updated Demonstrative_Examples, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2017-05-03
updated Related_Attack_Patterns

CWE Content Team
MITRE
2017-11-08
updated Modes_of_Introduction, References, Relationships

CWE Content Team
MITRE
2018-01-23
updated Abstraction, Relationships

CWE Content Team
MITRE
2018-03-27
updated References, Relationships, Type

CWE Content Team
MITRE
2019-06-20
updated Relationships, Type

CWE Content Team
MITRE
2020-02-24
updated Applicable_Platforms, Relationships

CWE Content Team
MITRE
2021-03-15
updated Demonstrative_Examples

CWE Content Team
MITRE
2021-10-28
updated Relationships

CWE Content Team
MITRE
2022-10-13
updated Applicable_Platforms, Demonstrative_Examples, Description, Observed_Examples, Potential_Mitigations, References

CWE Content Team
MITRE
2023-01-31
updated Applicable_Platforms, Demonstrative_Examples, Description, References, Relationships

CWE Content Team
MITRE
2023-04-27
updated Detection_Factors, References, Relationships, Taxonomy_Mappings

CWE Content Team
MITRE
2023-06-29
updated Mapping_Notes, Relationships

CWE Content Team
MITRE
2024-02-29
4.14
2024-02-29
updated Taxonomy_Mappings

CWE Content Team
MITRE
2025-04-03
4.17
2025-04-03
updated Common_Consequences, Description, Diagram, Other_Notes, Potential_Mitigations

CWE Content Team
MITRE
2025-12-11
4.19
2025-12-11
updated Observed_Examples, Relationships, Weakness_Ordinalities

"Mapping CWE to 62443" Sub-Working Group
CWE-CAPEC ICS/OT SIG
2023-04-25
Suggested mappings to ISA/IEC 62443.

Plaintext Storage of Sensitive Information