Export limit exceeded: 402198 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (402198 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-21726 | 1 Grafana | 1 Loki | 2026-04-24 | 5.3 Medium |
| The CVE-2021-36156 fix validates the namespace parameter for path traversal sequences after a single URL decode, by double encoding, an attacker can read files at the Ruler API endpoint /loki/api/v1/rules/{namespace} Thanks to Prasanth Sundararajan for reporting this vulnerability. | ||||
| CVE-2026-27876 | 1 Grafana | 2 Grafana, Grafana Enterprise | 2026-04-24 | 9.1 Critical |
| A chained attack via SQL Expressions and a Grafana Enterprise plugin can lead to a remote arbitrary code execution impact (RCE). This is enabled by a feature in Grafana (OSS), so all users are always recommended to update to avoid future attack vectors going this path. Only instances with the sqlExpressions feature toggle enabled are vulnerable. Only instances in the following version ranges are affected: - 11.6.0 (inclusive) to 11.6.14 (exclusive): 11.6.14 has the fix. 11.5 and below are not affected. - 12.0.0 (inclusive) to 12.1.10 (exclusive): 12.1.10 has the fix. 12.0 did not receive an update, as it is end-of-life. - 12.2.0 (inclusive) to 12.2.8 (exclusive): 12.2.8 has the fix. - 12.3.0 (inclusive) to 12.3.6 (exclusive): 12.3.6 has the fix. - 12.4.0 (inclusive) to 12.4.2 (exclusive): 12.4.2 has the fix. 13.0.0 and above also have the fix: no v13 release is affected. | ||||
| CVE-2026-28375 | 1 Grafana | 1 Grafana | 2026-04-24 | 6.5 Medium |
| A testdata data-source can be used to trigger out-of-memory crashes in Grafana. | ||||
| CVE-2026-21725 | 1 Grafana | 1 Grafana | 2026-04-24 | 2.6 Low |
| A time-of-create-to-time-of-use (TOCTOU) vulnerability lets recently deleted-then-recreated data sources be re-deleted without permission to do so. This requires several very stringent conditions to be met: - The attacker must have admin access to the specific datasource prior to its first deletion. - Upon deletion, all steps within the attack must happen within the next 30 seconds and on the same pod of Grafana. - The attacker must delete the datasource, then someone must recreate it. - The new datasource must not have the attacker as an admin. - The new datasource must have the same UID as the prior datasource. These are randomised by default. - The datasource can now be re-deleted by the attacker. - Once 30 seconds are up, the attack is spent and cannot be repeated. - No datasource with any other UID can be attacked. | ||||
| CVE-2024-4024 | 1 Gitlab | 1 Gitlab | 2026-04-24 | 7.3 High |
| An issue has been discovered in GitLab CE/EE affecting all versions starting from 7.8 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1. Under certain conditions, an attacker with their Bitbucket account credentials may be able to take over a GitLab account linked to another user's Bitbucket account, if Bitbucket is used as an OAuth 2.0 provider on GitLab. | ||||
| CVE-2024-4006 | 1 Gitlab | 1 Gitlab | 2026-04-24 | 4.3 Medium |
| An issue has been discovered in GitLab CE/EE affecting all versions starting from 16.7 before 16.9.6, all versions starting from 16.10 before 16.10.4, all versions starting from 16.11 before 16.11.1 where personal access scopes were not honored by GraphQL subscriptions | ||||
| CVE-2024-1525 | 1 Gitlab | 1 Gitlab | 2026-04-24 | 5.3 Medium |
| An issue has been discovered in GitLab CE/EE affecting all versions starting from 16.1 before 16.7.6, all versions starting from 16.8 before 16.8.3, all versions starting from 16.9 before 16.9.1. Under some specialized conditions, an LDAP user may be able to reset their password using their verified secondary email address and sign-in using direct authentication with the reset password, bypassing LDAP. | ||||
| CVE-2023-6840 | 1 Gitlab | 1 Gitlab | 2026-04-24 | 6.7 Medium |
| An issue has been discovered in GitLab EE affecting all versions from 16.4 prior to 16.6.7, 16.7 prior to 16.7.5, and 16.8 prior to 16.8.2 which allows a maintainer to change the name of a protected branch that bypasses the security policy added to block MR. | ||||
| CVE-2023-6736 | 1 Gitlab | 1 Gitlab | 2026-04-24 | 6.5 Medium |
| An issue has been discovered in GitLab EE affecting all versions starting from 11.3 before 16.7.6, all versions starting from 16.8 before 16.8.3, all versions starting from 16.9 before 16.9.1. It was possible for an attacker to cause a client-side denial of service using malicious crafted content in the CODEOWNERS file. | ||||
| CVE-2023-4378 | 1 Gitlab | 1 Gitlab | 2026-04-24 | 5.5 Medium |
| An issue has been discovered in GitLab CE/EE affecting all versions starting from 11.8 before 16.1.5, all versions starting from 16.2 before 16.2.5, all versions starting from 16.3 before 16.3.1. A malicious Maintainer can, under specific circumstances, leak the sentry token by changing the configured URL in the Sentry error tracking settings page. This was as a result of an incomplete fix for CVE-2022-4365. | ||||
| CVE-2026-39987 | 2 Coreweave, Marimo-team | 2 Marimo, Marimo | 2026-04-24 | 9.8 Critical |
| marimo is a reactive Python notebook. Prior to 0.23.0, Marimo has a Pre-Auth RCE vulnerability. The terminal WebSocket endpoint /terminal/ws lacks authentication validation, allowing an unauthenticated attacker to obtain a full PTY shell and execute arbitrary system commands. Unlike other WebSocket endpoints (e.g., /ws) that correctly call validate_auth() for authentication, the /terminal/ws endpoint only checks the running mode and platform support before accepting connections, completely skipping authentication verification. This vulnerability is fixed in 0.23.0. | ||||
| CVE-2026-4922 | 1 Gitlab | 1 Gitlab | 2026-04-24 | 8.1 High |
| GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.0 before 18.9.6, 18.10 before 18.10.4, and 18.11 before 18.11.1 that could have allowed an unauthenticated user to execute GraphQL mutations on behalf of authenticated users due to insufficient CSRF protection. | ||||
| CVE-2025-24934 | 1 Freebsd | 1 Freebsd | 2026-04-24 | 5.4 Medium |
| Software which sets SO_REUSEPORT_LB on a socket and then connects it to a host will not directly observe any problems. However, due to its membership in a load-balancing group, that socket will receive packets originating from any host. This breaks the contract of the connect(2) and implied connect via sendto(2), and may leave the application vulnerable to spoofing attacks. The kernel failed to check the connection state of sockets when adding them to load-balancing groups. Furthermore, when looking up the destination socket for an incoming packet, the kernel will match a socket belonging to a load-balancing group even if it is connected, in violation of the contract that connected sockets are only supposed to receive packets originating from the connected host. | ||||
| CVE-2026-23337 | 1 Linux | 1 Linux Kernel | 2026-04-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: pinctrl: pinconf-generic: Fix memory leak in pinconf_generic_parse_dt_config() In pinconf_generic_parse_dt_config(), if parse_dt_cfg() fails, it returns directly. This bypasses the cleanup logic and results in a memory leak of the cfg buffer. Fix this by jumping to the out label on failure, ensuring kfree(cfg) is called before returning. | ||||
| CVE-2026-23338 | 1 Linux | 1 Linux Kernel | 2026-04-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/userq: Do not allow userspace to trivially triger kernel warnings Userspace can either deliberately pass in the too small num_fences, or the required number can legitimately grow between the two calls to the userq wait ioctl. In both cases we do not want the emit the kernel warning backtrace since nothing is wrong with the kernel and userspace will simply get an errno reported back. So lets simply drop the WARN_ONs. (cherry picked from commit 2c333ea579de6cc20ea7bc50e9595ef72863e65c) | ||||
| CVE-2026-23342 | 1 Linux | 1 Linux Kernel | 2026-04-23 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix race in cpumap on PREEMPT_RT On PREEMPT_RT kernels, the per-CPU xdp_bulk_queue (bq) can be accessed concurrently by multiple preemptible tasks on the same CPU. The original code assumes bq_enqueue() and __cpu_map_flush() run atomically with respect to each other on the same CPU, relying on local_bh_disable() to prevent preemption. However, on PREEMPT_RT, local_bh_disable() only calls migrate_disable() (when PREEMPT_RT_NEEDS_BH_LOCK is not set) and does not disable preemption, which allows CFS scheduling to preempt a task during bq_flush_to_queue(), enabling another task on the same CPU to enter bq_enqueue() and operate on the same per-CPU bq concurrently. This leads to several races: 1. Double __list_del_clearprev(): after bq->count is reset in bq_flush_to_queue(), a preempting task can call bq_enqueue() -> bq_flush_to_queue() on the same bq when bq->count reaches CPU_MAP_BULK_SIZE. Both tasks then call __list_del_clearprev() on the same bq->flush_node, the second call dereferences the prev pointer that was already set to NULL by the first. 2. bq->count and bq->q[] races: concurrent bq_enqueue() can corrupt the packet queue while bq_flush_to_queue() is processing it. The race between task A (__cpu_map_flush -> bq_flush_to_queue) and task B (bq_enqueue -> bq_flush_to_queue) on the same CPU: Task A (xdp_do_flush) Task B (cpu_map_enqueue) ---------------------- ------------------------ bq_flush_to_queue(bq) spin_lock(&q->producer_lock) /* flush bq->q[] to ptr_ring */ bq->count = 0 spin_unlock(&q->producer_lock) bq_enqueue(rcpu, xdpf) <-- CFS preempts Task A --> bq->q[bq->count++] = xdpf /* ... more enqueues until full ... */ bq_flush_to_queue(bq) spin_lock(&q->producer_lock) /* flush to ptr_ring */ spin_unlock(&q->producer_lock) __list_del_clearprev(flush_node) /* sets flush_node.prev = NULL */ <-- Task A resumes --> __list_del_clearprev(flush_node) flush_node.prev->next = ... /* prev is NULL -> kernel oops */ Fix this by adding a local_lock_t to xdp_bulk_queue and acquiring it in bq_enqueue() and __cpu_map_flush(). These paths already run under local_bh_disable(), so use local_lock_nested_bh() which on non-RT is a pure annotation with no overhead, and on PREEMPT_RT provides a per-CPU sleeping lock that serializes access to the bq. To reproduce, insert an mdelay(100) between bq->count = 0 and __list_del_clearprev() in bq_flush_to_queue(), then run reproducer provided by syzkaller. | ||||
| CVE-2026-33797 | 2 Juniper, Juniper Networks | 4 Junos, Junos Os Evolved, Junos Os and 1 more | 2026-04-23 | 7.4 High |
| An Improper Input Validation vulnerability in Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, adjacent attacker, sending a specific genuine BGP packet in an already established BGP session to reset only that session causing a Denial of Service (DoS). An attacker repeatedly sending the packet will sustain the Denial of Service (DoS).This issue affects Junos OS: * 25.2 versions before 25.2R2 This issue does not affect Junos OS versions before 25.2R1. This issue affects Junos OS Evolved: * 25.2-EVO versions before 25.2R2-EVO This issue does not affect Junos OS Evolved versions before 25.2R1-EVO. eBGP and iBGP are affected. IPv4 and IPv6 are affected. | ||||
| CVE-2026-23331 | 1 Linux | 1 Linux Kernel | 2026-04-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: udp: Unhash auto-bound connected sk from 4-tuple hash table when disconnected. Let's say we bind() an UDP socket to the wildcard address with a non-zero port, connect() it to an address, and disconnect it from the address. bind() sets SOCK_BINDPORT_LOCK on sk->sk_userlocks (but not SOCK_BINDADDR_LOCK), and connect() calls udp_lib_hash4() to put the socket into the 4-tuple hash table. Then, __udp_disconnect() calls sk->sk_prot->rehash(sk). It computes a new hash based on the wildcard address and moves the socket to a new slot in the 4-tuple hash table, leaving a garbage in the chain that no packet hits. Let's remove such a socket from 4-tuple hash table when disconnected. Note that udp_sk(sk)->udp_portaddr_hash needs to be udpated after udp_hash4_dec(hslot2) in udp_unhash4(). | ||||
| CVE-2026-23332 | 1 Linux | 1 Linux Kernel | 2026-04-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: cpufreq: intel_pstate: Fix crash during turbo disable When the system is booted with kernel command line argument "nosmt" or "maxcpus" to limit the number of CPUs, disabling turbo via: echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo results in a crash: PF: supervisor read access in kernel mode PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI ... RIP: 0010:store_no_turbo+0x100/0x1f0 ... This occurs because for_each_possible_cpu() returns CPUs even if they are not online. For those CPUs, all_cpu_data[] will be NULL. Since commit 973207ae3d7c ("cpufreq: intel_pstate: Rearrange max frequency updates handling code"), all_cpu_data[] is dereferenced even for CPUs which are not online, causing the NULL pointer dereference. To fix that, pass CPU number to intel_pstate_update_max_freq() and use all_cpu_data[] for those CPUs for which there is a valid cpufreq policy. | ||||
| CVE-2026-23334 | 1 Linux | 1 Linux Kernel | 2026-04-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: can: usb: f81604: handle short interrupt urb messages properly If an interrupt urb is received that is not the correct length, properly detect it and don't attempt to treat the data as valid. | ||||