#git

### Impact A malicious user could cause a denial of service (DoS) when using a specially crafted gRPC request. The decompression mechanism for zstd did not respect the limits imposed by gRPC, allowing rapid memory usage increases. Versions v1.1.4 through to v1.2.2 made use of the Decoder.DecodeAll function in github.com/klauspost/compress/zstd to decompress data provided by the peer. The vulnerability is exploitable only by attackers who can send gRPC payloads to users of github.com/mostynb/go-grpc-compression/zstd or github.com/mostynb/go-grpc-compression/nonclobbering/zstd. ### Patches Version v1.2.3 of github.com/mostynb/go-grpc-compression avoids the issue by not using the Decoder.DecodeAll function in github.com/klauspost/compress/zstd. All users of github.com/mostynb/go-grpc-compression/zstd or github.com/mostynb/go-grpc-compression/nonclobbering/zstd in the affected versions should update to v1.2.3. ### Workarounds Other compression formats were not affected, users may c...

If passed, APRA will be a giant leap forward for the rights and freedoms of Americans.

Kiuwan SAST versions prior to 2.8.2402.3, Kiuwan Local Analyzer versions prior to master.1808.p685.q13371, and Kiuwan SaaS versions prior to 2024-02-05 suffer from XML external entity injection, cross site scripting, insecure direct object reference, and various other vulnerabilities.

Electronic health records (EHRs) have become crucial tools for storing and managing patient information. These digital records contain…

While cyberattacks drop slightly during the week of the Islamic pilgrimage, organizations in Saudi Arabia and other countries with large Muslim populations see attacks on the rise.

In lunary-ai/lunary version 1.2.13, an insufficient granularity of access control vulnerability allows users to create, update, get, and delete prompt variations for datasets not owned by their organization. This issue arises due to the application not properly validating the ownership of dataset prompts and their variations against the organization or project of the requesting user. As a result, unauthorized modifications to dataset prompts can occur, leading to altered or removed dataset prompts without proper authorization. This vulnerability impacts the integrity and consistency of dataset information, potentially affecting the results of experiments.

lepture Authlib before 1.3.1 has algorithm confusion with asymmetric public keys. Unless an algorithm is specified in a jwt.decode call, HMAC verification is allowed with any asymmetric public key. (This is similar to CVE-2022-29217 and CVE-2024-33663.)

A vulnerability in zenml-io/zenml version 0.56.3 allows attackers to reuse old session credentials or session IDs due to insufficient session expiration. Specifically, the session does not expire after a password change, enabling an attacker to maintain access to a compromised account without the victim's ability to revoke this access. This issue was observed in a self-hosted ZenML deployment via Docker, where after changing the password from one browser, the session remained active and usable in another browser without requiring re-authentication.

Previous to @2ca5bb1c2f11537be8f94ca6867d8d69789e744a (release [0.1.2](https://github.com/zf-fr/zfr-oauth2-server-module/tree/0.1.2)), tokens weren't checked for validity/expiration. This potentially caused a security issue if expired tokens were not deleted after the expiration time was past, allowing anyone to still use invalidated authentication credentials.

Using the Consumer component of ZendOpenId (or Zend_OpenId in ZF1), it is possible to login using an arbitrary OpenID account (without knowing any secret information) by using a malicious OpenID Provider. That means OpenID it is possible to login using arbitrary OpenID Identity (MyOpenID, Google, etc), which are not under the control of our own OpenID Provider. Thus, we are able to impersonate any OpenID Identity against the framework. Moreover, the Consumer accepts OpenID tokens with arbitrary signed elements. The framework does not check if, for example, both openid.claimed_id and openid.endpoint_url are signed. It is just sufficient to sign one parameter. According to https://openid.net/specs/openid-authentication-2_0.html#positive_assertions, at least op_endpoint, return_to, response_nonce, assoc_handle, and, if present in the response, claimed_id and identity, must be signed.