Etherpad <1.8.3 stored passwords used by users insecurely in the database and in log files. This affects every database backend supported by Etherpad.

An issue was discovered in Xuperchain 3.6.0 that allows for attackers to recover any arbitrary users' private key after obtaining the partial signature in multisignature.

Incorrect Access Control in Autumn v1.0.4 and earlier allows remote attackers to obtain clear-text login credentials via the component "autumn-cms/user/getAllUser/?page=1&limit=10".

An information disclosure vulnerability exists in the EPA protocol of Dut Computer Control Engineering Co.'s PLC MAC1100.

django-celery-results through 1.2.1 stores task results in the database. Among the data it stores are the variables passed into the tasks. The variables may contain sensitive cleartext information that does not belong unencrypted in the database.

A cleartext storage of sensitive information in GUI in FortiADC versions 5.4.3 and below, 6.0.0 and below may allow a remote authenticated attacker to retrieve some sensitive information such as users LDAP passwords and RADIUS shared secret by deobfuscating the passwords entry fields.

A vulnerability has been identified in Spectrum Power 4 (All versions < V4.70 SP8). Insecure storage of sensitive information in the configuration files could allow the retrieval of user names.

An issue was discovered on Nescomed Multipara Monitor M1000 devices. The onboard Flash memory stores data in cleartext, without integrity protection against tampering.

An issue was discovered on Nescomed Multipara Monitor M1000 devices. The internal storage of the underlying Linux system stores data in cleartext, without integrity protection against tampering.

Brocade SANNav before version 2.1.1 contains an information disclosure vulnerability. Successful exploitation of internal server information in the initial login response header.

Zyxel CloudCNM SecuManager 3.1.0 and 3.1.1 has weak /opt/axess/etc/default/axess permissions.

Zyxel CloudCNM SecuManager 3.1.0 and 3.1.1 has a hardcoded Erlang cookie for ejabberd replication.

In Django Two-Factor Authentication, user passwords are stored in clear text in the Django session

Django Two-Factor Authentication before 1.12, stores the user's password in clear text in the user session (base64-encoded). The password is stored in the session when the user submits their username and password, and is removed once they complete authentication by entering a two-factor authentication code. This means that the password is stored in clear text in the session for an arbitrary amount of time, and potentially forever if the user begins the login process by entering their username and password and then leaves before entering their two-factor authentication code. The severity of this issue depends on which type of session storage you have configured: in the worst case, if you're using Django's default database session storage, then users' passwords are stored in clear text in your database. In the best case, if you're using Django's signed cookie session, then users' passwords are only stored in clear text within their browser's cookie store. In the common case of using Django's cache session store, the users' passwords are stored in clear text in whatever cache storage you have configured (typically Memcached or Redis). This has been fixed in 1.12. After upgrading, users should be sure to delete any clear text passwords that have been stored. For example, if you're using the database session backend, you'll likely want to delete any session record from the database and purge that data from any database backups or replicas. In addition, affected organizations who have suffered a database breach while using an affected version should inform their users that their clear text passwords have been compromised. All organizations should encourage users whose passwords were insecurely stored to change these passwords on any sites where they were used. As a workaround, wwitching Django's session storage to use signed cookies instead of the database or cache lessens the impact of this issue, but should not be done without a thorough understanding of the security tradeoffs of using signed cookies rather than a server-side session storage. There is no way to fully mitigate the issue without upgrading.

Client caching login operation with plaintext password in Saleor Storefront

In Saleor Storefront before version 2.10.3, request data used to authenticate customers was inadvertently cached in the browser's local storage mechanism, including credentials. A malicious user with direct access to the browser could extract the email and password. In versions prior to 2.10.0 persisted the cache even after the user logged out. This is fixed in version 2.10.3. A workaround is to manually clear application data (browser's local storage) after logging into Saleor Storefront.

An issue was discovered in Navigate CMS 2.9 r1433. Sessions, as well as associated information such as CSRF tokens, are stored in cleartext files in the directory /private/sessions. An unauthenticated user could use a brute-force approach to attempt to identify existing sessions, or view the contents of this file to discover details about a session.

D-Link DIR-865L Ax 1.20B01 Beta devices have Cleartext Storage of Sensitive Information.

An issue was discovered in the stashcat app through 3.9.2 for macOS, Windows, Android, iOS, and possibly other platforms. It stores the client_key, the device_id, and the public key for end-to-end encryption in cleartext, enabling an attacker (by copying or having access to the local storage database file) to login to the system from any other computer, and get unlimited access to all data in the users's context.

NCH Express Accounts 8.24 and earlier allows local users to discover the cleartext password by reading the configuration file.

Unnecessary fields in the OpenTrace/BlueTrace protocol in COVIDSafe through v1.0.17 allow a remote attacker to identify a device model by observing cleartext payload data. This allows re-identification of devices, especially less common phone models or those in low-density situations.

Crash-recovered MSOffice encrypted documents defaulted to not to using encryption on next save

If LibreOffice has an encrypted document open and crashes, that document is auto-saved encrypted. On restart, LibreOffice offers to restore the document and prompts for the password to decrypt it. If the recovery is successful, and if the file format of the recovered document was not LibreOffice's default ODF file format, then affected versions of LibreOffice default that subsequent saves of the document are unencrypted. This may lead to a user accidentally saving a MSOffice file format document unencrypted while believing it to be encrypted. This issue affects: LibreOffice 6-3 series versions prior to 6.3.6; 6-4 series versions prior to 6.4.3.