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-2023-6825

Publication date:
13/03/2024
The File Manager and File Manager Pro plugins for WordPress are vulnerable to Directory Traversal in versions up to, and including version 7.2.1 (free version) and 8.3.4 (Pro version) via the target parameter in the mk_file_folder_manager_action_callback_shortcode function. This makes it possible for attackers to read the contents of arbitrary files on the server, which can contain sensitive information and to upload files into directories other than the intended directory for file uploads. The free version requires Administrator access for this vulnerability to be exploitable. The Pro version allows a file manager to be embedded via a shortcode and also allows admins to grant file handling privileges to other user levels, which could lead to this vulnerability being exploited by lower-level users.
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025

CVE-2023-6809

Publication date:
13/03/2024
The Custom fields shortcode plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's cf shortcode in all versions up to, and including, 0.1 due to insufficient input sanitization and output escaping on user supplied custom post meta values. This makes it possible for authenticated attackers with contributor-level and above permissions to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025

CVE-2023-6785

Publication date:
13/03/2024
The Download Manager plugin for WordPress is vulnerable to unauthorized file download of files added via the plugin in all versions up to, and including, 3.2.84. This makes it possible for unauthenticated attackers to download files added with the plugin (even when privately published).
Severity CVSS v4.0: Pending analysis
Last modification:
21/03/2025

CVE-2024-27441

Publication date:
13/03/2024
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none.
Severity CVSS v4.0: Pending analysis
Last modification:
13/03/2024

CVE-2024-25155

Publication date:
13/03/2024
In FileCatalyst Direct 3.8.8 and earlier through 3.8.6, the web server does not properly sanitize illegal characters in a URL which is then displayed on a subsequent error page. A malicious actor could craft a URL which would then execute arbitrary code within an HTML script tag. 
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025

CVE-2024-25154

Publication date:
13/03/2024
Improper URL validation leads to path traversal in FileCatalyst Direct 3.8.8 and earlier allowing an encoded payload to cause the web server to return files located outside of the web root which may lead to data leakage.  
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025

CVE-2024-25153

Publication date:
13/03/2024
A directory traversal within the ‘ftpservlet’ of the FileCatalyst Workflow Web Portal allows files to be uploaded outside of the intended ‘uploadtemp’ directory with a specially crafted POST request. In situations where a file is successfully uploaded to web portal’s DocumentRoot, specially crafted JSP files could be used to execute code, including web shells.
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025

CVE-2024-1508

Publication date:
13/03/2024
The Prime Slider – Addons For Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'settings['title_tags']' attribute of the Mercury widget in all versions up to, and including, 3.13.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025

CVE-2024-1507

Publication date:
13/03/2024
The Prime Slider – Addons For Elementor plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'title_tags' attribute of the Rubix widget in all versions up to, and including, 3.13.2 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
Severity CVSS v4.0: Pending analysis
Last modification:
21/01/2025

CVE-2023-52608

Publication date:
13/03/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Check mailbox/SMT channel for consistency<br /> <br /> On reception of a completion interrupt the shared memory area is accessed<br /> to retrieve the message header at first and then, if the message sequence<br /> number identifies a transaction which is still pending, the related<br /> payload is fetched too.<br /> <br /> When an SCMI command times out the channel ownership remains with the<br /> platform until eventually a late reply is received and, as a consequence,<br /> any further transmission attempt remains pending, waiting for the channel<br /> to be relinquished by the platform.<br /> <br /> Once that late reply is received the channel ownership is given back<br /> to the agent and any pending request is then allowed to proceed and<br /> overwrite the SMT area of the just delivered late reply; then the wait<br /> for the reply to the new request starts.<br /> <br /> It has been observed that the spurious IRQ related to the late reply can<br /> be wrongly associated with the freshly enqueued request: when that happens<br /> the SCMI stack in-flight lookup procedure is fooled by the fact that the<br /> message header now present in the SMT area is related to the new pending<br /> transaction, even though the real reply has still to arrive.<br /> <br /> This race-condition on the A2P channel can be detected by looking at the<br /> channel status bits: a genuine reply from the platform will have set the<br /> channel free bit before triggering the completion IRQ.<br /> <br /> Add a consistency check to validate such condition in the A2P ISR.
Severity CVSS v4.0: Pending analysis
Last modification:
25/02/2025

