ghsa

### Impact On HTML elements handled by Orejime, one could run malicious code by embedding `javascript:` code within data attributes. When consenting to the related purpose, Orejime would turn data attributes into unprefixed ones (i.e. `data-href` into `href`), thus executing the code. This shouldn't have any impact on most setups, as elements handled by Orejime are generally hardcoded. The problem would only arise if somebody could inject HTML code within pages. See https://github.com/boscop-fr/orejime/issues/142 for the original report. ### Patches The problem has been patched by https://github.com/boscop-fr/orejime/pull/143. It is available in version 2.3.2. ### Workarounds The problem can be fixed outside of Orejime by sanitizing attributes which could contain executable code.

Multiple API endpoints allowed access to sensitive files from other users by knowing the UUID of the file that were not intended to be accessible by UUID only.

An API endpoint allowed access to sensitive files from other users by knowing the UUID of the file that were not intended to be accessible by UUID only.

Apache NiFi 1.20.0 through 2.6.0 include the GetAsanaObject Processor, which requires integration with a configurable Distribute Map Cache Client Service for storing and retrieving state information. The GetAsanaObject Processor used generic Java Object serialization and deserialization without filtering. Unfiltered Java object deserialization does not provide protection against crafted state information stored in the cache server configured for GetAsanaObject. Exploitation requires an Apache NiFi system running with the GetAsanaObject Processor, and direct access to the configured cache server. Upgrading to Apache NiFi 2.7.0 is the recommended mitigation, which replaces Java Object serialization with JSON serialization. Removing the GetAsanaObject Processor located in the nifi-asana-processors-nar bundle also prevents exploitation.

Versions of the package fastapi-sso before 0.19.0 are vulnerable to Cross-site Request Forgery (CSRF) due to the improper validation of the OAuth state parameter during the authentication callback. While the get_login_url method allows for state generation, it does not persist the state or bind it to the user's session. Consequently, the verify_and_process method accepts the state received in the query parameters without verifying it against a trusted local value. This allows a remote attacker to trick a victim into visiting a malicious callback URL, which can result in the attacker's account being linked to the victim's internal account.

Improper Validation of Specified Index, Position, or Offset in Input (CWE-1285) in Filebeat Syslog parser and the Libbeat Dissect processor can allow a user to trigger a Buffer Overflow (CAPEC-100) and cause a denial of service (panic/crash) of the Filebeat process via either a malformed Syslog message or a malicious tokenizer pattern in the Dissect configuration.

Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow an authenticated user with snapshot restore privileges to cause Excessive Allocation (CAPEC-130) of memory and a denial of service (DoS) via crafted HTTP request.

Allocation of Resources Without Limits or Throttling (CWE-770) in Elasticsearch can allow a low-privileged authenticated user to cause Excessive Allocation (CAPEC-130) causing a persistent denial of service (OOM crash) via submission of oversized user settings data.

Allocation of resources without limits or throttling (CWE-770) allows an unauthenticated remote attacker to cause excessive allocation (CAPEC-130) of memory and CPU via the integration of malicious IPv4 fragments, leading to denial-of-service in Packetbeat.

### Impact It was possible to overwrite Git configuration remotely and override some of its behavior. ### Resources Thanks to Jason Marcello for responsible disclosure.