Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact secretKey, an important key for HMAC SHA256 authentication, was stored in the database in raw form. If a malicious person somehow had access to the data in the database, they could use the key and secretKey for HMAC SHA256 authentication to send requests impersonating that person. Patches Upgrade to Shield v1.0.0-beta.8 or later. After upgrading, all existing secret keys must be encrypted. See https://github.com/codeigniter4/shield/blob/develop/UPGRADING.md for details. Workarounds None. References - https://codeigniter4.github.io/shield/references/authentication/hmac/ For more information If you have any questions or comments about this advisory: Open an issue or discussion in codeigniter4/shield Email us at security@codeigniter.com
Recommended action: Upgrade to 1.0.0-beta.8 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact If successful login attempts are recorded, the raw tokens are stored in the log table. If a malicious person somehow views the data in the log table, he or she can obtain a raw token, which can then be used to send a request with that user's authority. When you (1) use the following authentiactors, - AccessTokens (tokens) - JWT (jwt) - HmacSha256 (hmac) and you (2) log successful login attempts, the raw tokens are stored. Patches Upgrade to Shield v1.0.0-beta.8 or later. Workarounds Disable logging for successful login attempts by the configuration files. - AccessTokens or HmacSha256 - Set Config\AuthToken::$recordLoginAttempt to Auth::RECORDLOGINATTEMPTFAILURE or Auth::RECORDLOGINATTEMPTNONE - JWT - Set Config\AuthJWT::$recordLoginAttempt to Auth::RECORDLOGINATTEMPTFAILURE or Auth::RECORDLOGINATTEMPTNONE References - https://codeigniter4.github.io/shield/gettingstarted/authenticators/ For more information If you have any questions or comments about this advisory: Open an…
Recommended action: Upgrade to 1.0.0-beta.8 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An improper implementation was found in the password storage process. All hashed passwords stored in Shield v1.0.0-beta.3 or earlier are easier to crack than expected due to the vulnerability. Therefore, they should be removed as soon as possible. If an attacker gets (1) the user's hashed password by Shield, and (2) the hashed password (SHA-384 hash without salt) from somewhere, the attacker may easily crack the user's password. Patches Upgrade to Shield v1.0.0-beta.4 or later. After upgrading, all users’ hashed passwords should be updated (saved to the database). See https://github.com/codeigniter4/shield/blob/develop/UPGRADING.md for details. Workarounds None. References - https://cheatsheetseries.owasp.org/cheatsheets/PasswordStorageCheatSheet.html#pre-hashing-passwords - https://blog.ircmaxell.com/2015/03/security-issue-combining-bcrypt-with.html - https://www.scottbrady91.com/authentication/beware-of-password-shucking For more information If you have any questions or…
Recommended action: Upgrade to 1.0.0-beta.4 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact This vulnerability may allow SameSite Attackers to bypass the CodeIgniter4 CSRF protection mechanism with CodeIgniter Shield. For this attack to succeed, the attacker must have direct (or indirect, e.g., XSS) control over a subdomain site (e.g., https://a.example.com/) of the target site (e.g., http://example.com/). This vulnerability exists whether Config\Security::$csrfProtection is 'cookie' or 'session'. It is also exploitable whether Config\Security::$regenerate is true or false. Patches Upgrade to CodeIgniter v4.2.3 or later and Shield v1.0.0-beta.2 or later. Workarounds Do all of the following: - set Config\Security::$csrfProtection to 'session' - remove old session data right after login (immediately after ID and password match) - regenerate CSRF token right after login (immediately after ID and password match) References - CodeIgniter4 CSRF Protection - SameSite Attacks - SameSite Cookies - The great SameSite confusion For more information If you have any questions or…
Recommended action: Upgrade to 1.0.0-beta.2 (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.