ghsa

### Impact An issue has been identified with how OpenSearch handled incoming requests on the HTTP layer. An unauthenticated user could force an OpenSearch node to exit with an OutOfMemory error by sending a moderate number of malformed HTTP requests. The issue was identified by Elastic Engineering and corresponds to security advisory [ESA-2023-13](https://discuss.elastic.co/t/elasticsearch-8-9-0-7-17-13-security-update/343616) (CVE-2023-31418). ### Mitigation Versions 1.3.14 and 2.11.0 contain a fix for this issue. ### For more information If you have any questions or comments about this advisory, please contact AWS/Amazon Security via our issue reporting page (https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.

### Impact The vulnerability allows a third party to derive a valid proof from a valid initial tuple {proof, public_inputs}, corresponding to the same public inputs as the initial proof. It is due to a randomness being generated using a small part of the scratch memory describing the state, allowing for degrees of freedom in the transcript. Note that the impact is limited to the PlonK verifier smart contract. ### Patches We still use a hash function on some data to have a pseudo rng, but instead of hashing the first 32 bytes of the state ( ` let random := mod(keccak256(state, 0x20), r_mod)` ) we hash the whole state at this point of the verifier as if it was a Fiat Shamir transcript: ``` mstore(mPtr, mload(add(state, STATE_FOLDED_DIGESTS_X))) mstore(add(mPtr, 0x20), mload(add(state, STATE_FOLDED_DIGESTS_Y))) mstore(add(mPtr, 0x40), calldataload(add(aproof, PROOF_BATCH_OPENING_AT_ZETA_X))) mstore(add(mPtr, 0x60), calldataload(add(aproof, PROOF_BATCH_...

### Impact This vulnerability causes a Prototype Pollution in document.js, through functions such as findByIdAndUpdate(). For applications using Express and EJS, this can potentially allow remote code execution. ### Patches The original patched version for mongoose 5.3.3 did not include a fix for CVE-2023-3696. Therefore the existing version @seal-security/mongoose-fixed version 5.3.3 is affected by this vulnerability (though it is protected from CVE-2022-2564 and CVE-2019-17426). To mitigate this issue, a @seal-security/mongoose-fixed version 5.3.4 has been deployed. Note that this version is compatible with the original mongoose version 5.3.3, not version 5.3.4 ### References https://security.snyk.io/vuln/SNYK-JS-MONGOOSE-5777721 https://github.com/advisories/GHSA-9m93-w8w6-76hh https://github.com/Automattic/mongoose/commit/f1efabf350522257364aa5c2cb36e441cf08f1a2

### Impact The package does not validate the ACS Location URI according to the SAML binding being parsed. If abused, this flaw allows attackers to register malicious Service Providers at the IdP and inject Javascript in the ACS endpoint definition, achieving Cross-Site-Scripting (XSS) in the IdP context during the redirection at the end of a SAML SSO Flow. Consequently, an attacker may perform any authenticated action as the victim once the victim’s browser loaded the SAML IdP initiated SSO link for the malicious service provider. Note: The severity is considered “High” because the SP registration is commonly an unrestricted operation in IdPs, hence not requiring particular permissions or publicly accessible to ease the IdP interoperability. ### Patches This issue is fixed in 0.4.14 ### Workarounds Users of the package can perform external validation of URLs provided in SAML metadata, or restrict the ability for end-users to upload arbitrary metadata. ### References This iss...

### Impact Due to insufficient access-level checks on the Wiki redirection page, any user can reveal private Projects' names, by accessing wiki.php with sequentially incremented IDs. ### Patches Patch under development. The vulnerability will be fixed in MantisBT version 2.25.8. ### Workarounds Disable wiki integration ( `$g_wiki_enable = OFF;`) ### References - https://mantisbt.org/bugs/view.php?id=32981

