Export limit exceeded: 36450 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (36450 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-2476 | 1 Mattermost | 1 Ms Teams | 2026-03-30 | 7.6 High |
| Mattermost Plugins versions <=2.0.3.0 fail to properly mask sensitive configuration values which allows an attacker with access to support packets to obtain original plugin settings via exported configuration data. Mattermost Advisory ID: MMSA-2026-00606 | ||||
| CVE-2026-33062 | 1 Free5gc | 2 Free5gc, Nrf | 2026-03-27 | 7.5 High |
| free5GC is an open source 5G core network. free5GC NRF prior to version 1.4.2 has an Improper Input Validation vulnerability leading to Denial of Service. All deployments of free5GC using the NRF discovery service are affected. The `EncodeGroupId` function attempts to access array indices [0], [1], [2] without validating the length of the split data. When the parameter contains insufficient separator characters, the code panics with "index out of range". A remote attacker can cause the NRF service to panic and crash by sending a crafted HTTP GET request with a malformed `group-id-list` parameter. This results in complete denial of service for the NRF discovery service. free5GC NRF version 1.4.2 fixes the issue. There is no direct workaround at the application level. The recommendation is to apply the provided patch or restrict access to the NRF API to trusted sources only. | ||||
| CVE-2026-33473 | 2 Go-vikunja, Vikunja | 2 Vikunja, Vikunja | 2026-03-27 | 5.7 Medium |
| Vikunja is an open-source self-hosted task management platform. Starting in version 0.13 and prior to version 2.2.1, any user that has enabled 2FA can have their TOTP reused during the standard 30 second validity window. Version 2.2.1 patches the issue. | ||||
| CVE-2026-33677 | 2 Go-vikunja, Vikunja | 2 Vikunja, Vikunja | 2026-03-27 | 6.5 Medium |
| Vikunja is an open-source self-hosted task management platform. Prior to version 2.2.1, the `GET /api/v1/projects/:project/webhooks` endpoint returns webhook BasicAuth credentials (`basic_auth_user` and `basic_auth_password`) in plaintext to any user with read access to the project. While the existing code correctly masks the HMAC `secret` field, the BasicAuth fields added in a later migration were not given the same treatment. This allows read-only collaborators to steal credentials intended for authenticating against external webhook receivers. Version 2.2.1 patches the issue. | ||||
| CVE-2024-42835 | 1 Langflow | 1 Langflow | 2026-03-27 | 9.8 Critical |
| langflow v1.0.12 was discovered to contain a remote code execution (RCE) vulnerability via the PythonCodeTool component. | ||||
| CVE-2024-9781 | 1 Wireshark | 1 Wireshark | 2026-03-27 | 7.8 High |
| AppleTalk and RELOAD Framing dissector crash in Wireshark 4.4.0 and 4.2.0 to 4.2.7 allows denial of service via packet injection or crafted capture file | ||||
| CVE-2026-4755 | 1 Molotovcherry | 1 Android-imagemagick7 | 2026-03-27 | 9.8 Critical |
| CWE-20 vulnerability in MolotovCherry Android-ImageMagick7.This issue affects Android-ImageMagick7: before 7.1.2-11. | ||||
| CVE-2026-33509 | 2 Pyload, Pyload-ng Project | 2 Pyload, Pyload-ng | 2026-03-27 | 7.5 High |
| pyLoad is a free and open-source download manager written in Python. From version 0.4.0 to before version 0.5.0b3.dev97, the set_config_value() API endpoint allows users with the non-admin SETTINGS permission to modify any configuration option without restriction. The reconnect.script config option controls a file path that is passed directly to subprocess.run() in the thread manager's reconnect logic. A SETTINGS user can set this to any executable file on the system, achieving Remote Code Execution. The only validation in set_config_value() is a hardcoded check for general.storage_folder — all other security-critical settings including reconnect.script are writable without any allowlist or path restriction. This issue has been patched in version 0.5.0b3.dev97. | ||||
| CVE-2025-9907 | 1 Redhat | 6 Ansible Automation Platform, Ansible Automation Platform Developer, Ansible Automation Platform Inside and 3 more | 2026-03-26 | 6.7 Medium |
| A flaw was found in the Red Hat Ansible Automation Platform, Event-Driven Ansible (EDA) Event Stream API. This vulnerability allows exposure of sensitive client credentials and internal infrastructure headers via the test_headers field when an event stream is in test mode. The possible outcome includes leakage of internal infrastructure details, accidental disclosure of user or system credentials, privilege escalation if high-value tokens are exposed, and persistent sensitive data exposure to all users with read access on the event stream. | ||||
| CVE-2026-30653 | 1 Free5gc | 1 Free5gc | 2026-03-25 | 7.5 High |
| An issue in Free5GC v.4.2.0 and before allows a remote attacker to cause a denial of service via the function HandleAuthenticationFailure of the component AMF | ||||
| CVE-2025-9908 | 1 Redhat | 6 Ansible Automation Platform, Ansible Automation Platform Developer, Ansible Automation Platform Inside and 3 more | 2026-03-25 | 6.7 Medium |
| A flaw was found in the Red Hat Ansible Automation Platform, Event-Driven Ansible (EDA) Event Streams. This vulnerability allows an authenticated user to gain access to sensitive internal infrastructure headers (such as X-Trusted-Proxy and X-Envoy-*) and event stream URLs via crafted requests and job templates. By exfiltrating these headers, an attacker could spoof trusted requests, escalate privileges, or perform malicious event injection. | ||||
| CVE-2025-71180 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: counter: interrupt-cnt: Drop IRQF_NO_THREAD flag An IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as CONFIG_PROVE_RAW_LOCK_NESTING warns: ============================= [ BUG: Invalid wait context ] 6.18.0-rc1+git... #1 ----------------------------- some-user-space-process/1251 is trying to lock: (&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter] other info that might help us debug this: context-{2:2} no locks held by some-user-space-process/.... stack backtrace: CPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT Call trace: show_stack (C) dump_stack_lvl dump_stack __lock_acquire lock_acquire _raw_spin_lock_irqsave counter_push_event [counter] interrupt_cnt_isr [interrupt_cnt] __handle_irq_event_percpu handle_irq_event handle_simple_irq handle_irq_desc generic_handle_domain_irq gpio_irq_handler handle_irq_desc generic_handle_domain_irq gic_handle_irq call_on_irq_stack do_interrupt_handler el0_interrupt __el0_irq_handler_common el0t_64_irq_handler el0t_64_irq ... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an alternative to switching to raw_spinlock_t, because the latter would limit all potential nested locks to raw_spinlock_t only. | ||||
| CVE-2025-71076 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Limit num_syncs to prevent oversized allocations The OA open parameters did not validate num_syncs, allowing userspace to pass arbitrarily large values, potentially leading to excessive allocations. Add check to ensure that num_syncs does not exceed DRM_XE_MAX_SYNCS, returning -EINVAL when the limit is violated. v2: use XE_IOCTL_DBG() and drop duplicated check. (Ashutosh) (cherry picked from commit e057b2d2b8d815df3858a87dffafa2af37e5945b) | ||||
| CVE-2025-71102 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: scs: fix a wrong parameter in __scs_magic __scs_magic() needs a 'void *' variable, but a 'struct task_struct *' is given. 'task_scs(tsk)' is the starting address of the task's shadow call stack, and '__scs_magic(task_scs(tsk))' is the end address of the task's shadow call stack. Here should be '__scs_magic(task_scs(tsk))'. The user-visible effect of this bug is that when CONFIG_DEBUG_STACK_USAGE is enabled, the shadow call stack usage checking function (scs_check_usage) would scan an incorrect memory range. This could lead 1. **Inaccurate stack usage reporting**: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg. 2. **Potential kernel crash**: If the value of __scs_magic(tsk)is greater than that of __scs_magic(task_scs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because task_struct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by task_scs(tsk) is allocated via vmalloc(which typically returns higher addresses). However, since this is purely a debugging feature (CONFIG_DEBUG_STACK_USAGE), normal production systems should be not unaffected. The bug only impacts developers and testers who are actively debugging stack usage with this configuration enabled. | ||||
| CVE-2025-71105 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: f2fs: use global inline_xattr_slab instead of per-sb slab cache As Hong Yun reported in mailing list: loop7: detected capacity change from 0 to 131072 ------------[ cut here ]------------ kmem_cache of name 'f2fs_xattr_entry-7:7' already exists WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline] WARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307 CPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline] RIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307 Call Trace: __kmem_cache_create include/linux/slab.h:353 [inline] f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline] f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843 f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918 get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692 vfs_get_tree+0x43/0x140 fs/super.c:1815 do_new_mount+0x201/0x550 fs/namespace.c:3808 do_mount fs/namespace.c:4136 [inline] __do_sys_mount fs/namespace.c:4347 [inline] __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline] do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94 entry_SYSCALL_64_after_hwframe+0x76/0x7e The bug can be reproduced w/ below scripts: - mount /dev/vdb /mnt1 - mount /dev/vdc /mnt2 - umount /mnt1 - mounnt /dev/vdb /mnt1 The reason is if we created two slab caches, named f2fs_xattr_entry-7:3 and f2fs_xattr_entry-7:7, and they have the same slab size. Actually, slab system will only create one slab cache core structure which has slab name of "f2fs_xattr_entry-7:3", and two slab caches share the same structure and cache address. So, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it will decrease reference count of slab cache, rather than release slab cache entirely, since there is one more user has referenced the cache. Then, if we try to create slab cache w/ name "f2fs_xattr_entry-7:3" again, slab system will find that there is existed cache which has the same name and trigger the warning. Let's changes to use global inline_xattr_slab instead of per-sb slab cache for fixing. | ||||
| CVE-2025-71106 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs: PM: Fix reverse check in filesystems_freeze_callback() The freeze_all_ptr check in filesystems_freeze_callback() introduced by commit a3f8f8662771 ("power: always freeze efivarfs") is reverse which quite confusingly causes all file systems to be frozen when filesystem_freeze_enabled is false. On my systems it causes the WARN_ON_ONCE() in __set_task_frozen() to trigger, most likely due to an attempt to freeze a file system that is not ready for that. Add a logical negation to the check in question to reverse it as appropriate. | ||||
| CVE-2025-71129 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: LoongArch: BPF: Sign extend kfunc call arguments The kfunc calls are native calls so they should follow LoongArch calling conventions. Sign extend its arguments properly to avoid kernel panic. This is done by adding a new emit_abi_ext() helper. The emit_abi_ext() helper performs extension in place meaning a value already store in the target register (Note: this is different from the existing sign_extend() helper and thus we can't reuse it). | ||||
| CVE-2025-71119 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: powerpc/kexec: Enable SMT before waking offline CPUs If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed: kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core_64.c:223 kexec_prepare_cpus+0x1b0/0x1bc [snip] NIP kexec_prepare_cpus+0x1b0/0x1bc LR kexec_prepare_cpus+0x1a0/0x1bc Call Trace: kexec_prepare_cpus+0x1a0/0x1bc (unreliable) default_machine_kexec+0x160/0x19c machine_kexec+0x80/0x88 kernel_kexec+0xd0/0x118 __do_sys_reboot+0x210/0x2c4 system_call_exception+0x124/0x320 system_call_vectored_common+0x15c/0x2ec This occurs as add_cpu() fails due to cpu_bootable() returning false for CPUs that fail the cpu_smt_thread_allowed() check or non primary threads if SMT is disabled. Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs. | ||||
| CVE-2025-71121 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: parisc: Do not reprogram affinitiy on ASP chip The ASP chip is a very old variant of the GSP chip and is used e.g. in HP 730 workstations. When trying to reprogram the affinity it will crash with a HPMC as the relevant registers don't seem to be at the usual location. Let's avoid the crash by checking the sversion. Also note, that reprogramming isn't necessary either, as the HP730 is a just a single-CPU machine. | ||||
| CVE-2025-71122 | 1 Linux | 1 Linux Kernel | 2026-03-25 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: iommufd/selftest: Check for overflow in IOMMU_TEST_OP_ADD_RESERVED syzkaller found it could overflow math in the test infrastructure and cause a WARN_ON by corrupting the reserved interval tree. This only effects test kernels with CONFIG_IOMMUFD_TEST. Validate the user input length in the test ioctl. | ||||