ghsa

### Summary When using a modified client or the grpc interface directly, the `RegisterRepository` call accepts _both_ the repository owner / repo **and** the repo_id. Furthermore, these two are not checked for matching before registering webhooks and data in the database. ### Details It is possible for an attacker to register a repository with a invalid or differing upstream ID, which causes Minder to report the repository as registered, but not remediate any future changes which conflict with policy (because the webhooks for the repo do not match any known repository in the database). When attempting to register a repo with a different repo ID, the registered provider must have admin on the named repo, or a 404 error will result. Similarly, if the stored provider token does not have repo access, then the remediations will not apply successfully. Lastly, it appears that reconciliation actions do not execute against repos with this type of mismatch. ### PoC With an RPC like the...

### Impact If an HTTP/2 connection gets TCP congested, when an idle timeout occurs the HTTP/2 session is marked as closed, and then a GOAWAY frame is queued to be written. However it is not written because the connection is TCP congested. When another idle timeout period elapses, it is then supposed to hard close the connection, but it delegates to the HTTP/2 session which reports that it has already been closed so it does not attempt to hard close the connection. This leaves the connection in ESTABLISHED state (i.e. not closed), TCP congested, and idle. An attacker can cause many connections to end up in this state, and the server may run out of file descriptors, eventually causing the server to stop accepting new connections from valid clients. The client may also be impacted (if the server does not read causing a TCP congestion), but the issue is more severe for servers. ### Patches Patched versions: * 9.4.54 * 10.0.20 * 11.0.20 * 12.0.6 ### Workarounds Disable HTTP/2 and HTTP/...

### Summary When using the built-in `extract32(b, start)`, if the `start` index provided has for side effect to update `b`, the byte array to extract `32` bytes from, it could be that some dirty memory is read and returned by `extract32`. ### Details Before evaluating `start`, the function `Extract32.build_IR` caches only: - The pointer in memory/storage to `b`: https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L916-L918 - The length of `b`: https://github.com/vyperlang/vyper/blob/10564dcc37756f3d3684b7a91fd8f4325a38c4d8/vyper/builtins/functions.py#L920-L922 but do not cache the actual content of `b`. This means that if the evaluation of `start` changes `b`'s content and length, an outdated length will be used with the new content when extracting 32 bytes from `b`. ### PoC Calling the function `foo` of the following contract returns `b'uuuuuuuuuuuuuuuuuuuuuuuuuuu\x00\x00789'` meaning that `extract32` accessed some dirty ...

## Summary If an excessively large value is specified as the starting index for an array in `_abi_decode`, it can cause the read position to overflow. This results in the decoding of values outside the intended array bounds, potentially leading to bugs in contracts that use arrays within `_abi_decode`. The advisory has been assigned low severity, because it is only observable if there is a memory write between two invocations of `abi_decode` on the same input. ## Proof of Concept ```vyper event Pwn: pass @external def f(x: Bytes[32 * 3]): a: Bytes[32] = b"foo" y: Bytes[32 * 3] = x decoded_y1: Bytes[32] = _abi_decode(y, Bytes[32]) a = b"bar" decoded_y2: Bytes[32] = _abi_decode(y, Bytes[32]) if decoded_y1 != decoded_y2: log Pwn() ``` Sending the following calldata results in `Pwn` being emitted. ``` 0xd45754f8 0000000000000000000000000000000000000000000000000000000000000020 0000000000000000000000000000000000000000000000000000000000000060 fffff...

