ghsa

### 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/Password_Storage_Cheat_Sheet.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 yo...

`Out::from_raw` in affected versions allows writing a value to invalid memory address without requiring `unsafe`. The soundness issue has been addressed by making `Out::from_raw` an unsafe function.

### Impact This action uses the `github.head_ref` parameter in an insecure way. This vulnerability can be triggered by any user on GitHub on any workflow using the action on pull requests. They just need to create a pull request with a branch name, which can contain the attack payload. (Note that first-time PR requests will not be run - but the attacker can submit a valid PR before submitting an invalid PR). This can be used to execute code on the GitHub runners (potentially use it for crypto-mining, and waste your resources) and to exfiltrate any secrets you use in the CI pipeline. ### Patches > Pass the variable as an environment variable and then use the environment variable instead of substituting it directly. Patched action is available on tag **v4**, tag **v4.4.1**, and any tag beyond. ### Workarounds No workaround is available if impacted, please upgrade the version > ℹ️ **v3** and **v4** are compatibles. ### References [Here](https://securitylab.github.com/research/...

### Impact Due to the underlying implementation of `.ToString()`, it's possible to execute arbitrary JavaScript, or to achieve a denial-of-service, if a binding parameter is a crafted Object. Users of `sqlite3` v5.0.0 - v5.1.4 are affected by this. ### Patches Fixed in v5.1.5. All users are recommended to upgrade to v5.1.5 or later. ### Workarounds * Ensure there is sufficient sanitization in the parent application to protect against invalid values being supplied to binding parameters. ### References * Commit: https://github.com/TryGhost/node-sqlite3/commit/edb1934dd222ae55632e120d8f64552d5191c781 ### For more information If you have any questions or comments about this advisory: * Email us at [[email protected]](mailto:[email protected]) Credits: Dave McDaniel of Cisco Talos

Code Injection in GitHub repository alextselegidis/easyappointments prior to 1.5.0 due to unescaped output.

Webpack 5 before 5.76.0 does not avoid cross-realm object access. ImportParserPlugin.js mishandles the magic comment feature. An attacker who controls a property of an untrusted object can obtain access to the real global object.

Users with the Company admin role (introduced by the company account feature in v4) can assign any role to any user. This also applies to any other user that has the role / assign policy. Any subtree limitation in place does not have any effect. The role / assign policy is typically only given to administrators, which limits the scope in most cases, but please verify who has this policy in your installaton. The fix ensures that subtree limitations are working as intended.

## Impact In file upload it is possible by certain means to upload files like .html and .js. These may contain XSS exploits which will be run when links to them are accessed by victims. Patches ## Patches The fix consists simply of adding common types of scriptable file types to the configuration of the already existing filetype blacklist feature. See "Patched versions". As such, this can also be done manually, without installing the patched versions. This may be relevant if you are currently running a considerably older version of the kernel package and don't want to upgrade it at this time. Please see the settting "ezsettings.default.io.file_storage.file_type_blacklist" at: https://github.com/ezsystems/ezplatform-kernel/blob/master/eZ/Bundle/EzPublishCoreBundle/Resources/config/default_settings.yml#L109 Important note ## Important note You should adapt this setting to your needs. Do not add file types to the blacklist that you actually need to be able to upload. For instance, if...

Ibexa DXP is using random execution time to hinder timing attacks against user accounts, a method of discovering whether a given account exists in a system without knowing its password, thus affecting privacy. This implementation was found to not be good enough in some situations. The fix replaces this with constant time functionality, configured in the new security.yml parameter 'ibexa.security.authentication.constant_auth_time'. It will log a warning if the constant time is exceeded. If this happens the setting should be increased.

This Security Advisory is about a vulnerability in eZ Platform v1.13, v2.5, and v3.2, and in Ibexa DXP and Ibexa Open Source v3.3. The /user/sessions endpoint can let an attacker detect if a given username or email refers to a valid account. This can be detected through differences in the response data or response time of certain requests. The fix ensures neither attack is possible. The fix is distributed via Composer.