Vulnerabilities

With the aim of informing, warning and helping professionals with the latest security vulnerabilities in technology systems, we have made a database available for users interested in this information, which is in Spanish and includes all of the latest documented and recognised vulnerabilities.

This repository, with over 75,000 registers, is based on the information from the NVD (National Vulnerability Database) – by virtue of a partnership agreement – through which INCIBE translates the included information into Spanish.

On occasions this list will show vulnerabilities that have still not been translated, as they are added while the INCIBE team is still carrying out the translation process. The CVE (Common Vulnerabilities and Exposures) Standard for Information Security Vulnerability Names is used with the aim to support the exchange of information between different tools and databases.

All vulnerabilities collected are linked to different information sources, as well as available patches or solutions provided by manufacturers and developers. It is possible to carry out advanced searches, as there is the option to select different criteria to narrow down the results, some examples being vulnerability types, manufacturers and impact levels, among others.

Through RSS feeds or Newsletters we can be informed daily about the latest vulnerabilities added to the repository. Below there is a list, updated daily, where you can discover the latest vulnerabilities.

CVE-2024-51502

Publication date:

04/11/2024

loona is an experimental, HTTP/1.1 and HTTP/2 implementation in Rust on top of io-uring. `loona-hpack` suffers from the same vulnerability as the original `hpack` as documented in issue #11. All users who try to decode untrusted input using the Decoder are vulnerable to this exploit. This issue has been addressed in release version 0.4.3. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Severity CVSS v4.0: MEDIUM

Last modification:

05/11/2024

CVE-2024-51734

Publication date:

04/11/2024

Zope AccessControl provides a general security framework for use in Zope. In affected versions anonymous users can delete the user data maintained by an `AccessControl.userfolder.UserFolder` which may prevent any privileged access. This problem has been fixed in version 7.2. Users are advised to upgrade. Users unable to upgrade may address the issue by adding `data__roles__ = ()` to `AccessControl.userfolder.UserFolder`.

Severity CVSS v4.0: HIGH

Last modification:

22/01/2025

CVE-2024-48050

Publication date:

04/11/2024

In agentscope

Severity CVSS v4.0: Pending analysis

Last modification:

04/09/2025

CVE-2024-48052

Publication date:

04/11/2024

In gradio

Severity CVSS v4.0: Pending analysis

Last modification:

13/06/2025

CVE-2024-48057

Publication date:

04/11/2024

localai

Severity CVSS v4.0: Pending analysis

Last modification:

04/09/2025

CVE-2024-48059

Publication date:

04/11/2024

gaizhenbiao/chuanhuchatgpt project, version

Severity CVSS v4.0: Pending analysis

Last modification:

11/07/2025

CVE-2024-48061

Publication date:

04/11/2024

langflow

Severity CVSS v4.0: Pending analysis

Last modification:

28/05/2025

CVE-2024-51500

Publication date:

04/11/2024

Meshtastic firmware is a device firmware for the Meshtastic project. The Meshtastic firmware does not check for packets claiming to be from the special broadcast address (0xFFFFFFFF) which could result in unexpected behavior and potential for DDoS attacks on the network. A malicious actor could craft a packet to be from that address which would result in an amplification of this one message into every node on the network sending multiple messages. Such an attack could result in degraded network performance for all users as the available bandwidth is consumed. This issue has been addressed in release version 2.5.6. All users are advised to upgrade. There are no known workarounds for this vulnerability.

Severity CVSS v4.0: Pending analysis

Last modification:

15/10/2025

CVE-2024-51501

Publication date:

04/11/2024

Refit is an automatic type-safe REST library for .NET Core, Xamarin and .NET The various header-related Refit attributes (Header, HeaderCollection and Authorize) are vulnerable to CRLF injection. The way HTTP headers are added to a request is via the `HttpHeaders.TryAddWithoutValidation` method. This method does not check for CRLF characters in the header value. This means that any headers added to a refit request are vulnerable to CRLF-injection. In general, CRLF-injection into a HTTP header (when using HTTP/1.1) means that one can inject additional HTTP headers or smuggle whole HTTP requests. If an application using the Refit library passes a user-controllable value through to a header, then that application becomes vulnerable to CRLF-injection. This is not necessarily a security issue for a command line application like the one above, but if such code were present in a web application then it becomes vulnerable to request splitting (as shown in the PoC) and thus Server Side Request Forgery. Strictly speaking this is a potential vulnerability in applications using Refit and not in Refit itself. This issue has been addressed in release versions 7.2.22 and 8.0.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.

Severity CVSS v4.0: CRITICAL

Last modification:

08/11/2024

CVE-2024-10805

Publication date:

04/11/2024

A vulnerability was found in code-projects University Event Management System 1.0. It has been classified as critical. This affects an unknown part of the file doedit.php. The manipulation of the argument id leads to sql injection. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The initial researcher advisory mentions a confusing product name to be affected. Other parameters might be affected as well.

Severity CVSS v4.0: MEDIUM

Last modification:

07/11/2024

CVE-2024-51744

Publication date:

04/11/2024

golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above.

Severity CVSS v4.0: Pending analysis

Last modification:

05/11/2024