ghsa

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

### Impact A vulnerability CVE-2023-39325 exists in [Go managing HTTP/2 requests](https://groups.google.com/g/golang-announce/c/iNNxDTCjZvo/m/UDd7VKQuAAAJ?pli=1), which impacts Traefik. This vulnerability could be exploited to cause a denial of service. ### References - [CVE-2023-44487](https://www.cve.org/CVERecord?id=CVE-2023-44487) - [CVE-2023-39325](https://www.cve.org/CVERecord?id=CVE-2023-39325) ### Patches - https://github.com/traefik/traefik/releases/tag/v2.10.5 - https://github.com/traefik/traefik/releases/tag/v3.0.0-beta4

### Impact It's possible for a user without any specific right to perform script injection and remote code execution just by inserting an appropriate title when creating a new Change Request. This vulnerability is particularly critical as Change Request aims at being created by user without any particular rights. ### Patches The vulnerability has been fixed in Change Request 1.9.2. ### Workarounds It's possible to workaround the issue without upgrading by editing the document `ChangeRequest.Code.ChangeRequestSheet` and by performing the same change as in the commit: https://github.com/xwiki-contrib/application-changerequest/commit/7565e720117f73102f5a276239eabfe85e15cff4. ### References * JIRA ticket: https://jira.xwiki.org/browse/CRAPP-298 * Commit of the fix: https://github.com/xwiki-contrib/application-changerequest/commit/7565e720117f73102f5a276239eabfe85e15cff4 ### For more information If you have any questions or comments about this advisory: * Open an issue in [J...

When a collaboration is deleted in vantage6, the linked resources (such as tasks from that collaboration) are not properly deleted. This is partly to manage data properly, but also to prevent a potential (but unlikely) side-effect, where if a collaboration with id=10 is deleted, and subsequently a new collaboration is created with id=10, the authenticated users in that collaboration could potentially see results of the deleted collaboration in some cases, resulting in information disclosure.