### Problem User sessions in the @nfid/embed SDK with Ed25519 keys are vulnerable due to a compromised private key `535yc-uxytb-gfk7h-tny7p-vjkoe-i4krp-3qmcl-uqfgr-cpgej-yqtjq-rqe`. This exposes users to potential loss of funds on ledgers and unauthorized access to canisters they control. ### Solution Using version >1.0.1 of @dfinity/auth-client and @dfinity/identity packages, or @nfid/embed >0.10.1-alpha.6 includes patched versions of the issue. User sessions will be automatically fixed when they re-authenticate. ### Why this happened The DFINITY auth client library provides a function, `Ed25519KeyIdentity.generate`, for generating an Ed25519 key pair. This function includes an optional parameter to supply a 32-byte seed value, which will be utilized as the secret key. In cases where no seed value is provided, the library is expected to generate the secret key using secure randomness. However, a recent update of DFINITY libraries has compromised this assurance by employing an insec...

### Impact When SAML is used as the authentication mechanism, Central Dogma accepts unsigned SAML messages (assertions, logout requests, etc.) as they are, rather than rejecting them by default. As a result, an attacker can forge a SAML message to authenticate themselves, despite the fact that such an unsigned SAML message should be rejected. ### Patches The vulnerability has been patched in Central Dogma 0.64.3 by updating its Armeria dependency to 1.27.2. All users who use SAML as the authentication mechanism must upgrade from 0.64.3 or later. ### Workarounds A user can manually upgrade the `armeria-saml` module with the one from Armeria 1.27.2 or later, either by replacing the JAR in the Central Dogma distribution or by updating the dependency tree of the build. ### References [`SamlMessageUtil.validateSignature()`](https://github.com/line/armeria/blob/0efc776988d71be4da6e506ec8a33c2b7b43f567/saml/src/main/java/com/linecorp/armeria/server/saml/SamlMessageUtil.java#L160-L163)

### Impact The SAML implementation provided by `armeria-saml` currently accepts unsigned SAML messages (assertions, logout requests, etc.) as they are, rather than rejecting them by default. As a result, an attacker can forge a SAML message to authenticate themselves, despite the fact that such an unsigned SAML message should be rejected. ### Patches The vulnerability has been patched in Armeria version 1.27.2. All users who rely on `armeria-saml` older than version 1.27.2 must upgrade to 1.27.2 or later. ### Workarounds There is no known workaround for this vulnerability. ### References [`SamlMessageUtil.validateSignature()`](https://github.com/line/armeria/blob/0efc776988d71be4da6e506ec8a33c2b7b43f567/saml/src/main/java/com/linecorp/armeria/server/saml/SamlMessageUtil.java#L160-L163)

### Impact Code scanning revealed possible vulnerability in C extensions for PyPop: incorrect function calls (missing arguments or wrongly typed arguments) and redundant null pointers. ### Patches The problem has been patched and fixed in the latest release of PyPop: 1.0.2. Please upgrade your PyPop installation via: ``` pip install -U pypop-genomics ``` ### Workarounds No. Upgrade to the latest package: 1.0.2. ### References N/A

### Impact Passing functions with very long names or complex default argument names into `function#copy` or`function#toStringTokens` may put script to stall ### Patches Fixed with https://github.com/medikoo/es5-ext/commit/3551cdd7b2db08b1632841f819d008757d28e8e2 and https://github.com/medikoo/es5-ext/commit/a52e95736690ad1d465ebcd9791d54570e294602 Published with v0.10.63 ### Workarounds No real workaround aside of refraining from using above utilities. ### References https://github.com/medikoo/es5-ext/issues/201

### TL;DR This vulnerability affects Kirby sites that use the new [link field](https://getkirby.com/docs/reference/panel/fields/link) and output the entered link without additional validation or sanitization. The attack commonly requires user interaction by another user or visitor. The link dialog of the writer field is *not* affected as the writer field content is automatically sanitized by the Kirby backend code. You are also already protected if you limit the acceptable link types with the `options` field property. ---- ### Introduction Cross-site scripting (XSS) is a type of vulnerability that allows to execute any kind of JavaScript code inside the Panel session of the same or other users. In the Panel, a harmful script can for example trigger requests to Kirby's API with the permissions of the victim. Such vulnerabilities are critical if you might have potential attackers in your group of authenticated Panel users. They can escalate their privileges if they get access to t...