ghsa

### 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

A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to obtain tokens and forge malicious requests on behalf of a user. This can lead to unauthorized actions being taken on the user's behalf, potentially compromising the security and integrity of the application. ## Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. **Lack of Token Association**: The CSRF token was validated against tokens in storage but was not tied to the original requestor that generated it, allowing for token reuse. ### Specific Go Packages Affected github.com/gofiber/fiber/v2/middleware/csrf ## Remediation To remediate this vulnerability, it is recommended to take the following actions: 1. **Update the Application**: Upgrade the application to a fixed version with a patch for the vulnerability. 2. **Implement Proper CSRF Protecti...

A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to inject arbitrary values and forge malicious requests on behalf of a user. This vulnerability can allow an attacker to inject arbitrary values without any authentication, or perform various malicious actions on behalf of an authenticated user, potentially compromising the security and integrity of the application. ## Vulnerability Details The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. The following issues were identified: 1. **Token Injection**: For 'safe' methods, the token was extracted from the cookie and saved to storage without further validation or sanitization. 2. **Lack of Token Association**: The CSRF token was validated against tokens in storage but not associated with a session, nor by using a Double Submit Cookie Method, allowing for token reuse. ### Specific Go Packages Affected github.com/gofib...