| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| XWiki Platform is a generic wiki platform. Starting in version 5.0-rc-1 and prior to versions 14.10.19, 15.5.4, and 15.9-rc-1, it is possible to access the hash of a password by using the diff feature of the history whenever the object storing the password is deleted. Using that vulnerability it's possible for an attacker to have access to the hash password of a user if they have rights to edit the users' page. With the default right scheme in XWiki this vulnerability is normally prevented on user profiles, except by users with Admin rights. Note that this vulnerability also impacts any extensions that might use passwords stored in xobjects: for those usecases it depends on the right of those pages. There is currently no way to be 100% sure that this vulnerability has been exploited, as an attacker with enough privilege could have deleted the revision where the xobject was deleted after rolling-back the deletion. But again, this operation requires high privileges on the target page (Admin right). A page with a user password xobject which have in its history a revision where the object has been deleted should be considered at risk and the password should be changed there. a diff, to ensure it's not coming from a password field. As another mitigation, admins should ensure that the user pages are properly protected: the edit right shouldn't be allowed for other users than Admin and owner of the profile (which is the default right). There is not much workaround possible for a privileged user other than upgrading XWiki. |
| RedTeam Pentesting discovered that the web interface of STARFACE as well as its REST API allows authentication using the SHA512 hash of the password instead of the cleartext password. While storing password hashes instead of cleartext passwords in an application's database generally has become best practice to protect users' passwords in case of a database compromise, this is rendered ineffective when allowing to authenticate using the password hash. |
| The default password hashing algorithm (PBKDF2-HMAC-SHA1) in Liferay Portal 7.2.0 through 7.4.3.15, and older unsupported versions, and Liferay DXP 7.4 before update 16, 7.3 before update 4, 7.2 before fix pack 17, and older unsupported versions defaults to a low work factor, which allows attackers to quickly crack password hashes. |
| The LMS5xx uses weak hash generation methods, resulting in the creation of insecure hashs. If an attacker manages to retrieve the hash, it could lead to collision attacks and the potential retrieval of the password. |
| Serverpod is an app and web server, built for the Flutter and Dart ecosystem. An issue was identified with the old password hash algorithm that made it susceptible to rainbow attacks if the database was compromised. This vulnerability is fixed by 1.2.6. |
|
Franklin Fueling System TS-550 versions prior to 1.9.23.8960 are vulnerable to attackers decoding admin credentials, resulting in unauthenticated access to the device.
|
| CryptoES is a cryptography algorithms library compatible with ES6 and TypeScript. Prior to version 2.1.0, CryptoES PBKDF2 is 1,000 times weaker than originally specified in 1993, and at least 1,300,000 times weaker than current industry standard. This is because it both defaults to SHA1, a cryptographic hash algorithm considered insecure since at least 2005, and defaults to one single iteration, a 'strength' or 'difficulty' value specified at 1,000 when specified in 1993. PBKDF2 relies on iteration count as a countermeasure to preimage and collision attacks. If used to protect passwords, the impact is high. If used to generate signatures, the impact is high. Version 2.1.0 contains a patch for this issue. As a workaround, configure CryptoES to use SHA256 with at least 250,000 iterations. |
| Buttercup v2.20.3 allows attackers to obtain the hash of the master password for the password manager via accessing the file /vaults.json/ |
|
PiiGAB M-Bus stores passwords using a weak hash algorithm.
|
| In PHP 8.0.X before 8.0.28, 8.1.X before 8.1.16 and 8.2.X before 8.2.3, password_verify() function may accept some invalid Blowfish hashes as valid. If such invalid hash ever ends up in the password database, it may lead to an application allowing any password for this entry as valid.
|
| Vulnerability in ekorCCP and ekorRCI that could allow an attacker with access to the network where the device is located to decrypt the credentials of privileged users, and subsequently gain access to the system to perform malicious actions. |
|
The application was vulnerable to an authenticated information disclosure, allowing administrators to view unsalted user passwords, which could lead to the compromise of plaintext passwords via offline attacks.
|
| Inoda OnTrack v3.4 employs a weak password policy which allows attackers to potentially gain unauthorized access to the application via brute-force attacks. Additionally, user passwords are hashed without a salt or pepper making it much easier for tools like hashcat to crack the hashes. |
| Bminusl IHateToBudget v1.5.7 employs a weak password policy which allows attackers to potentially gain unauthorized access to the application via brute-force attacks. Additionally, user passwords are hashed without a salt or pepper making it much easier for tools like hashcat to crack the hashes. |
| An access control issue in ICT Protege GX/WX 2.08 allows attackers to leak SHA1 password hashes of other users. |
| A use of password hash with insufficient computational effort vulnerability [CWE-916] in FortiSandbox before 4.2.0 may allow an attacker with access to the password database to efficiently mount bulk guessing attacks to recover the passwords. |
| A vulnerability has been identified in Desigo DXR2 (All versions < V01.21.142.5-22), Desigo PXC3 (All versions < V01.21.142.4-18), Desigo PXC4 (All versions < V02.20.142.10-10884), Desigo PXC5 (All versions < V02.20.142.10-10884). The web application stores the PBKDF2 derived key of users passwords with a low iteration count. An attacker with user profile access privilege can retrieve the stored password hashes of other accounts and then successfully perform an offline cracking attack and recover the plaintext passwords of other users. |
| BigAnt Software BigAnt Server v5.6.06 was discovered to utilize weak password hashes. |
| Weak secrethash can be brute-forced in GitHub repository livehelperchat/livehelperchat prior to 3.96. |
| Usage of a weak cryptographic algorithm in Palo Alto Networks PAN-OS software where the password hashes of administrator and local user accounts are not created with a sufficient level of computational effort, which allows for password cracking attacks on accounts in normal (non-FIPS-CC) operational mode. An attacker must have access to the account password hashes to take advantage of this weakness and can acquire those hashes if they are able to gain access to the PAN-OS software configuration. Fixed versions of PAN-OS software use a secure cryptographic algorithm for account password hashes. This issue does not impact Prisma Access firewalls. This issue impacts: PAN-OS 8.1 versions earlier than PAN-OS 8.1.21; All versions of PAN-OS 9.0; PAN-OS 9.1 versions earlier than PAN-OS 9.1.11; PAN-OS 10.0 versions earlier than PAN-OS 10.0.7. |
