ghsa

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

### Impact The error page for a missing path echoes the path back to the user. If this contains HTML, an attacker could execute a script on the user's machine inside the Maloja context and perform authorized actions like scrobbling or deleting scrobbles. This does not affect the security of your server. The exploit is purely client-side. Since there is very little incentive to mess with your scrobble data and it requires very specific targeting (an attacker would have to send a user a link to their own server), the severity rating might be misleading. ### Patches The Vulnerability is patched in 3.2.2

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.

### Impact Resque Scheduler version 1.27.4 and above are affected by a cross-site scripting vulnerability. A remote attacker can inject javascript code to the "{schedule_job}" or "args" parameter in /resque/delayed/jobs/{schedule_job}?args={args_id} to execute javascript at client side. ### Patches Fixed in v4.10.2 ### 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://nvd.nist.gov/vuln/detail/CVE-2022-44303 * https://github.com/resque/resque-scheduler/issues/761 * https://github.com/resque/resque/issues/1885 * https://github.com/resque/resque-scheduler/pull/780 * https://github.com/resque/resque-scheduler/pull/783

### Summary Russh v0.40.1 and earlier is vulnerable to a novel prefix truncation attack (a.k.a. Terrapin attack), which allows a man-in-the-middle attacker to strip an arbitrary number of messages right after the initial key exchange, breaking SSH extension negotiation (RFC8308) in the process and thus downgrading connection security. ### Mitigations To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes. Support for strict key exchange has been added to Russh in the patched version. **Warning: To take effect, both the client and server must support this countermeasure.** As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available. ### Details The SSH specifications of Ch...

### Summary AsyncSSH v2.14.1 and earlier is vulnerable to a novel prefix truncation attack (a.k.a. Terrapin attack), which allows a man-in-the-middle attacker to strip an arbitrary number of messages right after the initial key exchange, breaking SSH extension negotiation (RFC8308) in the process and thus downgrading connection security. ### Mitigations To mitigate this protocol vulnerability, OpenSSH suggested a so-called "strict kex" which alters the SSH handshake to ensure a Man-in-the-Middle attacker cannot introduce unauthenticated messages as well as convey sequence number manipulation across handshakes. Support for strict key exchange has been added to AsyncSSH in the patched version. **Warning: To take effect, both the client and server must support this countermeasure.** As a stop-gap measure, peers may also (temporarily) disable the affected algorithms and use unaffected alternatives like AES-GCM instead until patches are available. ### Details The SSH specifications...