#git

Dreamer CMS v4.1.3 was discovered to contain a Cross-Site Request Forgery (CSRF) via the component /admin/label/delete.

Dreamer CMS v4.1.3 was discovered to contain a Cross-Site Request Forgery (CSRF) via the component /admin\/category\/add.

Dreamer CMS v4.1.3 was discovered to contain a Cross-Site Request Forgery (CSRF) via the component /admin/attachment/delete.

Dreamer CMS v4.1.3 was discovered to contain a Cross-Site Request Forgery (CSRF) via the component /admin/user/add.

Avoid these errors to get the greatest value from your incident response training sessions.

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