Total
532 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2020-4619 | 1 Ibm | 1 Data Risk Manager | 2020-09-22 | 4.0 MEDIUM | 6.5 MEDIUM |
| IBM Data Risk Manager (iDNA) 2.0.6 stores user credentials in plain in clear text which can be read by an authenticated user. IBM X-Force ID: 184976. | |||||
| CVE-2018-18984 | 1 Medtronic | 6 29901 Encore Programmer, 29901 Encore Programmer Firmware, Carelink 2090 Programmer and 3 more | 2020-09-18 | 2.1 LOW | 4.6 MEDIUM |
| Medtronic CareLink 2090 Programmer CareLink 9790 Programmer 29901 Encore Programmer, all versions, The affected products do not encrypt or do not sufficiently encrypt the following sensitive information while at rest PII and PHI. | |||||
| CVE-2018-19009 | 1 Pilz | 1 Pnozmulti Configurator | 2020-09-18 | 2.1 LOW | 7.8 HIGH |
| Pilz PNOZmulti Configurator prior to version 10.9 allows an authenticated attacker with local access to the system containing the PNOZmulti Configurator software to view sensitive credential data in clear-text. This sensitive data is applicable to only the PMI m107 diag HMI device. An attacker with access to this sensitive data and physical access to the PMI m107 diag can modify data on the HMI device. | |||||
| CVE-2020-15784 | 1 Siemens | 1 Spectrum Power 4 | 2020-09-14 | 5.0 MEDIUM | 5.3 MEDIUM |
| 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. | |||||
| CVE-2020-15484 | 1 Niscomed | 2 M1000 Multipara Patient Monitor, M1000 Multipara Patient Monitor Firmware | 2020-08-31 | 5.0 MEDIUM | 7.5 HIGH |
| 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. | |||||
| CVE-2019-9873 | 1 Jetbrains | 1 Intellij Idea | 2020-08-24 | 5.0 MEDIUM | 9.8 CRITICAL |
| In several versions of JetBrains IntelliJ IDEA Ultimate, creating Task Servers configurations leads to saving a cleartext unencrypted record of the server credentials in the IDE configuration files. The issue has been fixed in the following versions: 2019.1, 2018.3.5, 2018.2.8, and 2018.1.8. | |||||
| CVE-2019-9872 | 1 Jetbrains | 1 Intellij Idea | 2020-08-24 | 4.3 MEDIUM | 8.1 HIGH |
| In several versions of JetBrains IntelliJ IDEA Ultimate, creating run configurations for cloud application servers leads to saving a cleartext unencrypted record of the server credentials in the IDE configuration files. If the Settings Repository plugin was then used and configured to synchronize IDE settings using a public repository, these credentials were published to this repository. The issue has been fixed in the following versions: 2019.1, 2018.3.5, 2018.2.8, and 2018.1.8. | |||||
| CVE-2019-11966 | 1 Hp | 1 Intelligent Management Center | 2020-08-24 | 9.0 HIGH | 8.8 HIGH |
| A remote privilege escalation vulnerability was identified in HPE Intelligent Management Center (IMC) PLAT earlier than version 7.3 E0506P09. | |||||
| CVE-2019-13096 | 1 Tronlink | 1 Wallet | 2020-08-24 | 5.0 MEDIUM | 9.8 CRITICAL |
| TronLink Wallet 2.2.0 stores user wallet keystore in plaintext and places them in insecure storage. An attacker can read and reuse the user keystore of a valid user via /data/data/com.tronlink.wallet/shared_prefs/<wallet-name>.xml to gain unauthorized access. | |||||
| CVE-2019-13099 | 1 Momo Project | 1 Momo | 2020-08-24 | 4.0 MEDIUM | 6.5 MEDIUM |
| The Momo application 2.1.9 for Android stores confidential information insecurely on the system (i.e., in cleartext), which allows a non-root user to find out the username/password of a valid user and a user's access token via Logcat. | |||||
| CVE-2019-0285 | 1 Sap | 1 Crystal Reports | 2020-08-24 | 5.0 MEDIUM | 9.8 CRITICAL |
| The .NET SDK WebForm Viewer in SAP Crystal Reports for Visual Studio (fixed in version 2010) discloses sensitive database information including credentials which can be misused by the attacker. | |||||
| CVE-2018-12572 | 1 Avast | 1 Free Antivirus | 2020-08-24 | 2.1 LOW | 7.8 HIGH |
| Avast Free Antivirus prior to 19.1.2360 stores user credentials in memory upon login, which allows local users to obtain sensitive information by dumping AvastUI.exe application memory and parsing the data. | |||||
| CVE-2019-13100 | 1 Send-anywhere | 1 Send Anywhere | 2020-08-24 | 4.0 MEDIUM | 6.5 MEDIUM |
| The Send Anywhere application 9.4.18 for Android stores confidential information insecurely on the system (i.e., in cleartext), which allows a non-root user to find out the username/password of a valid user via /data/data/com.estmob.android.sendanywhere/shared_prefs/sendanywhere_device.xml. | |||||
| CVE-2019-9823 | 1 Jetbrains | 1 Intellij Idea | 2020-08-24 | 5.0 MEDIUM | 9.8 CRITICAL |
| In several JetBrains IntelliJ IDEA versions, creating remote run configurations of JavaEE application servers leads to saving a cleartext record of the server credentials in the IDE configuration files. The issue has been fixed in the following versions: 2018.3.5, 2018.2.8, 2018.1.8. | |||||
| CVE-2019-11384 | 1 Zalora | 1 Zalora | 2020-08-24 | 5.0 MEDIUM | 9.8 CRITICAL |
| The Zalora application 6.15.1 for Android stores confidential information insecurely on the system (i.e. plain text), which allows a non-root user to find out the username/password of a valid user via /data/data/com.zalora.android/shared_prefs/login_data.xml. | |||||
| CVE-2020-17495 | 1 Django-celery-results Project | 1 Django-celery-results | 2020-08-14 | 5.0 MEDIUM | 7.5 HIGH |
| 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. | |||||
| CVE-2020-15085 | 1 Mirumee | 1 Saleor | 2020-07-28 | 2.1 LOW | 6.1 MEDIUM |
| 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. | |||||
| CVE-2020-7517 | 1 Schneider-electric | 1 Easergy Builder | 2020-07-27 | 2.1 LOW | 5.5 MEDIUM |
| A CWE-312: Cleartext Storage of Sensitive Information vulnerability exists in Easergy Builder (Version 1.4.7.2 and older) which could allow an attacker to read user credentials. | |||||
| CVE-2020-4369 | 1 Ibm | 1 Verify Gateway | 2020-07-24 | 2.1 LOW | 5.5 MEDIUM |
| IBM Verify Gateway (IVG) 1.0.0 and 1.0.1 stores highly sensitive information in cleartext that could be obtained by a user. IBM X-Force ID: 179004. | |||||
| CVE-2020-15105 | 1 Django Two-factor Authentication Project | 1 Django Two-factor Authentication | 2020-07-21 | 3.6 LOW | 5.4 MEDIUM |
| 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. | |||||