Search

Search Results (331597 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2023-6425 1 Bigprof 1 Online Clinic Management System 2026-02-06 6.3 Medium
A vulnerability has been discovered in BigProf Online Clinic Management System 2.2, which does not sufficiently encode user-controlled input, resulting in persistent XSS through /clinic/medical_records_view.php, in the FirstRecord parameter. Exploitation of this vulnerability could allow an attacking user to store dangerous JavaScript payloads on the system that will be triggered when the page loads.
CVE-2022-40924 1 Phpgurukul 1 Zoo Management System 2026-02-06 7.2 High
Zoo Management System v1.0 has an arbitrary file upload vulnerability in the picture upload point of the "save_animal" file of the "Animals" module in the background management system.
CVE-2025-15335 1 Tanium 1 Service Threatresponse 2026-02-06 4.3 Medium
Tanium addressed an information disclosure vulnerability in Threat Response.
CVE-2025-15334 1 Tanium 1 Service Threatresponse 2026-02-06 4.3 Medium
Tanium addressed an information disclosure vulnerability in Threat Response.
CVE-2026-24883 2 Gnupg, Gpg4win 2 Gnupg, Gpg4win 2026-02-06 3.7 Low
In GnuPG before 2.5.17, a long signature packet length causes parse_signature to return success with sig->data[] set to a NULL value, leading to a denial of service (application crash).
CVE-2026-24882 2 Gnupg, Gpg4win 2 Gnupg, Gpg4win 2026-02-06 8.4 High
In GnuPG before 2.5.17, a stack-based buffer overflow exists in tpm2daemon during handling of the PKDECRYPT command for TPM-backed RSA and ECC keys.
CVE-2026-0537 1 Autodesk 1 3ds Max 2026-02-06 7.8 High
A maliciously crafted RGB file, when parsed through Autodesk 3ds Max, can force a Memory Corruption vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process.
CVE-2026-0538 1 Autodesk 1 3ds Max 2026-02-06 7.8 High
A maliciously crafted GIF file, when parsed through Autodesk 3ds Max, can force an Out-of-Bounds Write vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process.
CVE-2024-37385 2 Microsoft, Roundcube 3 Windows, Roundcube Webmail, Webmail 2026-02-06 9.8 Critical
Roundcube Webmail before 1.5.7 and 1.6.x before 1.6.7 on Windows allows command injection via im_convert_path and im_identify_path. NOTE: this issue exists because of an incomplete fix for CVE-2020-12641.
CVE-2026-0660 1 Autodesk 1 3ds Max 2026-02-06 7.8 High
A maliciously crafted GIF file, when parsed through Autodesk 3ds Max, can cause a Stack-Based Buffer Overflow vulnerability. A malicious actor can leverage this vulnerability to execute arbitrary code in the context of the current process.
CVE-2026-1504 1 Google 1 Chrome 2026-02-06 6.5 Medium
Inappropriate implementation in Background Fetch API in Google Chrome prior to 144.0.7559.110 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: High)
CVE-2025-15333 1 Tanium 1 Service Threatresponse 2026-02-06 4.3 Medium
Tanium addressed an information disclosure vulnerability in Threat Response.
CVE-2026-0227 2 Palo Alto Networks, Paloaltonetworks 5 Cloud Ngfw, Pan-os, Prisma Access and 2 more 2026-02-06 7.5 High
A vulnerability in Palo Alto Networks PAN-OS software enables an unauthenticated attacker to cause a denial of service (DoS) to the firewall. Repeated attempts to trigger this issue results in the firewall entering into maintenance mode.
CVE-2025-15321 1 Tanium 1 Tanos 2026-02-06 2.7 Low
Tanium addressed an improper input validation vulnerability in Tanium Appliance.
CVE-2025-15332 1 Tanium 1 Service Threatresponse 2026-02-06 4.9 Medium
Tanium addressed an information disclosure vulnerability in Threat Response.
CVE-2026-24925 2026-02-06 7.3 High
Heap-based buffer overflow vulnerability in the image module. Impact: Successful exploitation of this vulnerability may affect availability.
CVE-2025-14512 2 Gnome, Redhat 3 Glib, Enterprise Linux, Openshift 2026-02-06 6.5 Medium
A flaw was found in glib. This vulnerability allows a heap buffer overflow and denial-of-service (DoS) via an integer overflow in GLib's GIO (GLib Input/Output) escape_byte_string() function when processing malicious file or remote filesystem attribute values.
CVE-2026-23110 1 Linux 1 Linux Kernel 2026-02-06 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: scsi: core: Wake up the error handler when final completions race against each other The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance. First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count. This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands. Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task. This needs the call to scsi_host_busy() to be moved after host_failed is incremented to close the race condition.
CVE-2026-23108 1 Linux 1 Linux Kernel 2026-02-06 7.0 High
In the Linux kernel, the following vulnerability has been resolved: can: usb_8dev: usb_8dev_read_bulk_callback(): fix URB memory leak Fix similar memory leak as in commit 7352e1d5932a ("can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak"). In usb_8dev_open() -> usb_8dev_start(), the URBs for USB-in transfers are allocated, added to the priv->rx_submitted anchor and submitted. In the complete callback usb_8dev_read_bulk_callback(), the URBs are processed and resubmitted. In usb_8dev_close() -> unlink_all_urbs() the URBs are freed by calling usb_kill_anchored_urbs(&priv->rx_submitted). However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usb_kill_anchored_urbs(). Fix the memory leak by anchoring the URB in the usb_8dev_read_bulk_callback() to the priv->rx_submitted anchor.
CVE-2026-23107 1 Linux 1 Linux Kernel 2026-02-06 7.0 High
In the Linux kernel, the following vulnerability has been resolved: arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA The code to restore a ZA context doesn't attempt to allocate the task's sve_state before setting TIF_SME. Consequently, restoring a ZA context can place a task into an invalid state where TIF_SME is set but the task's sve_state is NULL. In legitimate but uncommon cases where the ZA signal context was NOT created by the kernel in the context of the same task (e.g. if the task is saved/restored with something like CRIU), we have no guarantee that sve_state had been allocated previously. In these cases, userspace can enter streaming mode without trapping while sve_state is NULL, causing a later NULL pointer dereference when the kernel attempts to store the register state: | # ./sigreturn-za | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000046 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x06: level 2 translation fault | Data abort info: | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00 | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000 | Internal error: Oops: 0000000096000046 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : sve_save_state+0x4/0xf0 | lr : fpsimd_save_user_state+0xb0/0x1c0 | sp : ffff80008070bcc0 | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000 | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020 | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0 | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440 | Call trace: | sve_save_state+0x4/0xf0 (P) | fpsimd_thread_switch+0x48/0x198 | __switch_to+0x20/0x1c0 | __schedule+0x36c/0xce0 | schedule+0x34/0x11c | exit_to_user_mode_loop+0x124/0x188 | el0_interrupt+0xc8/0xd8 | __el0_irq_handler_common+0x18/0x24 | el0t_64_irq_handler+0x10/0x1c | el0t_64_irq+0x198/0x19c | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ end trace 0000000000000000 ]--- Fix this by having restore_za_context() ensure that the task's sve_state is allocated, matching what we do when taking an SME trap. Any live SVE/SSVE state (which is restored earlier from a separate signal context) must be preserved, and hence this is not zeroed.