ghsa

### Impact This vulnerability may allow [SameSite Attackers](https://canitakeyoursubdomain.name/) to bypass the [CodeIgniter4 CSRF protection](https://codeigniter4.github.io/userguide/libraries/security.html) 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) ### Referen...

### Impact `=< [email protected]` users are vulnerable to _CRLF Injection_ on headers when using unsanitized input as request headers, more specifically, inside the `content-type` header. Example: ``` import { request } from 'undici' const unsanitizedContentTypeInput = 'application/json\r\n\r\nGET /foo2 HTTP/1.1' await request('http://localhost:3000, { method: 'GET', headers: { 'content-type': unsanitizedContentTypeInput }, }) ``` The above snippet will perform two requests in a single `request` API call: 1) `http://localhost:3000/` 2) `http://localhost:3000/foo2` ### Patches This issue was patched in Undici v5.8.1 ### Workarounds Sanitize input when sending content-type headers using user input. ## For more information If you have any questions or comments about this advisory: - Open an issue in [undici repository](https://github.com/nodejs/undici/issues) - To make a report, follow the [SECURITY](https://github.com/nodejs/node/blob/HEAD/SECURITY.md) document...

**Summary** As part of a Kubevirt audit performed by NCC group, a finding dealing with systemic lack of path sanitization which leads to a path traversal was identified. Google tested the exploitability of the paths in the audit report and identified that when combined with another vulnerability one of the paths leads to an arbitrary file read on the host from the VM. The read operations are limited to files which are publicly readable or which are readable for UID 107 or GID 107. /proc/self/<> is not accessible. **Severity** Moderate - The vulnerability is proven to exist in an open source version of KubeVirt by NCC Group while being combined with Systemic Lack of Path Sanitization, which leads to Path traversal. **Proof of Concept** The initial VMI specifications can be written as such to reproduce the issue: ``` apiVersion: kubevirt.io/v1 kind: VirtualMachineInstance metadata: name: vmi-fedora spec: domain: devices: disks: - disk: bus: virtio ...

## Impact The `core.exportVariable` function uses a well known delimiter that attackers can use to break out of that specific variable and assign values to other arbitrary variables. Workflows that write untrusted values to the `GITHUB_ENV` file may cause the path or other environment variables to be modified without the intention of the workflow or action author. ## Patches Users should upgrade to `@actions/core v1.9.1`. ## Workarounds If you are unable to upgrade the `@actions/core` package, you can modify your action to ensure that any user input does not contain the delimiter `_GitHubActionsFileCommandDelimeter_` before calling `core.exportVariable`. ## References [More information about setting-an-environment-variable in workflows](https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable) If you have any questions or comments about this advisory: * Open an issue in [`actions/toolkit`](https://github.com/actions...

Wouter Castryck and Thomas Decru presented an efficient key recovery attack on the SIDH protocol. As a result, the secret key of SIKEp751 can be recovered in a matter of hours. The SIKE and SIDH schemes will be removed from oqs 0.7.2. [An efficient key recovery attack on SIDH (preliminary version)](https://eprint.iacr.org/2022/975)

### Impact The functions `ECDSA.recover` and `ECDSA.tryRecover` are vulnerable to a kind of signature malleability due to accepting EIP-2098 compact signatures in addition to the traditional 65 byte signature format. This is only an issue for the functions that take a single `bytes` argument, and not the functions that take `r, v, s` or `r, vs` as separate arguments. The potentially affected contracts are those that implement signature reuse or replay protection by marking the signature itself as used rather than the signed message or a nonce included in it. A user may take a signature that has already been submitted, submit it again in a different form, and bypass this protection. ### Patches The issue has been patched in 4.7.3. ### For more information If you have any questions or comments about this advisory, or need assistance deploying a fix, email us at [[email protected]](mailto:[email protected]).

### Impact `undici` is vulnerable to SSRF (Server-side Request Forgery) when an application takes in **user input** into the `path/pathname` option of `undici.request`. If a user specifies a URL such as `http://127.0.0.1` or `//127.0.0.1` ```js const undici = require("undici") undici.request({origin: "http://example.com", pathname: "//127.0.0.1"}) ``` Instead of processing the request as `http://example.org//127.0.0.1` (or `http://example.org/http://127.0.0.1` when `http://127.0.0.1 is used`), it actually processes the request as `http://127.0.0.1/` and sends it to `http://127.0.0.1`. If a developer passes in user input into `path` parameter of `undici.request`, it can result in an _SSRF_ as they will assume that the hostname cannot change, when in actual fact it can change because the specified path parameter is combined with the base URL. ### Patches This issue was fixed in `[email protected]`. ### Workarounds The best workaround is to validate user input before passing it to the...

### Impact The default landing page contained HTML to display a sample `curl` command which is made visible if the full landing page bundle could not be fetched from Apollo's CDN. The server's URL is directly interpolated into this command inside the browser from `window.location.href`. On some older browsers such as IE11, this value is not URI-encoded. On such browsers, opening a malicious URL pointing at an Apollo Router could cause execution of attacker-controlled JavaScript. This only affects Apollo Server with the [default landing page](https://www.apollographql.com/docs/apollo-server/api/plugin/landing-pages/) enabled. Old browsers visiting your server may be affected if ANY of these apply: - You do not pass any landing page plugin to the `plugins` option of `new ApolloServer`. - You pass `ApolloServerPluginLandingPageLocalDefault()` or `ApolloServerPluginLandingPageProductionDefault()` to the `plugins` option of `new ApolloServer`. Browsers visiting your server are NOT affect...

### Impact This issue concerns instances of Governor that use the module `GovernorVotesQuorumFraction`, a mechanism that determines quorum requirements as a percentage of the voting token's total supply. In affected instances, when a proposal is passed to lower the quorum requirement, past proposals may become executable if they had been defeated only due to lack of quorum, and the number of votes it received meets the new quorum requirement. Analysis of instances on chain found only one proposal that met this condition, and we are actively monitoring for new occurrences of this particular issue. ### Patches This issue has been patched in v4.7.2. ### Workarounds Avoid lowering quorum requirements if a past proposal was defeated for lack of quorum. ### References https://github.com/OpenZeppelin/openzeppelin-contracts/pull/3561 ### For more information If you have any questions or comments about this advisory, or need assistance deploying the fix, email us at [security@openzepp...

### Impact py-cord is a an API wrapper for Discord written in Python. Bots using py-cord version 2.0.0 are vulnerable to remote shutdown if they are added to the server with the `application.commands` scope without the `bot` scope. Currently, it appears that all public bots that use slash commands are affected. ### Patches This issue has been patched in version 2.0.1. ### Workarounds There are currently no recommended workarounds - please upgrade to a patched version. ### References https://github.com/Pycord-Development/pycord/pull/1568 ### For more information If you have any questions or comments about this advisory: * Open an issue in [our GitHub](https://github.com/Pycord-Development/pycord) * Email us at [[email protected]](mailto:[email protected])