ghsa

Python Packaging Authority (PyPA)'s setuptools is a library designed to facilitate packaging Python projects. Setuptools version 65.5.0 and earlier could allow remote attackers to cause a denial of service by fetching malicious HTML from a PyPI package or custom PackageIndex page due to a vulnerable Regular Expression in `package_index`. This has been patched in version 65.5.1.

Python Packaging Authority (PyPA) Wheel is a reference implementation of the Python wheel packaging standard. Wheel 0.37.1 and earlier are vulnerable to a Regular Expression denial of service via attacker controlled input to the wheel cli. The vulnerable regex is used to verify the validity of Wheel file names. This has been patched in version 0.38.1.

### Impact The filesystem glob pattern wildcards `*`, `?`, and `[...]` match file path literals and leading dots by default, which unintentionally exposes sub folder content of allowed paths. Example: The `fs` scope `$HOME/*.key` would also allow `$HOME/.ssh/secret.key` to be read even though it is in a sub directory of `$HOME` and is inside a hidden folder. Scopes without the wildcards are not affected. As `**` allows for sub directories the behavior there is also as expected. ### Patches The issue has been patched in the latest release and was backported into the currently supported 1.x branches. ### Workarounds No workaround is known at the time of publication. ### References The original report contained information that the `dialog.open` component automatically allows one sub directory to be read, regardless of the `recursive` option. Imagine a file system looking like ``` o ../ o documents/ - file.txt - deeper/ o deep_file.txt ``` Reproduction steps: ...

### Impact When an application uses (1) multiple session cookies (e.g., one for user pages and one for admin pages) and (2) a session handler is set to `DatabaseHandler`, `MemcachedHandler`, or `RedisHandler`, then if an attacker gets one session cookie (e.g., one for user pages), they may be able to access pages that require another session cookie (e.g., for admin pages). ### Patches Upgrade to v4.2.11 or later. ### Workarounds - Use only one session cookie. ### References - https://codeigniter4.github.io/userguide/libraries/sessions.html#session-drivers ### For more information If you have any questions or comments about this advisory: * Open an issue in [codeigniter4/CodeIgniter4](https://github.com/codeigniter4/CodeIgniter4/issues) * Email us at [SECURITY.md](https://github.com/codeigniter4/CodeIgniter4/blob/develop/SECURITY.md)

### Impact This vulnerability may allow attackers to spoof their IP address when your server is behind a reverse proxy. ### Patches Upgrade to v4.2.11 or later, and configure `Config\App::$proxyIPs`. ### Workarounds Do not use `$request->getIPAddress()`. ### References - https://codeigniter4.github.io/userguide/incoming/request.html#CodeIgniter\HTTP\Request::getIPAddress ### For more information If you have any questions or comments about this advisory: * Open an issue in [codeigniter4/CodeIgniter4](https://github.com/codeigniter4/CodeIgniter4/issues) * Email us at [SECURITY.md](https://github.com/codeigniter4/CodeIgniter4/blob/develop/SECURITY.md)

A vulnerability was found in ahorner text-helpers 1.1.0/1.1.1. It has been declared as critical. This vulnerability affects unknown code of the file lib/text_helpers/translation.rb. The manipulation of the argument link leads to use of web link to untrusted target with window.opener access. The attack can be initiated remotely. Upgrading to version 1.2.0 can address this issue. The name of the patch is 184b60ded0e43c985788582aca2d1e746f9405a3. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-216520.

Apache ShardingSphere-Proxy prior to 5.3.0 when using MySQL as database backend didn't cleanup the database session completely after client authentication failed, which allowed an attacker to execute normal commands by constructing a special MySQL client. This vulnerability has been fixed in Apache ShardingSphere 5.3.0.

The package liquidjs before 10.0.0 is vulnerable to Information Exposure when `ownPropertyOnly` parameter is set to `False`, which results in leaking properties of a prototype. Workaround For versions 9.34.0 and higher, an option to disable this functionality is provided.

# Overview Versions `<=8.5.1` of `jsonwebtoken` library can be misconfigured so that passing a poorly implemented key retrieval function (referring to the `secretOrPublicKey` argument from the [readme link](https://github.com/auth0/node-jsonwebtoken#jwtverifytoken-secretorpublickey-options-callback)) will result in incorrect verification of tokens. There is a possibility of using a different algorithm and key combination in verification than the one that was used to sign the tokens. Specifically, tokens signed with an asymmetric public key could be verified with a symmetric HS256 algorithm. This can lead to successful validation of forged tokens. # Am I affected? You will be affected if your application is supporting usage of both symmetric key and asymmetric key in jwt.verify() implementation with the same key retrieval function. # How do I fix it? Update to version 9.0.0 # Will the fix impact my users? There is no impact for end users

# Overview In versions `<=8.5.1` of `jsonwebtoken` library, lack of algorithm definition in the `jwt.verify()` function can lead to signature validation bypass due to defaulting to the `none` algorithm for signature verification. # Am I affected? You will be affected if you do not specify algorithms in the `jwt.verify()` function # How do I fix it? Update to version 9.0.0 which removes the default support for the none algorithm in the `jwt.verify()` method. # Will the fix impact my users? There will be no impact, if you update to version 9.0.0 and you don’t need to allow for the `none` algorithm. If you need 'none' algorithm, you have to explicitly specify that in `jwt.verify()` options.