ghsa

Concrete CMS 9 before 9.2.3 is vulnerable to Cross Site Request Forgery (CSRF) at /ccm/system/dialogs/file/delete/1/submit.

The json-jwt (aka JSON::JWT) gem 1.16.3 for Ruby sometimes allows bypass of identity checks via a sign/encryption confusion attack. For example, JWE can sometimes be used to bypass JSON::JWT.decode.

The jose2go component before 1.6.0 for Go allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.

The jose4j component before 0.9.4 for Java allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.

### Summary ```ruby module Rack class MediaType SPLIT_PATTERN = %r{\s*[;,]\s*} ``` The above regexp is subject to ReDos. 50K blank characters as a prefix to the header will take over 10s to split. ### PoC A simple HTTP request with lots of blank characters in the content-type header: ```ruby request["Content-Type"] = (" " * 50_000) + "a," ``` ### Impact It's a very easy to craft ReDoS. Like all ReDoS the impact is debatable.

# Possible DoS Vulnerability with Range Header in Rack There is a possible DoS vulnerability relating to the Range request header in Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26141. Versions Affected: >= 1.3.0. Not affected: < 1.3.0 Fixed Versions: 3.0.9.1, 2.2.8.1 Impact ------ Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue. Vulnerable applications will use the `Rack::File` middleware or the `Rack::Utils.byte_ranges` methods (this includes Rails applications). Releases -------- The fixed releases are available at the normal locations. Workarounds ----------- There are no feasible workarounds for this issue. Patches ------- To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset. * 3-0-range.pa...

# Possible Denial of Service Vulnerability in Rack Header Parsing There is a possible denial of service vulnerability in the header parsing routines in Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26146. Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1 Impact ------ Carefully crafted headers can cause header parsing in Rack to take longer than expected resulting in a possible denial of service issue. Accept and Forwarded headers are impacted. Ruby 3.2 has mitigations for this problem, so Rack applications using Ruby 3.2 or newer are unaffected. Releases -------- The fixed releases are available at the normal locations. Workarounds ----------- There are no feasible workarounds for this issue. Patches ------- To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset. * 2-0-header-red...

An issue in Mezzanine v6.0.0 allows attackers to bypass access control mechanisms in the admin panel via a crafted request.

### Summary The "frames.html" file within the Yard Doc's generated documentation is vulnerable to Cross-Site Scripting (XSS) attacks due to inadequate sanitization of user input within the JavaScript segment of the "frames.erb" template file. ### Details The vulnerability stems from mishandling user-controlled data retrieved from the URL hash in the embedded JavaScript code within the "frames.erb" template file. Specifically, the script lacks proper sanitization of the hash data before utilizing it to establish the top-level window's location. This oversight permits an attacker to inject malicious JavaScript payloads through carefully crafted URLs. Snippet from "frames.erb": ```erb <script type="text/javascript"> var match = unescape(window.location.hash).match(/^#!(.+)/); var name = match ? match[1] : '<%= url_for_main %>'; name = name.replace(/^(\w+):\/\//, '').replace(/^\/\//, ''); window.top.location = name; </script> ``` ### PoC (Proof of Concept) To exploit this vulner...

### Impact When Flask-AppBuilder is set to AUTH_TYPE AUTH_OID, allows an attacker to forge an HTTP request, that could deceive the backend into using any requested OpenID service. This vulnerability could grant an attacker unauthorised privilege access if a custom OpenID service is deployed by the attacker and accessible by the backend. This vulnerability is only exploitable when the application is using the old (deprecated 10 years ago) OpenID 2.0 authorization protocol (which is very different from the popular OIDC - Open ID Connect - popular protocol used today). Currently, this protocol is regarded as legacy, with significantly reduced usage and not supported for several years by major authorization providers. ### Patches Upgrade to Flask-AppBuilder 4.3.11 ### Workarounds If upgrade is not possible add the following to your config: ``` from flask import flash, redirect from flask_appbuilder import expose from flask_appbuilder.security.sqla.manager import SecurityManager from f...