Export limit exceeded: 16487 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 397615 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 42414 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (42414 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-73721 | 2 Arubanetworks, Hewlett Packard Enterprise (hpe) | 2 Fabric Composer, Fabric Composer | 2026-09-02 | 7.2 High |
| Vulnerabilities in the API of HPE Networking Fabric Composer could allow an authenticated remote attacker to conduct SQL injection attacks against the HPE Networking Fabric Composer instance. An attacker could exploit these vulnerabilities to obtain and modify sensitive information in the underlying database potentially leading to complete compromise of the HPE Networking Fabric Composer host. | ||||
| CVE-2026-64056 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: net: ethernet: cortina: Make RX SKB per-port The SKB used to assemble packets from fragments in gmac_rx() is static local, but the Gemini has two ethernet ports, meaning there can be races between the ports on a bad day if a device is using both. Make the RX SKB a per-port variable and carry it over between invocations in the port struct instead. Zero the pointer once we call napi_gro_frags(), on error (after calling napi_free_frags()) or if the port is stopped. Zero it in some place where not strictly necessary just to emphasize what is going on. This was found by Sashiko during normal patch review. | ||||
| CVE-2026-64061 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 9.8 Critical |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix early put of sink folio in netfs_read_gaps() Fix netfs_read_gaps() to release the sink page it uses after waiting for the request to complete. The way the sink page is used is that an ITER_BVEC-class iterator is created that has the gaps from the target folio at either end, but has the sink page tiled over the middle so that a single read op can fill in both gaps. The bug was found by KASAN detecting a UAF on the generic/075 xfstest in the cifsd kernel thread that handles reception of data from the TCP socket: BUG: KASAN: use-after-free in _copy_to_iter+0x48a/0xa20 Write of size 885 at addr ffff888107f92000 by task cifsd/1285 CPU: 2 UID: 0 PID: 1285 Comm: cifsd Not tainted 7.0.0 #6 PREEMPT(lazy) Call Trace: dump_stack_lvl+0x5d/0x80 print_report+0x17f/0x4f1 kasan_report+0x100/0x1e0 kasan_check_range+0x10f/0x1e0 __asan_memcpy+0x3c/0x60 _copy_to_iter+0x48a/0xa20 __skb_datagram_iter+0x2c9/0x430 skb_copy_datagram_iter+0x6e/0x160 tcp_recvmsg_locked+0xce0/0x1130 tcp_recvmsg+0xeb/0x300 inet_recvmsg+0xcf/0x3a0 sock_recvmsg+0xea/0x100 cifs_readv_from_socket+0x3a6/0x4d0 [cifs] cifs_read_iter_from_socket+0xdd/0x130 [cifs] cifs_readv_receive+0xaad/0xb10 [cifs] cifs_demultiplex_thread+0x1148/0x1740 [cifs] kthread+0x1cf/0x210 | ||||
| CVE-2026-64062 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: netfs: Fix potential deadlock in write-through mode Fix netfs_advance_writethrough() to always unlock the supplied folio and to mark it dirty if it isn't yet written to the end. Unfortunately, it can't be marked for writeback until the folio is done with as that may cause a deadlock against mmapped reads and writes. Even though it has been marked dirty, premature writeback can't occur as the caller is holding both inode->i_rwsem (which will prevent concurrent truncation, fallocation, DIO and other writes) and ictx->wb_lock (which will cause flushing to wait and writeback to skip or wait). Note that this may be easier to deal with once the queuing of folios is split from the generation of subrequests. | ||||
| CVE-2026-64044 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: ovpn: respect peer refcount in CMD_NEW_PEER error path ovpn_nl_peer_new_doit()'s error path calls ovpn_peer_release() directly rather than ovpn_peer_put(), bypassing the kref. The accompanying comment ("peer was not yet hashed, thus it is not used in any context") holds for UDP but not for TCP. For UDP, the ovpn_socket union uses the .ovpn arm and never points back at a peer; UDP encap_recv looks up peers via the not-yet-populated hashtables, so the new peer is unreachable until ovpn_peer_add() publishes it. For TCP, ovpn_socket_new() sets ovpn_sock->peer and ovpn_tcp_socket_attach() publishes ovpn_sock via rcu_assign_sk_user_data(). From that moment until ovpn_socket_release() detaches in the error path, the TCP fd is fully wired: userspace recvmsg / sendmsg / close / poll on the fd, as well as the strparser-driven ovpn_tcp_rcv() path, can reach the peer through sk_user_data -> ovpn_sock->peer and bump its refcount via ovpn_peer_hold(). ovpn_tcp_socket_wait_finish() (called inside ovpn_socket_release()) drains strparser and the tx work, but does not synchronize with userspace syscall callers that already hold a peer reference. If ovpn_nl_peer_modify() or ovpn_peer_add() returns an error while such a caller is in flight - notably an ovpn_tcp_recvmsg() blocked in __skb_recv_datagram() on peer->tcp.user_queue - the direct ovpn_peer_release() destroys the peer while the caller still holds the reference, and the eventual ovpn_peer_put() from that caller operates on freed memory. Replace the direct destructor call with ovpn_peer_put() so the kref correctly defers destruction until the last reference is dropped. In the common case where no concurrent user is present, behaviour is unchanged: the kref hits zero immediately and ovpn_peer_release_kref() runs the same destructor. With this conversion ovpn_peer_release() has no callers outside peer.c - ovpn_peer_release_kref() in the same translation unit is the only remaining user - so make it static and drop its declaration from peer.h. | ||||
| CVE-2026-64050 | 1 Linux | 1 Linux Kernel | 2026-09-02 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: drm/msm/dpu: don't mix devm and drmm functions Mixing devm and drmm functions will result in a use-after-free on msm driver teardown if userspace keeps a reference on the drm device: The WB connector data will be destroyed because of the use of devm_kzalloc()), while the usersoace still can try interacting with the WB connector (which uses drmm_ functions). Change dpu_writeback_init() to use drmm_. Patchwork: https://patchwork.freedesktop.org/patch/722656/ | ||||
| CVE-2026-66375 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 8.1 High |
| A low-privilege authenticated user may permanently remove protected internal metadata across repositories under specific conditions. | ||||
| CVE-2026-66377 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 5.3 Medium |
| An unauthenticated user may access restricted repository information under specific conditions. | ||||
| CVE-2026-66378 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 4.3 Medium |
| An authenticated user without repository read permission may access private NuGet metadata under specific conditions. | ||||
| CVE-2026-66379 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 4.3 Medium |
| An authenticated user may view private Puppet module metadata without repository read access. | ||||
| CVE-2026-66380 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 4.3 Medium |
| An authenticated user without repository read permission may access private OCI referrer metadata under specific conditions. | ||||
| CVE-2026-68753 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 5.3 Medium |
| An unauthenticated user may access restricted Artifactory content when a credentialed remote repository is configured in a specific way. | ||||
| CVE-2026-68754 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 6.5 Medium |
| A repository publisher without delete permission may modify protected package content under specific conditions. | ||||
| CVE-2026-68755 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 4.3 Medium |
| A bundle writer may create misleading release promotion information under specific conditions. | ||||
| CVE-2026-68758 | 1 Jfrog | 1 Artifactory | 2026-09-02 | 6.5 Medium |
| A low-privileged authenticated user may access restricted support information under specific conditions. | ||||
| CVE-2026-82463 | 1 Pac4j | 1 Pac4j | 2026-09-02 | 8.1 High |
| pac4j-core before 6.5.6 contains an authentication bypass vulnerability in CheckProfileTypeAuthorizer that reverses the profile type validation logic. Attackers can authenticate through a weaker client and access resources requiring a stronger profile type by satisfying generic profile checks. | ||||
| CVE-2026-78676 | 1 Gitpython Project | 1 Gitpython | 2026-09-02 | 9.8 Critical |
| GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation. | ||||
| CVE-2026-18544 | 1 Ibm | 1 Portieris | 2026-09-02 | 8.1 High |
| IBM Portieris 0.5.0 through 0.14.2 could allow a remote authenticated attacker to bypass image policy enforcement due to improper authorization of pod owner references. | ||||
| CVE-2026-78597 | 1 Elastic | 1 Kibana | 2026-09-02 | 4.3 Medium |
| Missing Authorization (CWE-862) in the Kibana Entity Store feature can lead to unauthorized credential creation via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated user holding only low-privilege Security feature access could invoke an administrative operation that creates and persists Elasticsearch API keys under the caller's identity, bypassing the elevated cluster and Kibana privileges that the documented Entity Store setup flow requires. | ||||
| CVE-2026-78607 | 1 Elastic | 1 Elasticsearch | 2026-09-02 | 5.4 Medium |
| Missing Authorization (CWE-862) in the Elasticsearch custom inference service can lead to information disclosure via Privilege Abuse (CAPEC-122). A user holding only inference execution privileges could cause outbound inference traffic to be directed to a destination of their choosing and could cause administrator-provisioned credentials to be exposed. | ||||