Search

Search Results (353738 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-4410 1 Ibm 2 Websphere Application Server, Websphere Application Server Liberty 2026-05-27 4.8 Medium
IBM WebSphere Application Server - Liberty 19.0.0.7 through 26.0.0.5 and IBM WebSphere Application Server 9.0, and 8.5 and WebSphere Application Server Liberty are vulnerable to a denial of service, caused by sending a specially-crafted request. A remote attacker could exploit this vulnerability to cause the server to consume memory resources.
CVE-2026-1248 1 Ibm 1 Business Automation Workflow Containers And Traditional 2026-05-27 4.3 Medium
IBM Business Automation Workflow containers and traditional may leak information about its database structure in error messages.
CVE-2015-6564 2 Openbsd, Redhat 2 Openssh, Enterprise Linux 2026-05-27 7 High
Use-after-free vulnerability in the mm_answer_pam_free_ctx function in monitor.c in sshd in OpenSSH before 7.0 on non-OpenBSD platforms might allow local users to gain privileges by leveraging control of the sshd uid to send an unexpectedly early MONITOR_REQ_PAM_FREE_CTX request.
CVE-2015-6563 3 Apple, Openbsd, Redhat 3 Mac Os X, Openssh, Enterprise Linux 2026-05-27 6.4 Medium
The monitor component in sshd in OpenSSH before 7.0 on non-OpenBSD platforms accepts extraneous username data in MONITOR_REQ_PAM_INIT_CTX requests, which allows local users to conduct impersonation attacks by leveraging any SSH login access in conjunction with control of the sshd uid to send a crafted MONITOR_REQ_PWNAM request, related to monitor.c and monitor_wrap.c.
CVE-2015-4000 13 Apple, Canonical, Debian and 10 more 31 Iphone Os, Mac Os X, Safari and 28 more 2026-05-27 3.7 Low
The TLS protocol 1.2 and earlier, when a DHE_EXPORT ciphersuite is enabled on a server but not on a client, does not properly convey a DHE_EXPORT choice, which allows man-in-the-middle attackers to conduct cipher-downgrade attacks by rewriting a ClientHello with DHE replaced by DHE_EXPORT and then rewriting a ServerHello with DHE_EXPORT replaced by DHE, aka the "Logjam" issue.
CVE-2026-45995 1 Linux 1 Linux Kernel 2026-05-27 N/A
In the Linux kernel, the following vulnerability has been resolved: io_uring/zcrx: fix user_struct uaf io_free_rbuf_ring() usees a struct user_struct, which io_zcrx_ifq_free() puts it down before destroying the ring.
CVE-2026-45868 1 Linux 1 Linux Kernel 2026-05-27 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: pinctrl: single: fix refcount leak in pcs_add_gpio_func() of_parse_phandle_with_args() returns a device_node pointer with refcount incremented in gpiospec.np. The loop iterates through all phandles but never releases the reference, causing a refcount leak on each iteration. Add of_node_put() calls to release the reference after extracting the needed arguments and on the error path when devm_kzalloc() fails. This bug was detected by our static analysis tool and verified by my code review.
CVE-2026-45882 1 Linux 1 Linux Kernel 2026-05-27 N/A
In the Linux kernel, the following vulnerability has been resolved: power: supply: pm8916_bms_vm: Fix use-after-free in power_supply_changed() Using the `devm_` variant for requesting IRQ _before_ the `devm_` variant for allocating/registering the `power_supply` handle, means that the `power_supply` handle will be deallocated/unregistered _before_ the interrupt handler (since `devm_` naturally deallocates in reverse allocation order). This means that during removal, there is a race condition where an interrupt can fire just _after_ the `power_supply` handle has been freed, *but* just _before_ the corresponding unregistration of the IRQ handler has run. This will lead to the IRQ handler calling `power_supply_changed()` with a freed `power_supply` handle. Which usually crashes the system or otherwise silently corrupts the memory... Note that there is a similar situation which can also happen during `probe()`; the possibility of an interrupt firing _before_ registering the `power_supply` handle. This would then lead to the nasty situation of using the `power_supply` handle *uninitialized* in `power_supply_changed()`. Fix this racy use-after-free by making sure the IRQ is requested _after_ the registration of the `power_supply` handle.
CVE-2026-6783 1 Mozilla 2 Firefox, Thunderbird 2026-05-27 5.3 Medium
Incorrect boundary conditions, integer overflow in the Audio/Video: Playback component. This vulnerability was fixed in Firefox 150 and Thunderbird 150.
CVE-2026-6753 1 Mozilla 2 Firefox, Thunderbird 2026-05-27 7.3 High
Incorrect boundary conditions in the WebRTC component. This vulnerability was fixed in Firefox 150, Firefox ESR 140.10, Thunderbird 150, and Thunderbird 140.10.
CVE-2026-6765 1 Mozilla 2 Firefox, Thunderbird 2026-05-27 5.3 Medium
Information disclosure in the Form Autofill component. This vulnerability was fixed in Firefox 150, Firefox ESR 140.10, Thunderbird 150, and Thunderbird 140.10.
CVE-2026-9170 1 Ibm 2 Http Server, Web Server Plug Ins For Websphere Application Server And Websphere Liberty 2026-05-27 9.8 Critical
IBM HTTP Server 8.5, and 9.0
CVE-2026-6778 1 Mozilla 2 Firefox, Thunderbird 2026-05-27 5.3 Medium
Invalid pointer in the Audio/Video: Playback component. This vulnerability was fixed in Firefox 150 and Thunderbird 150.
CVE-2026-23652 1 Microsoft 1 Power Pages 2026-05-27 10 Critical
Improper neutralization of special elements used in a command ('command injection') in Microsoft Power Pages allows an unauthorized attacker to execute code over a network.
CVE-2026-36539 2026-05-27 N/A
Netis AC1200 Router NC21 V4.0.1.4296 exposes a CGI endpoint /cgi-bin/skk_get.cgi that returns the entire router configuration as a JSON response with no authentication required. Any attacker on the LAN can send a single HTTP GET request and instantly retrieve administrator credentials, WiFi passwords, PPPoE credentials, DDNS credentials, and a full map of all connected devices.
CVE-2026-45849 1 Linux 1 Linux Kernel 2026-05-27 N/A
In the Linux kernel, the following vulnerability has been resolved: net: mscc: ocelot: add missing lock protection in ocelot_port_xmit_inj() ocelot_port_xmit_inj() calls ocelot_can_inject() and ocelot_port_inject_frame() without holding the injection group lock. Both functions contain lockdep_assert_held() for the injection lock, and the correct caller felix_port_deferred_xmit() properly acquires the lock using ocelot_lock_inj_grp() before calling these functions. Add ocelot_lock_inj_grp()/ocelot_unlock_inj_grp() around the register injection path to fix the missing lock protection. The FDMA path is not affected as it uses its own locking mechanism.
CVE-2026-45856 1 Linux 1 Linux Kernel 2026-05-27 7.0 High
In the Linux kernel, the following vulnerability has been resolved: RDMA/uverbs: Validate wqe_size before using it in ib_uverbs_post_send ib_uverbs_post_send() uses cmd.wqe_size from userspace without any validation before passing it to kmalloc() and using the allocated buffer as struct ib_uverbs_send_wr. If a user provides a small wqe_size value (e.g., 1), kmalloc() will succeed, but subsequent accesses to user_wr->opcode, user_wr->num_sge, and other fields will read beyond the allocated buffer, resulting in an out-of-bounds read from kernel heap memory. This could potentially leak sensitive kernel information to userspace. Additionally, providing an excessively large wqe_size can trigger a WARNING in the memory allocation path, as reported by syzkaller. This is inconsistent with ib_uverbs_unmarshall_recv() which properly validates that wqe_size >= sizeof(struct ib_uverbs_recv_wr) before proceeding. Add the same validation for ib_uverbs_post_send() to ensure wqe_size is at least sizeof(struct ib_uverbs_send_wr).
CVE-2026-45857 1 Linux 1 Linux Kernel 2026-05-27 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: scsi: csiostor: Fix dereference of null pointer rn The error exit path when rn is NULL ends up deferencing the null pointer rn via the use of the macro CSIO_INC_STATS. Fix this by adding a new error return path label after the use of the macro to avoid the deference.
CVE-2026-45860 1 Linux 1 Linux Kernel 2026-05-27 7.0 High
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_conncount: increase the connection clean up limit to 64 After the optimization to only perform one GC per jiffy, a new problem was introduced. If more than 8 new connections are tracked per jiffy the list won't be cleaned up fast enough possibly reaching the limit wrongly. In order to prevent this issue, only skip the GC if it was already triggered during the same jiffy and the increment is lower than the clean up limit. In addition, increase the clean up limit to 64 connections to avoid triggering GC too often and do more effective GCs. This has been tested using a HTTP server and several performance tools while having nft_connlimit/xt_connlimit or OVS limit configured. Output of slowhttptest + OVS limit at 52000 connections: slow HTTP test status on 340th second: initializing: 0 pending: 432 connected: 51998 error: 0 closed: 0 service available: YES
CVE-2026-46015 1 Linux 1 Linux Kernel 2026-05-27 N/A
In the Linux kernel, the following vulnerability has been resolved: tcp: call sk_data_ready() after listener migration When inet_csk_listen_stop() migrates an established child socket from a closing listener to another socket in the same SO_REUSEPORT group, the target listener gets a new accept-queue entry via inet_csk_reqsk_queue_add(), but that path never notifies the target listener's waiters. A nonblocking accept() still works because it checks the queue directly, but poll()/epoll_wait() waiters and blocking accept() callers can also remain asleep indefinitely. Call READ_ONCE(nsk->sk_data_ready)(nsk) after a successful migration in inet_csk_listen_stop(). However, after inet_csk_reqsk_queue_add() succeeds, the ref acquired in reuseport_migrate_sock() is effectively transferred to nreq->rsk_listener. Another CPU can then dequeue nreq via accept() or listener shutdown, hit reqsk_put(), and drop that listener ref. Since listeners are SOCK_RCU_FREE, wrap the post-queue_add() dereferences of nsk in rcu_read_lock()/rcu_read_unlock(), which also covers the existing sock_net(nsk) access in that path. The reqsk_timer_handler() path does not need the same changes for two reasons: half-open requests become readable only after the final ACK, where tcp_child_process() already wakes the listener; and once nreq is visible via inet_ehash_insert(), the success path no longer touches nsk directly.