Latest News

Plenti, a static site generator, has an arbitrary file write vulnerability in versions prior to 0.7.2. The `/postLocal` endpoint is vulnerable to an arbitrary file write vulnerability when a plenti user serves their website. This issue may lead to Remote Code Execution. Version 0.7.2 fixes the vulnerability.

An issue was discovered in Ollama before 0.1.46. An attacker can use two HTTP requests to upload a malformed GGUF file containing just 4 bytes starting with the GGUF custom magic header. By leveraging a custom Modelfile that includes a FROM statement pointing to the attacker-controlled blob file, the attacker can crash the application through the CreateModel route, leading to a segmentation fault (signal SIGSEGV: segmentation violation).

Glossarizer through 1.5.2 improperly tries to convert text into HTML. Even though the application itself escapes special characters (e.g., <>), the underlying library converts these encoded characters into legitimate HTML, thereby possibly causing stored XSS. Attackers can append a XSS payload to a word that has a corresponding glossary entry.

The threat actors deceive their victims by impersonating the legal teams of companies, well-known Web stores, and manufacturers.

Thanks @pventuzelo for reporting. From the correspondence: > Hi, > > We (Fuzzinglabs & Lambdaclass) found that during deserialization of certain files representing a `VerifyingKey`, an excessive memory allocation is happening consuming a lot of resources and even triggering a crash with the error `fatal error: runtime: out of memory`. > > Please find the details below: > > ## Vulnerability Details > > - **Severity:** Critical -> DoS > - **Affected Component:** Deserialization > > ## Environment > > - **Compiler Version:** go version go1.22.2 linux/amd64 > - **Distro Version:** Ubuntu 24.04.1 LTS > > - **Additional Environment Details:** > - `[github.com/consensys/gnark](http://github.com/consensys/gnark) v0.11.0` > - `[github.com/consensys/gnark-crypto](http://github.com/consensys/gnark-crypto) v0.14.1-0.20240909142611-e6b99e74cec1` > > ## Steps to Reproduce > > You can download the needed files here: https://drive.google.com/drive/folders/1KQ5I3vv4bUllvqbatGappwbAkIcR2N...

The 2024 ISC2 Cybersecurity Workforce Study found that amid a tightening job market and dynamic cyber-threat environment, ongoing staffing and skills shortages are putting organizations at serious risk. Can AI move the needle in defenders' favor?

Vault Community and Vault Enterprise (“Vault”) clusters using Vault’s Integrated Storage backend are vulnerable to a denial-of-service (DoS) attack through memory exhaustion through a Raft cluster join API endpoint. An attacker may send a large volume of requests to the endpoint which may cause Vault to consume excessive system memory resources, potentially leading to a crash of the underlying system and the Vault process itself. This vulnerability, CVE-2024-8185, is fixed in Vault Community 1.18.1 and Vault Enterprise 1.18.1, 1.17.8, and 1.16.12.

### Impact A community member disclosed an issue where verification signatures for requests sent to Reverb's Pusher-compatible API were not being verified. This API is used in scenarios such as broadcasting a message from a backend service or for obtaining statistical information (such as number of connections) about a given channel. The verification signature is a hash comprised of different parts of the request signed by the app's secret key. The signature is sent as part of the request and should be regenerated by Reverb. Only when both the signature in the request and the one generated by Reverb match should the request be allowed. This helps to verify the request came from a known source. > [!NOTE] > This issue only affects the Pusher-compatible API endpoints and not the WebSocket connections themselves. In order to exploit this vulnerability, the application ID which, should never be exposed, would need to be known by an attacker. The following endpoints were affected: ```...

### Summary The use of a weak cryptographic algorithm and a hard-coded salt to hash the password reset key allows it to be recovered and used to reset the password of any account. ### Details Firstly, the salt used to hash the password reset key is hard-coded in the `includes/services/UserManager.php` file at line `36` : ```php private const PW_SALT = 'FBcA'; ``` Next, the application uses a weak cryptographic algorithm to hash the password reset key. The hash algorithm is defined in the `includes/services/UserManager.php` file at line `201` : ```php protected function generateUserLink($user) { // Generate the password recovery key $key = md5($user['name'] . '_' . $user['email'] . random_int(0, 10000) . date('Y-m-d H:i:s') . self::PW_SALT); ``` The key is generated from the **user's name**, **e-mail address**, a random number **between 0 and 10000**, the **current date** of the request and the **salt**. If we know the user's name and e-mail address, we can retrieve the key...

Android malware FakeCall can intercept calls to the bank on infected devices and redirect the target to the criminals.