## Summary Nocodb contains SQL injection vulnerability, that allows an authenticated attacker with creator access to query the underlying database. ## Product nocodb/nocodb ## Tested Version [0.109.2](https://github.com/nocodb/nocodb/releases/tag/0.109.2) ## Details ### SQL injection in `SqliteClient.ts` (`GHSL-2023-141`) By supplying a specially crafted payload to the given below parameter and endpoint, an attacker can inject arbitrary SQL queries to be executed. Since this is a blind SQL injections, an attacker may need to use time-based payloads which would include a function to delay execution for a given number of seconds. The response time indicates, whether the result of the query execution was true or false. Depending on the result, the HTTP response will be returned after a given number of seconds, indicating TRUE, or immediately, indicating FALSE. In that way, an attacker can reveal the data present in the database. The [`triggerList`](https://github.com/nocodb/nocodb...

### Impact An attacker could use a recursive graphql query to execute a Distributed Denial of Service attack (DDOS attack) against a website. This mostly affects websites with publicly exposed graphql schemas. If your Silverstripe CMS project does not expose a public facing graphql schema, a user account is required to trigger the DDOS attack. If your site is hosted behind a content delivery network (CDN), such as Imperva or CloudFlare, this may further mitigate the risk. The fix includes some new configuration options which you might want to tweak for your project, based on your own requirements. See the documentation in the references for details. ### Patches Patched in [3.8.2](https://github.com/silverstripe/silverstripe-graphql/releases/tag/3.8.2), [4.1.3](https://github.com/silverstripe/silverstripe-graphql/releases/tag/4.1.3), [4.2.5](https://github.com/silverstripe/silverstripe-graphql/releases/tag/4.2.5), [4.3.4](https://github.com/silverstripe/silverstripe-graphql/releases/...

Improper signature counter value handling ### Impact A flaw was found in webauthn4j-spring-security-core. When an authneticator returns an incremented signature counter value during authentication, webauthn4j-spring-security-core does not properly persist the value, which means cloned authenticator detection does not work. An attacker who cloned valid authenticator in some way can use the cloned authenticator without being detected. ### Patches Please upgrade to `com.webauthn4j:webauthn4j-spring-security-core:0.9.1.RELEASE` ### References For more details about WebAuthn signature counters, see [WebAuthn specification 6.1.1. Signature Counter Considerations](https://www.w3.org/TR/2021/REC-webauthn-2-20210408/#sctn-sign-counter). ### Reporter This issue was discovered by Michael Budnick (@mbudnick)

### Impact When login via the OAuth method, the identityOAuth parameters, sent in a GET request is vulnerable to XSS and XWiki syntax injection. This allows remote code execution via the groovy macro and thus affects the confidentiality, integrity and availability of the whole XWiki installation. The vulnerability is in [this part](https://github.com/xwikisas/identity-oauth/blob/master/ui/src/main/resources/IdentityOAuth/LoginUIExtension.vm#L58) of the code. ### Patches The issue has been fixed in Identity OAuth version 1.6 by https://github.com/xwikisas/identity-oauth/commit/d805d3154b17c6bf455ddf5deb0a3461a3833bc6 . The fix is in the content of the [IdentityOAuth/LoginUIExtension](https://github.com/xwikisas/identity-oauth/commit/d805d3154b17c6bf455ddf5deb0a3461a3833bc6#diff-2ab2e0716443d790d7d798320e4a45151661f4eca5440331f4a227b29c87c188) file ### Workarounds There are no known workarounds besides upgrading. ### References _Are there any links users can visit to find out more?...

### Impact Envoy and Go HTTP/2 protocol stack is vulnerable to the "Rapid Reset" class of exploits, which send a sequence of HEADERS frames optionally followed by RST_STREAM frames. This can be exercised if you use the builtin gateway and receive untrusted http2 traffic. ### Patches https://github.com/kumahq/kuma/pull/8023 https://github.com/kumahq/kuma/pull/8001 https://github.com/kumahq/kuma/pull/8034 ### Workarounds Disable http2 on the gateway listener with a MeshProxyPatch or ProxyTemplate. ### References https://github.com/advisories/GHSA-qppj-fm5r-hxr3 https://github.com/golang/go/issues/63417 https://github.com/envoyproxy/envoy/security/advisories/GHSA-jhv4-f7mr-xx76 https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/?sf269548684=1 https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/edge