#git

with only one user interaction(download a malicious config), attackers can gain full command execution on the victim system.

A flaw was found in Keycloak. This issue may allow an attacker to steal authorization codes or tokens from clients using a wildcard in the JARM response mode "form_post.jwt" which could be used to bypass the security patch implemented to address CVE-2023-6134.

### Impact Prior to this fix, the GraphQL query parsing was vulnerable to `StackOverflowError`s. The possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. > [!CAUTION] > **No specific knowledge of an application's GraphQL schema would be required to construct a pathological query.** ### Patches The stack overflow issues have been resolved in the v0.18.0 release of Grackle. ### Workarounds Users could interpose a sanitizing layer in between untrusted input and Grackle query processing.

### Impact _What kind of vulnerability is it? Who is impacted?_ Original Report: > The Oauth1/2 "state" and OpenID Connect "nonce" is vulnerable for a "timing attack" since it's compared via regular string > comparison (instead of `Yii::$app->getSecurity()->compareString()`). Affected Code: 1. OAuth 1 "state" https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OAuth1.php#L158 3. OAuth 2 "state" https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OAuth2.php#L121 4. OpenID Connect "nonce" https://github.com/yiisoft/yii2-authclient/blob/0d1c3880f4d79e20aa1d77c012650b54e69695ff/src/OpenIdConnect.php#L420 ### Patches _Has the problem been patched? What versions should users upgrade to?_ TBD: Replace strcmp with `Yii::$app->getSecurity()->compareString()`). ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ not as far as I see....

### Impact A ReDoS (Regular expression Denial of Service) vulnerability has been identified in Sentry's Astro SDK 7.78.0-7.86.0. Under certain conditions, this vulnerability allows an attacker to cause excessive computation times on the server, leading to denial of service (DoS). Applications that are using Sentry's Astro SDK are affected if: 1. They're using Sentry instrumentation: - they have [manually registered](https://docs.sentry.io/platforms/javascript/guides/astro/manual-setup/#manually-add-server-instrumentation) Sentry Middleware (affected versions 7.78.0-7.86.0); - or [configured](https://docs.sentry.io/platforms/javascript/guides/astro/manual-setup/#configure-server-instrumentation) Astro in SSR (server) or hybrid mode, use Astro 3.5.0 and newer and didn’t [disable the automatic server instrumentation](https://docs.sentry.io/platforms/javascript/guides/astro/manual-setup/#disable-auto-server-instrumentation) (affected versions 7.82.0-7.86.0). 2. They have configured...

### Impact _What kind of vulnerability is it? Who is impacted?_ Original Report: > The Oauth2 PKCE implementation is vulnerable in 2 ways: > 1. The `authCodeVerifier` should be removed after usage (similar to 'authState') > 2. There is a risk for a "downgrade attack" if PKCE is being relied on for CSRF protection. ### Patches _Has the problem been patched? What versions should users upgrade to?_ 2.2.15 ### Workarounds _Is there a way for users to fix or remediate the vulnerability without upgrading?_ not known yet. ### References _Are there any links users can visit to find out more?_

### Impact resque-web in resque versions before 2.1.0 is vulnerable to reflected XSS through the current_queue parameter in the path of the queues endpoint. ### Patches v2.1.0 ### Workarounds No known workarounds at this time. It is recommended to not click on 3rd party or untrusted links to the resque-web interface until you have patched your application. ### References https://github.com/resque/resque/issues/1679 https://github.com/resque/resque/pull/1687

### Impact The following paths in resque-web have been found to be vulnerable to reflected XSS: ``` /failed/?class=<script>alert(document.cookie)</script> /queues/><img src=a onerror=alert(document.cookie)> ``` ### Patches v2.2.1 ### Workarounds No known workarounds at this time. It is recommended to not click on 3rd party or untrusted links to the resque-web interface until you have patched your application. ### References https://github.com/resque/resque/pull/1790

### Impact Reflected XSS can be performed using the current_queue portion of the path on the /queues endpoint of resque-web. ### Patches v2.6.0 ### Workarounds No known workarounds at this time. It is recommended to not click on 3rd party or untrusted links to the resque-web interface until you have patched your application. ### References https://github.com/resque/resque/pull/1865

Keycloak prevents certain schemes in redirects, but permits them if a wildcard is appended to the token. This could permit an attacker to submit a specially crafted request leading to XSS or possibly further attacks.