ghsa

### Background SAML messages are usually signed to prove the identity of the issuer of the message. In the case of SAML authentication responses, correctly verifying the signature is critical to trust that the assertion contained inside the response was issued by a trusted third-party and the identity of the subject has been properly verified. A SAML message can be signed both at the message level and at the assertion level (if the message is an authentication response). When the whole authentication response message is unsigned, all the assertions contained inside must be signed independently in order to verify their authenticity. Failure to properly verify the authenticity of the entire message or individual assertions leads to the ability of an attacker to impersonate any user from any Identity Provider trusted by the Service Provider. ### Description A signature validation bypass issue has been found in the `SimpleSAML_XML_Validator` class. This class performs the verification of...

### Background In order to implement support for the SAML Enhanced Client or Proxy profile, the credentials obtained for authentication were stored in the state in order to pass them to the relevant routines. This, however, led to the credentials being recorded in the user’s session, which can be stored in permanent storage such as the local file system or a remote memcache or database server. ### Description When an authentication request is received via the ECP profile, the username and password obtained this way were saved to the state array, which is used to pass relevant data to different routines that may need it. This is not a problem in itself. However, when the ECP profile is disabled in the Identity Provider, other bindings such as HTTP-POST or HTTP-Redirect will be used, and since redirections are involved, the state array is then persisted to the user’s session, effectively storing it in the session backend. The ECP profile, which uses the SOAP and PAOS bindings, does not...

### Background Several scripts part of SimpleSAMLphp display a web page with links obtained from the request parameters. This allows us to enhance usability, as the users are presented with links they can follow after completing a certain action, like logging out. ### Description The following scripts were not checking the URLs obtained via the HTTP request before displaying them as the target of links that the user may click on: - www/logout.php - modules/core/www/no_cookie.php The issue allowed attackers to display links targeting a malicious website inside a trusted site running SimpleSAMLphp, due to the lack of security checks involving the link_href and retryURL HTTP parameters, respectively. The issue was resolved by including a verification of the URLs received in the request against a white list of websites specified in the trusted.url.domains configuration option. ### Affected versions All SimpleSAMLphp versions prior to 1.14.4. ### Impact A remote attacker could craft a l...

There is a low level potential SQL injection vulnerability in the silverstripe/subsites module has been identified and fixed in version 2.1.1.

There is a vulnerability in silverstripe/taxonomy module that allows SQL injection. This affected controller (`TaxonomyDirectoryController`) is disabled by default and must be enabled by a developer for the exploit to be possible.

The [userforms module](https://github.com/silverstripe/silverstripe-userforms) allows CMS administrators to create public facing forms with file upload abilities. These files are uploaded into a predictable public path on the website, unless configured otherwise by the CMS administrator setting up the form. While the name of the uploaded file itself is not predictable, certain actions taken by CMS authors could expose it. For example, submission notification emails contain a link to the file without authorisation checks. In 3.0.0 this field is disabled by default, but re-enabled upon installation of the [secure assets module](https://github.com/silverstripe-labs/silverstripe-secureassets). When this is installed, the field can once again be used within a form, and will automatically lock this folder to a secure list of users, which can then be configured further by an administrator. Existing file upload fields will not be disabled, but will require re-enabling via config or installat...

Minder is vulnerable to a denial-of-service (DoS) attack which could allow an attacker to crash the Minder server and deny other users access to it. The root cause of the vulnerability is that Minders sigstore verifier reads an untrusted response entirely into memory without enforcing a limit on the response body. An attacker can exploit this by making Minder make a request to an attacker-controlled endpoint which returns a response with a large body which will crash the Minder server. Specifically, the point of failure is where Minder parses the response from the GitHub attestations endpoint in `getAttestationReply`. Here, Minder makes a request to the `orgs/$owner/attestations/$checksumref` GitHub endpoint (line 285) and then parses the response into the `AttestationReply` (line 295): https://github.com/stacklok/minder/blob/daccbc12e364e2d407d56b87a13f7bb24cbdb074/internal/verifier/sigstore/container/container.go#L271-L300 The way Minder parses the response on line 295 makes it p...

### Impact Users with access to the administration panel with page editing permissions could insert `<script>` tags in markdown fields, which are exposed on the publicly accessible site pages, leading to potential XSS injections. ### Patches - [**Formwork 1.13.0**](https://github.com/getformwork/formwork/releases/tag/1.13.0) has been released with a patch that solves this vulnerability. Now the system config option `content.safe_mode` (enabled by default) controls whether HTML tags and potentially dangerous links are escaped. This is configurable as in some cases more flexibility should be given. Panel users should be only a controlled group of editors, which cannot enable the option by themselves, and not a generic group. This mitigates the chance of introducing vulnerabilities. - [**Formwork 2.x** (6adc302)](https://github.com/getformwork/formwork/commit/6adc302f5a294f2ffbbf1571dd4ffea6b7876723) adds a similar `content.safeMode` system option. Like Formwork 1.13.0, by default HTML ...

### Summary The next ruby code is vulnerable to denial of service due to the fact that the user controlled data `profiler_runs` was not contrained to any limitation. Which would lead to allocating resources on the server side with no limitation (CWE-770). ```ruby runs = (request.params['profiler_runs'] || @times).to_i result = @profile.profile do runs.times { @app.call(env) } end ``` An exploit as such `curl --fail "http://127.0.0.1:9292/?profiler_runs=9999999999&profile=process_time"` may cause resource exhaution by a remotely controlled value. ### PoC Herein the `config.ru` file: ```ruby require 'rack' require 'rack/contrib' use Rack::Profiler # if ENV['RACK_ENV'] == 'development' # Define a Rack application app = lambda do |env| # Your application logic goes here [200, {}, ["Hello World"]] end # Run the Rack application run app ``` A Dockerfile: ```Dockerfile # Use the official Ruby image as a base FROM ruby:latest # Set the working...

### Impact Attackers can exploit the vulnerability to read and delete files and folders from an arbitrary, writable directory as anyone can set the output folder when submitting the request via the `outputFolder` option. ### Patches The issue was fixed via https://github.com/OpenAPITools/openapi-generator/pull/18652 (included in v7.6.0 release) by removing the usage of the `outputFolder` option. ### Workarounds No workaround available. ### References No other reference available.