ghsa

### GraphQL behaviour Nested fragment in GraphQL might be quite hard to handle depending on the implementation language. Some language support natively a max recursion depth. However, on most compiled languages, you should add a threshold of recursion. ```graphql # Infinite loop example query { ...a } fragment a on Query { ...b } fragment b on Query { ...a } ``` ### POC TLDR With max_size being the number of nested fragment generated. At max_size=7500, it should instantly raise:  However, with a lower size, you will overflow the memory after some iterations. ### Reproduction steps (Juniper) ``` git clone https://github.com/graphql-rust/juniper.git cd juniper ``` Save this POC as poc.py ```python import requests import time import json from itertools import permutations print('=== Fragments POC ===') url = 'http://localhost:8080/graphql' max_size = 7500 perms = [''.join(p) for p in permutations('abcefghijk')] perms = perms[:m...

### Impact An authenticated Admin user could craft HTTP requests to filter users by their salted and hashed passwords strings. These filters could be made by using partial hashed password strings. The response would not include the hashed passwords, but an attacker could infer partial password hashes and their respective users. Only when using `AUTH_DB` database authentication option. ### Patches Fixed on 4.1.3 ### For more information If you have any questions or comments about this advisory: * Open an issue in [example link to repo](http://example.com) * Email us at [example email address](mailto:example@example.com)

### Impact Eval injection possible if the shop is vulnerable to an SQL injection. ### Patches The problem is fixed in version 1.7.8.7 ### Workarounds Delete the MySQL Smarty cache feature by removing these lines in the file `config/smarty.config.inc.php` lines 43-46 (PrestaShop 1.7) or 40-43 (PrestaShop 1.6): ```php if (Configuration::get('PS_SMARTY_CACHING_TYPE') == 'mysql') { include _PS_CLASS_DIR_.'Smarty/SmartyCacheResourceMysql.php'; $smarty->caching_type = 'mysql'; } ```

### Impact When the [built-in HTTP proxy downloader middleware](https://docs.scrapy.org/en/2.6/topics/downloader-middleware.html#module-scrapy.downloadermiddlewares.httpproxy) processes a request with `proxy` metadata, and that `proxy` metadata includes proxy credentials, the built-in HTTP proxy downloader middleware sets the `Proxy-Authentication` header, but only if that header is not already set. There are third-party proxy-rotation downloader middlewares that set different `proxy` metadata every time they process a request. Because of request retries and redirects, the same request can be processed by downloader middlewares more than once, including both the built-in HTTP proxy downloader middleware and any third-party proxy-rotation downloader middleware. These third-party proxy-rotation downloader middlewares could change the `proxy` metadata of a request to a new value, but fail to remove the `Proxy-Authentication` header from the previous value of the `proxy` metadata, caus...

### Impact mezzio-swoole applications using Diactoros for their PSR-7 implementation, and which are either not behind a proxy, or can be accessed via untrusted proxies, can potentially have the host, protocol, and/or port of a `Laminas\Diactoros\Uri` instance associated with the incoming server request modified to reflect values from `X-Forwarded-*` headers. Such changes can potentially lead to XSS attacks (if a fully-qualified URL is used in links) and/or URL poisoning. ### Patches 3.7.0, and 4.3.0 and later. The patches present in these versions update the `SwooleServerRequestFactory` to filter out `X-Forwarded-*` headers when creating the initial request. They then by default pass that instance through a `Laminas\Diactoros\ServerRequestFilter\FilterUsingXForwardedHeaders` instance created from the `trustReservedSubnet()` constructor, ensuring that the request only honors the `X-Forwarded-*` headers for private reserved subnets. Users can define the `Laminas\Diactoros\ServerRequ...

### Impact When establishing a server-mode `TLSSocket` using `fs2-io` on Node.js, the parameter `requestCert = true` is ignored, peer certificate verification is skipped, and the connection proceeds. The vulnerability is limited to: 1. `fs2-io` running on Node.js. The JVM TLS implementation is completely independent. 2. `TLSSocket`s in server-mode. Client-mode `TLSSocket`s are implemented via a different API. 3. mTLS as enabled via `requestCert = true` in `TLSParameters`. The default setting is `false` for server-mode `TLSSocket`s. It was introduced with the initial Node.js implementation of fs2-io in v3.1.0. ### Patches A patch is released in v3.2.11. The `requestCert = true` parameter is respected and the peer certificate is verified. If verification fails, a `SSLException` is raised. ### Workarounds If using an unpatched version on Node.js, do not use a server-mode `TLSSocket` with `requestCert = true` to establish a mTLS connection. ### References - https://github.com/nodej...

### Impact Executing deeply nested queries may cause stack overflow. ### Patches Upgrade to `v4.0.6`

### Impact For a repository with the [check-spelling action](https://github.com/marketplace/actions/check-spelling) enabled that triggers on `pull_request_target` (or `schedule`), an attacker can send a crafted Pull Request that causes a `GITHUB_TOKEN` to be exposed. With the `GITHUB_TOKEN`, it's possible to push commits to the repository bypassing standard approval processes. Commits to the repository could then steal any/all secrets available to the repository. ### Workarounds You can either: * [Disable the workflow](https://docs.github.com/en/actions/managing-workflow-runs/disabling-and-enabling-a-workflow) until you've fixed **all branches**. or * Set repository to [Allow specific actions](https://docs.github.com/en/github/administering-a-repository/managing-repository-settings/disabling-or-limiting-github-actions-for-a-repository#allowing-specific-actions-to-run). You can check: - [x] `Allow actions created by GitHub` - [x] `Allow Marketplace actions by verified creat...

A stored cross-site scripting (XSS) vulnerability in /index.php?r=site%2Fsignup of Feehi CMS v2.1.1 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the username field.

Apache Calcite Avatica JDBC driver creates HTTP client instances based on class names provided via `httpclient_impl` connection property; however, the driver does not verify if the class implements the expected interface before instantiating it, which can lead to code execution loaded via arbitrary classes and in rare cases remote code execution. To exploit the vulnerability: 1) the attacker needs to have privileges to control JDBC connection parameters; 2) and there should be a vulnerable class (constructor with URL parameter and ability to execute code) in the classpath. From Apache Calcite Avatica 1.22.0 onwards, it will be verified that the class implements the expected interface before invoking its constructor.