ghsa

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

The `Ref` methods `into_ref`, `into_mut`, `into_slice`, and `into_slice_mut` are unsound and may allow safe code to exhibit undefined behavior when used with `Ref<B, T>` where `B` is [`cell::Ref`](https://doc.rust-lang.org/core/cell/struct.Ref.html) or [`cell::RefMut`](https://doc.rust-lang.org/core/cell/struct.RefMut.html). Note that these methods remain sound when used with `B` types other than `cell::Ref` or `cell::RefMut`. See https://github.com/google/zerocopy/issues/716 for a more in-depth analysis. The current plan is to yank the affected versions soon. See https://github.com/google/zerocopy/issues/679 for more detail.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17.

Cross-site Scripting (XSS) - Stored in GitHub repository thorsten/phpmyfaq prior to 3.1.17.

### Impact Versions [v9.26.0](https://github.com/octokit/webhooks.js/releases/tag/v9.26.0), [v10.9.x](https://github.com/octokit/webhooks.js/releases/tag/v10.9.1)), [v11.1.x](https://github.com/octokit/webhooks.js/releases/tag/v11.1.1), [v12.0.x](https://github.com/octokit/webhooks.js/releases/tag/v12.0.3) all contained the code that would throw the error. Specifically, during a pentest we encountered a bug in the octokit/webhooks library (a dependency of Probot, a framework for building Github Apps). The resulting request was found to cause an uncaught exception that ends the nodejs process. The problem is caused by an issue with error handling in the @octokit/webhooks library because the error can be undefined in some cases. Credit goes to @pb82 (for the early analysis) and @rh-tguittet (for discovery). ### Patches Maintenance releases for the Error being thrown by the verify method in [octokit/webhooks.js](https://github.com/octokit/webhooks.js) * v12 - [v12.0.4](https://githu...

### Impact Anyone who can edit an arbitrary wiki page in an XWiki installation can gain programming right through several cases of missing escaping in the code for displaying sections in the administration interface. This impacts the confidentiality, integrity and availability of the whole XWiki installation. Normally, all users are allowed to edit their own user profile so this should be exploitable by all users of the XWiki instance. The easiest way to reproduce this is to edit any document with the object editor and add an object of type `XWiki.ConfigurableClass` ("Custom configurable sections"). Set "Display in section" and "Display in Category" to "other", set scope to "Wiki and all spaces" and "Heading" to `{{async}}{{groovy}}services.logging.getLogger("attacker").error("Attack from Heading succeeded!"); println("Hello from Groovy!"){{/groovy}}{{/async}}`. Click "Save". Open `<xwiki-host>/xwiki/bin/view/Main/?sheet=XWiki.AdminSheet&viewer=content&editor=globaladmin&section=othe...

### Impact There is a reflected XSS or also direct remote code execution vulnerability in the code for displaying configurable admin sections. The code that can be passed through a URL parameter is only executed when the user who is visiting the crafted URL has edit right on at least one configuration section. While any user of the wiki could easily create such a section, in this case it is much more convenient to exploit [GHSA-qj86-p74r-7wp5](https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-qj86-p74r-7wp5) which is why this attack scenario won't be further considered in the following. In contrast to GHSA-qj86-p74r-7wp5, this vulnerability doesn't require the attacker to have an account or any access on the wiki. It is sufficient to trick any admin user of the XWiki installation to visit the crafted URL. Alternatively, the URL can also be embedded as image source of an image in any content of the wiki like a comment that could be left by an anonymous user. This vulner...