CVE-2024-2247

Publication date:
13/03/2024
JFrog Artifactory versions below 7.77.7, 7.82.1, are vulnerable to DOM-based cross-site scripting due to improper handling of the import override mechanism.
Severity CVSS v4.0: Pending analysis
Last modification:
27/02/2025

CVE-2024-26629

Publication date:
13/03/2024
In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nfsd: fix RELEASE_LOCKOWNER<br /> <br /> The test on so_count in nfsd4_release_lockowner() is nonsense and<br /> harmful. Revert to using check_for_locks(), changing that to not sleep.<br /> <br /> First: harmful.<br /> As is documented in the kdoc comment for nfsd4_release_lockowner(), the<br /> test on so_count can transiently return a false positive resulting in a<br /> return of NFS4ERR_LOCKS_HELD when in fact no locks are held. This is<br /> clearly a protocol violation and with the Linux NFS client it can cause<br /> incorrect behaviour.<br /> <br /> If RELEASE_LOCKOWNER is sent while some other thread is still<br /> processing a LOCK request which failed because, at the time that request<br /> was received, the given owner held a conflicting lock, then the nfsd<br /> thread processing that LOCK request can hold a reference (conflock) to<br /> the lock owner that causes nfsd4_release_lockowner() to return an<br /> incorrect error.<br /> <br /> The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because it<br /> never sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, so<br /> it knows that the error is impossible. It assumes the lock owner was in<br /> fact released so it feels free to use the same lock owner identifier in<br /> some later locking request.<br /> <br /> When it does reuse a lock owner identifier for which a previous RELEASE<br /> failed, it will naturally use a lock_seqid of zero. However the server,<br /> which didn&amp;#39;t release the lock owner, will expect a larger lock_seqid and<br /> so will respond with NFS4ERR_BAD_SEQID.<br /> <br /> So clearly it is harmful to allow a false positive, which testing<br /> so_count allows.<br /> <br /> The test is nonsense because ... well... it doesn&amp;#39;t mean anything.<br /> <br /> so_count is the sum of three different counts.<br /> 1/ the set of states listed on so_stateids<br /> 2/ the set of active vfs locks owned by any of those states<br /> 3/ various transient counts such as for conflicting locks.<br /> <br /> When it is tested against &amp;#39;2&amp;#39; it is clear that one of these is the<br /> transient reference obtained by find_lockowner_str_locked(). It is not<br /> clear what the other one is expected to be.<br /> <br /> In practice, the count is often 2 because there is precisely one state<br /> on so_stateids. If there were more, this would fail.<br /> <br /> In my testing I see two circumstances when RELEASE_LOCKOWNER is called.<br /> In one case, CLOSE is called before RELEASE_LOCKOWNER. That results in<br /> all the lock states being removed, and so the lockowner being discarded<br /> (it is removed when there are no more references which usually happens<br /> when the lock state is discarded). When nfsd4_release_lockowner() finds<br /> that the lock owner doesn&amp;#39;t exist, it returns success.<br /> <br /> The other case shows an so_count of &amp;#39;2&amp;#39; and precisely one state listed<br /> in so_stateid. It appears that the Linux client uses a separate lock<br /> owner for each file resulting in one lock state per lock owner, so this<br /> test on &amp;#39;2&amp;#39; is safe. For another client it might not be safe.<br /> <br /> So this patch changes check_for_locks() to use the (newish)<br /> find_any_file_locked() so that it doesn&amp;#39;t take a reference on the<br /> nfs4_file and so never calls nfsd_file_put(), and so never sleeps. With<br /> this check is it safe to restore the use of check_for_locks() rather<br /> than testing so_count against the mysterious &amp;#39;2&amp;#39;.
Severity CVSS v4.0: Pending analysis
Last modification:
27/02/2025