#vulnerability

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.

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.

In lunary-ai/lunary version v1.2.13, an improper authorization vulnerability exists that allows unauthorized users to access and manipulate projects within an organization they should not have access to. Specifically, the vulnerability is located in the `checkProjectAccess` method within the authorization middleware, which fails to adequately verify if a user has the correct permissions to access a specific project. Instead, it only checks if the user is part of the organization owning the project, overlooking the necessary check against the `account_project` table for explicit project access rights. This flaw enables attackers to gain complete control over all resources within a project, including the ability to create, update, read, and delete any resource, compromising the privacy and security of sensitive information.

Details have emerged about a new critical security flaw impacting PHP that could be exploited to achieve remote code execution under certain circumstances. The vulnerability, tracked as CVE-2024-4577, has been described as a CGI argument injection vulnerability affecting all versions of PHP installed on the Windows operating system. According to DEVCORE security researcher, the shortcoming makes

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.

In Zend Framework, Zend_Captcha_Word (v1) and Zend\Captcha\Word (v2) generate a "word" for a CAPTCHA challenge by selecting a sequence of random letters from a character set. Prior to this advisory, the selection was performed using PHP's internal array_rand() function. This function does not generate sufficient entropy due to its usage of rand() instead of more cryptographically secure methods such as openssl_pseudo_random_bytes(). This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

We discovered several methods used to generate random numbers in ZF1 that potentially used insufficient entropy. These random number generators are used in the following method calls: ``` Zend_Ldap_Attribute::createPassword Zend_Form_Element_Hash::_generateHash Zend_Gdata_HttpClient::filterHttpRequest Zend_Filter_Encrypt_Mcrypt::_srand Zend_OpenId::randomBytes ``` In each case, the methods were using rand() or mt_rand(), neither of which can generate cryptographically secure values. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation. Moreover, we discovered a potential security issue in the usage of the [openssl_random_pseudo_bytes()](http://php.net/manual/en/function.openssl-random-pseudo-bytes.php) function in Zend_Crypt_Math::randBytes, reported in PHP BUG [#70014](https://bugs.php.net/bug.php?id=70014), and the security implications reported in a discussion [on the random_compat library.](https://github.com/...

In Zend Framework, `Zend_Captcha_Word` (v1) and `Zend\Captcha\Word` (v2) generate a "word" for a CAPTCHA challenge by selecting a sequence of random letters from a character set. Prior to this advisory, the selection was performed using PHP's internal `array_rand()` function. This function does not generate sufficient entropy due to its usage of rand() instead of more cryptographically secure methods such as `openssl_pseudo_random_bytes()`. This could potentially lead to information disclosure should an attacker be able to brute force the random number generation.

A path traversal and a javascript code injection vulnerabilities were identified in willdurand/js-translation-bundle versions prior to 2.1.1.

Adminer script versions up to 4.6.2 contains file disclosure vulnerability.