Export limit exceeded: 364878 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (364878 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-65941 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-65940 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-65939 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-65938 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-65937 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-65936 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-65935 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-65934 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-65933 | 2025-11-19 | N/A | ||
| Not used | ||||
| CVE-2025-34157 | 1 Coollabs | 1 Coolify | 2025-11-19 | 9.0 Critical |
| Coolify versions prior to v4.0.0-beta.420.6 are vulnerable to a stored cross-site scripting (XSS) attack in the project creation workflow. An authenticated user with low privileges can create a project with a maliciously crafted name containing embedded JavaScript. When an administrator attempts to delete the project or its associated resource, the payload executes in the admin’s browser context. This results in full compromise of the Coolify instance, including theft of API tokens, session cookies, and access to WebSocket-based terminal sessions on managed servers. | ||||
| CVE-2025-34159 | 1 Coollabs | 1 Coolify | 2025-11-19 | 8.8 High |
| Coolify versions prior to v4.0.0-beta.420.6 are vulnerable to a remote code execution vulnerability in the application deployment workflow. The platform allows authenticated users, with low-level member privileges, to inject arbitrary Docker Compose directives during project creation. By crafting a malicious service definition that mounts the host root filesystem, an attacker can gain full root access to the underlying server. | ||||
| CVE-2025-34161 | 1 Coollabs | 1 Coolify | 2025-11-19 | 8.8 High |
| Coolify versions prior to v4.0.0-beta.420.7 are vulnerable to a remote code execution vulnerability in the project deployment workflow. The platform allows authenticated users, with low-level member privileges, to inject arbitrary shell commands via the Git Repository field during project creation. By submitting a crafted repository string containing command injection syntax, an attacker can execute arbitrary commands on the underlying host system, resulting in full server compromise. | ||||
| CVE-2025-34267 | 1 Flowiseai | 1 Flowise | 2025-11-19 | 9.9 Critical |
| Flowise v3.0.1 < 3.0.8 and all versions after with 'ALLOW_BUILTIN_DEP' enabled contain an authenticated remote code execution vulnerability and node VM sandbox escape due to insecure use of integrated modules (Puppeteer and Playwright) within the nodevm execution environment. An authenticated attacker able to create or run a tool that leverages Puppeteer/Playwright can specify attacker-controlled browser binary paths and parameters. When the tool executes, the attacker-controlled executable/parameters are run on the host and circumvent the intended nodevm sandbox restrictions, resulting in execution of arbitrary code in the context of the host. This vulnerability was incorrectly assigned as a duplicate CVE-2025-26319 by the developers and should be considered distinct from that identifier. | ||||
| CVE-2025-34282 | 1 Thingsboard | 1 Thingsboard | 2025-11-19 | 9.1 Critical |
| ThingsBoard versions < 4.2.1 contain a server-side request forgery (SSRF) vulnerability in the dashboard's Image Upload Gallery feature. An attacker can upload a malicious SVG file that references a remote URL. If the server processes the SVG file in a way that parses external references, it may initiate unintended outbound requests. This can be used to access internal services or resources. | ||||
| CVE-2025-34489 | 1 Gfi | 1 Mailessentials | 2025-11-19 | 7.8 High |
| GFI MailEssentials prior to version 21.8 is vulnerable to a local privilege escalation issue. A local attacker can escalate to NT Authority/SYSTEM by sending a crafted serialized payload to a .NET Remoting Service. | ||||
| CVE-2025-34490 | 1 Gfi | 1 Mailessentials | 2025-11-19 | 6.5 Medium |
| GFI MailEssentials prior to version 21.8 is vulnerable to an XML External Entity (XXE) issue. An authenticated and remote attacker can send crafted HTTP requests to read arbitrary system files. | ||||
| CVE-2025-34491 | 1 Gfi | 1 Mailessentials | 2025-11-19 | 8.8 High |
| GFI MailEssentials prior to version 21.8 is vulnerable to a .NET deserialization issue. A remote and authenticated attacker can execute arbitrary code by sending crafted serialized .NET when joining to a Multi-Server setup. | ||||
| CVE-2023-51767 | 3 Fedoraproject, Openbsd, Redhat | 3 Fedora, Openssh, Enterprise Linux | 2025-11-18 | 7 High |
| OpenSSH through 10.0, when common types of DRAM are used, might allow row hammer attacks (for authentication bypass) because the integer value of authenticated in mm_answer_authpassword does not resist flips of a single bit. NOTE: this is applicable to a certain threat model of attacker-victim co-location in which the attacker has user privileges. NOTE: this is disputed by the Supplier, who states "we do not consider it to be the application's responsibility to defend against platform architectural weaknesses." | ||||
| CVE-2025-38525 | 1 Linux | 1 Linux Kernel | 2025-11-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix irq-disabled in local_bh_enable() The rxrpc_assess_MTU_size() function calls down into the IP layer to find out the MTU size for a route. When accepting an incoming call, this is called from rxrpc_new_incoming_call() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses local_bh_enable() which, config dependent, throws a warning if IRQs are enabled: WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0 ... RIP: 0010:__local_bh_enable_ip+0x43/0xd0 ... Call Trace: <TASK> rt_cache_route+0x7e/0xa0 rt_set_nexthop.isra.0+0x3b3/0x3f0 __mkroute_output+0x43a/0x460 ip_route_output_key_hash+0xf7/0x140 ip_route_output_flow+0x1b/0x90 rxrpc_assess_MTU_size.isra.0+0x2a0/0x590 rxrpc_new_incoming_peer+0x46/0x120 rxrpc_alloc_incoming_call+0x1b1/0x400 rxrpc_new_incoming_call+0x1da/0x5e0 rxrpc_input_packet+0x827/0x900 rxrpc_io_thread+0x403/0xb60 kthread+0x2f7/0x310 ret_from_fork+0x2a/0x230 ret_from_fork_asm+0x1a/0x30 ... hardirqs last enabled at (23): _raw_spin_unlock_irq+0x24/0x50 hardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70 softirqs last enabled at (0): copy_process+0xc61/0x2730 softirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90 Fix this by moving the call to rxrpc_assess_MTU_size() out of rxrpc_init_peer() and further up the stack where it can be done without interrupts disabled. It shouldn't be a problem for rxrpc_new_incoming_call() to do it after the locks are dropped as pmtud is going to be performed by the I/O thread - and we're in the I/O thread at this point. | ||||
| CVE-2025-38524 | 1 Linux | 1 Linux Kernel | 2025-11-18 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix recv-recv race of completed call If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->user_mutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again. In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->user_mutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control message). The first thread will return okay, but then the second thread will wake up holding the user_mutex and, if it sees that the call has been released by the first thread, it will BUG thusly: kernel BUG at net/rxrpc/recvmsg.c:474! Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale. | ||||