Threats Tagged 'cwe-328'

motionEye (mEye) is an online interface for a piece of software called "motion," which is a video surveillance program with motion detection. Prior to 0.44.0, motionEye accepts the client-controlled meye_username and meye_password_hash cookies as authentication material without server-side session validation. An unauthenticated attacker who knows a target username and corresponding hash can set the cookies manually or cause them to be loaded by submitting blank credentials through the switch-user authentication flow, after which the server authenticates the attacker as that user. The administrator username and password-hash value are stored in /etc/motioneye/motion.conf, which is globally readable by default, allowing a local shell user to obtain reusable administrator credential material. Successful impersonation can enable account lockout, password changes and persistence, data enumeration, data destruction, and data exfiltration. This issue is fixed in version 0.44.0.

R-SOFT DMS stores superadmin credentials using a non-salted nested MD5 hash. This allows an attacker who obtain password hash to decode superadmin credentials. Critically, this password cannot be changed except by modifying the configuration file. This issue was fixed in version v3.17-2000.

The Control-M/Enterprise Manager uses weak protections for stored hashes of account passwords, potentially allowing offline password recovery attacks if credential data is obtained by an attacker. This vulnerability affects Control-M/Enterprise Manager unsupported versions 9.0.20.x and potentially earlier unsupported versions

Redeight CMS version 1.0 uses the MD5 algorithm without a salt to store user passwords. Because MD5 is a cryptographically broken algorithm and lacks salting, attackers who obtain the password hashes can trivially reverse them using rainbow tables, leading to the exposure of plaintext credentials.

phpMyFAQ versions prior to 4.1.4 use SHA-1, a cryptographically broken hash algorithm, for hashing attachment passwords. SHA-1 has been vulnerable to collision attacks since 2017. This weakness was addressed in version 4.1.4.

Version 3.0.7 of the Securly Chrome Extension uses deprecated SHA-1 hashing for IWF CSAM URL matching (25,020 hashes) and CIPA blocklist matching (12,352 hashes).

CVE-2026-45413 affects MaxKB versions prior to 2.9.1, where user passwords are stored using unsalted MD5 hashes. This weak hashing method makes password hashes trivially crackable using rainbow tables or GPU-accelerated brute force tools. The vulnerability is fixed in version 2.9.1. The CVSS 4.0 score is 6.9, indicating a medium severity risk primarily due to local attack vector and no required privileges or user interaction.

Next.js is a React framework for building full-stack web applications. From 13.4.6 to before 15.5.16 and 16.2.5, React Server Component responses can be vulnerable to cache poisoning in deployments that rely on shared caches with insufficient response partitioning. In affected conditions, collisions in the _rsc cache-busting value can allow an attacker to poison cache entries so users receive the wrong response variant for a given URL. This vulnerability is fixed in 15.5.16 and 16.2.5.

Sandboxie-Plus versions 1.17.2 and earlier contain a weakness in the password hashing implementation where the SHA-1 digest is incorrectly converted to hexadecimal, reducing the effective entropy of stored password hashes from 160 bits to 80 bits. This issue is compounded by the use of an unsalted SHA-1 hash. The vulnerability makes brute-forcing leaked or backed-up password hashes easier. The issue has been fixed in version 1.17.3. The CVSS score is low, reflecting limited impact and exploitability.

jq is a command-line JSON processor. Before commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784, jq used MurmurHash3 with a hardcoded, publicly visible seed (0x432A9843) for all JSON object hash table operations, which allowed an attacker to precompute key collisions offline. By supplying a crafted JSON object (~100 KB) where all keys hashed to the same bucket, hash table lookups degraded from O(1) to O(n), turning any jq expression into an O(n²) operation and causing significant CPU exhaustion. This affected common jq use cases such as CI/CD pipelines, web services, and data processing scripts, and was far more practical to exploit than existing heap overflow issues since it required only a small payload. This issue has been patched in commit 0c7d133c3c7e37c00b6d46b658a02244fdd3c784.