Export limit exceeded: 346643 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 346643 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (346643 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-47864 | 2026-04-15 | N/A | ||
| home 5G HR02, Wi-Fi STATION SH-52B, and Wi-Fi STATION SH-54C contain a buffer overflow vulnerability in the hidden debug function. A remote unauthenticated attacker may get the web console of the product down. | ||||
| CVE-2024-47865 | 1 Rakuten | 1 Turbo 5g Firmware | 2026-04-15 | 5.3 Medium |
| Missing authentication for critical function vulnerability exists in Rakuten Turbo 5G firmware version V1.3.18 and earlier. If this vulnerability is exploited, a remote unauthenticated attacker may update or downgrade the firmware on the device. | ||||
| CVE-2025-40761 | 1 Siemens | 11 Ruggedcom Rox Mx5000, Ruggedcom Rox Mx5000re, Ruggedcom Rox Rx1400 and 8 more | 2026-04-15 | 7.6 High |
| A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions), RUGGEDCOM ROX MX5000RE (All versions), RUGGEDCOM ROX RX1400 (All versions), RUGGEDCOM ROX RX1500 (All versions), RUGGEDCOM ROX RX1501 (All versions), RUGGEDCOM ROX RX1510 (All versions), RUGGEDCOM ROX RX1511 (All versions), RUGGEDCOM ROX RX1512 (All versions), RUGGEDCOM ROX RX1524 (All versions), RUGGEDCOM ROX RX1536 (All versions), RUGGEDCOM ROX RX5000 (All versions). Affected devices do not properly limit access through its Built-In-Self-Test (BIST) mode. This could allow an attacker with physical access to the serial interface to bypass authentication and get access to a root shell on the device. | ||||
| CVE-2025-68198 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: crash: fix crashkernel resource shrink When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues: 1. Invalid crashkernel resource objects 2. Kernel crash if crashkernel shrinking is done twice For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as: cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel Instead, it should show 50MB: af000000-b21fffff : Crash kernel Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86): BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI <snip...> Call Trace: <TASK> ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 <snip...> This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated. Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory. | ||||
| CVE-2025-40769 | 1 Siemens | 1 Sinec Traffic Analyzer | 2026-04-15 | 7.4 High |
| A vulnerability has been identified in SINEC Traffic Analyzer (6GK8822-1BG01-0BA0) (All versions < V3.0). The affected application uses a Content Security Policy that allows unsafe script execution methods. This could allow an attacker to execute unauthorized scripts, potentially leading to cross-site scripting attacks. | ||||
| CVE-2025-68200 | 1 Linux | 1 Linux Kernel | 2026-04-15 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Add bpf_prog_run_data_pointers() syzbot found that cls_bpf_classify() is able to change tc_skb_cb(skb)->drop_reason triggering a warning in sk_skb_reason_drop(). WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 __sk_skb_reason_drop net/core/skbuff.c:1189 [inline] WARNING: CPU: 0 PID: 5965 at net/core/skbuff.c:1192 sk_skb_reason_drop+0x76/0x170 net/core/skbuff.c:1214 struct tc_skb_cb has been added in commit ec624fe740b4 ("net/sched: Extend qdisc control block with tc control block"), which added a wrong interaction with db58ba459202 ("bpf: wire in data and data_end for cls_act_bpf"). drop_reason was added later. Add bpf_prog_run_data_pointers() helper to save/restore the net_sched storage colliding with BPF data_meta/data_end. | ||||
| CVE-2024-47917 | 2026-04-15 | 7.5 High | ||
| CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') | ||||
| CVE-2024-47918 | 2026-04-15 | 6.1 Medium | ||
| Tiki Wiki CMS – CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) | ||||
| CVE-2024-47910 | 1 Sonarsource | 1 Sonarqube | 2026-04-15 | 7.2 High |
| An issue was discovered in SonarSource SonarQube before 9.9.5 LTA and 10.x before 10.5. A SonarQube user with the Administrator role can modify an existing configuration of a GitHub integration to exfiltrate a pre-signed JWT. | ||||
| CVE-2024-47921 | 2026-04-15 | 8.4 High | ||
| Smadar SPS – CWE-327: Use of a Broken or Risky Cryptographic Algorithm | ||||
| CVE-2024-47923 | 2026-04-15 | 5.3 Medium | ||
| Mashov – CWE-200: Exposure of Sensitive Information to an Unauthorized Actor | ||||
| CVE-2024-47925 | 1 Tecnick | 1 Tcexam | 2026-04-15 | 7.5 High |
| Tecnick TCExam – Multiple CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') | ||||
| CVE-2024-47935 | 2026-04-15 | 6.7 Medium | ||
| Improper Validation of Integrity Check Value vulnerability in TXOne Networks StellarProtect (Legacy Mode), StellarEnforce, and Safe Lock allows an attacker to escalate their privileges in the victim’s device. The attacker needs to hijack the DLL file in advance. This issue affects StellarProtect (Legacy Mode): before 3.2; StellarEnforce: before 3.2; Safe Lock: from 3.0.0 before 3.1.1076. *Note: StellarProtect (Legacy Mode) is the new name for StellarEnforce, they are the same product. | ||||
| CVE-2024-47944 | 1 Rittal Gmbh And Co.kg | 1 Iot Interface And Cmc Iii Processing Unit | 2026-04-15 | 6.8 Medium |
| The device directly executes .patch firmware upgrade files on a USB stick without any prior authentication in the admin interface. This leads to an unauthenticated code execution via the firmware upgrade function. | ||||
| CVE-2024-47947 | 2026-04-15 | 4.7 Medium | ||
| Due to missing input sanitization, an attacker can perform cross-site-scripting attacks and run arbitrary Javascript in the browser of other users. The "Edit Disclaimer Text" function of the configuration menu is vulnerable to stored XSS. Only the users Poweruser and Admin can use this function which is available at the URL https://$SCANNER/cgi/admin.cgi?-rdisclaimer+-apre The stored Javascript payload will be executed every time the ScanWizard is loaded, even in the Kiosk-mode browser. | ||||
| CVE-2024-47972 | 2026-04-15 | 4 Medium | ||
| Improper resource management in firmware of some Solidigm DC Products may allow an attacker to potentially control the performance of the resource. | ||||
| CVE-2024-47973 | 2026-04-15 | 5.1 Medium | ||
| In some Solidigm DC Products, a defect in device overprovisioning may provide information disclosure to an attacker. | ||||
| CVE-2024-47974 | 2026-04-15 | 4.4 Medium | ||
| Race condition during resource shutdown in some Solidigm DC Products may allow an attacker to potentially enable denial of service. | ||||
| CVE-2025-68202 | 1 Linux | 1 Linux Kernel | 2026-04-15 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: sched_ext: Fix unsafe locking in the scx_dump_state() For built with CONFIG_PREEMPT_RT=y kernels, the dump_lock will be converted sleepable spinlock and not disable-irq, so the following scenarios occur: inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. irq_work/0/27 [HC0[0]:SC0[0]:HE1:SE1] takes: (&rq->__lock){?...}-{2:2}, at: raw_spin_rq_lock_nested+0x2b/0x40 {IN-HARDIRQ-W} state was registered at: lock_acquire+0x1e1/0x510 _raw_spin_lock_nested+0x42/0x80 raw_spin_rq_lock_nested+0x2b/0x40 sched_tick+0xae/0x7b0 update_process_times+0x14c/0x1b0 tick_periodic+0x62/0x1f0 tick_handle_periodic+0x48/0xf0 timer_interrupt+0x55/0x80 __handle_irq_event_percpu+0x20a/0x5c0 handle_irq_event_percpu+0x18/0xc0 handle_irq_event+0xb5/0x150 handle_level_irq+0x220/0x460 __common_interrupt+0xa2/0x1e0 common_interrupt+0xb0/0xd0 asm_common_interrupt+0x2b/0x40 _raw_spin_unlock_irqrestore+0x45/0x80 __setup_irq+0xc34/0x1a30 request_threaded_irq+0x214/0x2f0 hpet_time_init+0x3e/0x60 x86_late_time_init+0x5b/0xb0 start_kernel+0x308/0x410 x86_64_start_reservations+0x1c/0x30 x86_64_start_kernel+0x96/0xa0 common_startup_64+0x13e/0x148 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&rq->__lock); <Interrupt> lock(&rq->__lock); *** DEADLOCK *** stack backtrace: CPU: 0 UID: 0 PID: 27 Comm: irq_work/0 Call Trace: <TASK> dump_stack_lvl+0x8c/0xd0 dump_stack+0x14/0x20 print_usage_bug+0x42e/0x690 mark_lock.part.44+0x867/0xa70 ? __pfx_mark_lock.part.44+0x10/0x10 ? string_nocheck+0x19c/0x310 ? number+0x739/0x9f0 ? __pfx_string_nocheck+0x10/0x10 ? __pfx_check_pointer+0x10/0x10 ? kvm_sched_clock_read+0x15/0x30 ? sched_clock_noinstr+0xd/0x20 ? local_clock_noinstr+0x1c/0xe0 __lock_acquire+0xc4b/0x62b0 ? __pfx_format_decode+0x10/0x10 ? __pfx_string+0x10/0x10 ? __pfx___lock_acquire+0x10/0x10 ? __pfx_vsnprintf+0x10/0x10 lock_acquire+0x1e1/0x510 ? raw_spin_rq_lock_nested+0x2b/0x40 ? __pfx_lock_acquire+0x10/0x10 ? dump_line+0x12e/0x270 ? raw_spin_rq_lock_nested+0x20/0x40 _raw_spin_lock_nested+0x42/0x80 ? raw_spin_rq_lock_nested+0x2b/0x40 raw_spin_rq_lock_nested+0x2b/0x40 scx_dump_state+0x3b3/0x1270 ? finish_task_switch+0x27e/0x840 scx_ops_error_irq_workfn+0x67/0x80 irq_work_single+0x113/0x260 irq_work_run_list.part.3+0x44/0x70 run_irq_workd+0x6b/0x90 ? __pfx_run_irq_workd+0x10/0x10 smpboot_thread_fn+0x529/0x870 ? __pfx_smpboot_thread_fn+0x10/0x10 kthread+0x305/0x3f0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x40/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 </TASK> This commit therefore use rq_lock_irqsave/irqrestore() to replace rq_lock/unlock() in the scx_dump_state(). | ||||
| CVE-2024-48073 | 1 Sunniwell | 1 Ht3300 Firmware | 2026-04-15 | 9.8 Critical |
| sunniwell HT3300 before 1.0.0.B022.2 is vulnerable to Insecure Permissions. The /usr/local/bin/update program, which is responsible for updating the software in the HT3300 device, is given the execution mode of sudo NOPASSWD. This program is vulnerable to a command injection vulnerability, which could allow an attacker to pass commands to this program via command line arguments to gain elevated root privileges. | ||||