Export limit exceeded: 408366 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (408366 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-64028 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: tracing: Avoid NULL return from hist_field_name() on truncation hist_field_name() returns "" everywhere except the fully-qualified VAR_REF/EXPR case, where snprintf() truncation returns NULL early and bypasses the bottom NULL->"" guard. Callers don't expect NULL: strcat(expr, hist_field_name(field, 0)) at trace_events_hist.c:1758 and the strcmp() in the sort-key match loop at :4804 both deref it. system and event_name are bounded by MAX_EVENT_NAME_LEN, but the field name on a VAR_REF is kstrdup'd from a histogram variable name parsed out of the trigger string and has no length cap, so a long enough var name in a fully qualified reference can reach the truncation path. Keep the length check but leave field_name as "" on overflow. | ||||
| CVE-2026-64027 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: net: shaper: rework the VALID marking (again) Recent commit changed the semantics from NOT_VALID to VALID. I didn't realize that the flags are not stored atomically with the entry in XArray. There's still a race of reader observing a VALID mark for a slot, getting interrupted, writer replacing the entry with a different one, reader continuing, fetching the entry which is now a different pointer than the pointer for which VALID was meant. The biggest consequence of this is that we may see a UAF since net_shaper_rollback() assumed that entries without VALID can be freed without observing RCU. Looks like the XArray marks are buying us nothing at this point. Let's convert the code to an explicit valid field. The smp_load_acquire() / smp_store_release() barriers are marginally cleaner. | ||||
| CVE-2026-97334 | 2026-10-13 | N/A | ||
| The network messaging layer contained improper handling of highly compressed data affecting service availability. Software customers upgrade to resolved maintenance release. Update all Commvault installations, including CommServe server, Web Server, Command Center, MediaAgents, clients, and HyperScale. | ||||
| CVE-2026-97333 | 2026-10-13 | N/A | ||
| QAPI contained a stack-based buffer overflow affecting service availability. Software customers upgrade to resolved maintenance release. Update CommServe, Web Server, Command Center and Index Server. | ||||
| CVE-2026-93907 | 1 Ibm | 1 Websphere Application Server | 2026-10-13 | 8.1 High |
| IBM WebSphere Application Server 8.5, and 9.0 could allow a remote attacker to bypass authentication by exploiting a flaw in the CSIv2 inbound propagation handler. | ||||
| CVE-2026-93891 | 1 Ibm | 1 Tririga Application Platform | 2026-10-13 | 7.6 High |
| IBM TRIRIGA Application Platform 5.0.0 through 5.0.8 could allow a remote authenticated attacker to obtain sensitive information due to an XML external entity (XXE) injection flaw. | ||||
| CVE-2026-92832 | 1 Ibm | 1 Aspera Enterprise Webapps | 2026-10-13 | 5.1 Medium |
| IBM Aspera Enterprise WebApps 1.0.0 through 1.0.6 could allow a local attacker to obtain sensitive information due to cleartext transmission of sensitive information. | ||||
| CVE-2026-90921 | 1 Ibm | 1 Maximo Ai Service | 2026-10-13 | 7.5 High |
| IBM Maximo AI Service 9.1.0, and 9.2.0 could allow a remote attacker to cause a denial of service due to improper handling of malformed frames, resulting in termination of the host process. | ||||
| CVE-2026-90920 | 1 Ibm | 1 Maximo Ai Service | 2026-10-13 | 9.8 Critical |
| IBM Maximo AI Service 9.1.0, and 9.2.0 could allow a remote attacker to execute arbitrary code due to improper control of code generation. | ||||
| CVE-2026-90911 | 1 Ibm | 1 Maximo Ai Service | 2026-10-13 | 7.5 High |
| IBM Maximo AI Service 9.1.0, and 9.2.0 could allow a remote attacker to cause a denial of service due to uncontrolled resource consumption. | ||||
| CVE-2026-78673 | 1 Ibm | 1 Maximo Ai Service | 2026-10-13 | 7.5 High |
| IBM Maximo AI Service 9.1.0, and 9.2.0 could allow a remote attacker to cause a denial of service due to improper input validation. | ||||
| CVE-2026-77100 | 2026-10-13 | N/A | ||
| MediaAgent contained a heap-based buffer overflow issue affecting service availability. Software customers upgrade to resolved maintenance release. Update Commvault installation of MediaAgents and HyperScale. | ||||
| CVE-2026-75782 | 1 Ibm | 1 Aspera Enterprise Webapps | 2026-10-13 | 7.8 High |
| IBM Aspera Enterprise WebApps 1.0.0 through 1.0.6 could allow a local attacker to gain elevated privileges due to a misconfigured PATH environment variable. | ||||
| CVE-2026-75076 | 1 Ibm | 1 Aspera Enterprise Webapps | 2026-10-13 | 4.3 Medium |
| IBM Aspera Enterprise WebApps 1.0.0 through 1.0.6 could allow a remote attacker to obtain sensitive information due to the exposure of JavaScript source map files. | ||||
| CVE-2026-65172 | 2026-10-13 | 8.6 High | ||
| NVIDIA AIStore for Linux and Kubernetes contains a missing authorization vulnerability in the ETL management API where an unauthenticated remote attacker may access ETL information or control existing ETL jobs by sending crafted GET or POST requests to an AIStore proxy. A successful exploit may lead to information disclosure and unauthorized start or stop operations that affect the integrity and availability of ETL data-processing pipelines. | ||||
| CVE-2026-18517 | 1 Ibm | 1 Maximo Application Suite Location Service For Esri Component | 2026-10-13 | 7.7 High |
| IBM Maximo Application Suite - Location Service for Esri Component 9.2, 9.1, and 9.0 IBM Maximo Application Suite — Location Service for Esri Component is vulnerable to unintended network egress due to a misconfigured Kubernetes NetworkPolicy. | ||||
| CVE-2026-103499 | 1 Ibm | 2 Websphere Application Server, Websphere Application Server Liberty | 2026-10-13 | 7.5 High |
| IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.10 and IBM WebSphere Application Server 8.5, and 9.0 Liberty could allow a remote unauthenticated attacker to cause a denial of service due to uncontrolled resource consumption. | ||||
| CVE-2026-102627 | 1 Ibm | 1 Tririga Application Platform | 2026-10-13 | 8.8 High |
| IBM TRIRIGA Application Platform 5.0.0 through 5.0.8 could allow a remote authenticated attacker to execute arbitrary code due to improper validation of file paths during archive extraction. | ||||
| CVE-2026-64026 | 1 Linux | 1 Linux Kernel | 2026-10-13 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg This improves the fix for CVE-2026-43500. Fix the pagecache corruption from in-place decryption of a DATA packet transmitted locally by splice() by getting rid of the packet sharing in the I/O thread and unconditionally extracting the packet content into a bounce buffer in which the buffer is decrypted. recvmsg() (or the kernel equivalent) then copies the data from the bounce buffer to the destination buffer. The sk_buff then remains unmodified. This has an additional advantage in that the packet is then arranged in the buffer with the correct alignment required for the crypto algorithms to process directly. The performance of the crypto does seem to be a little faster and, surprisingly, the unencrypted performance doesn't seem to change much - possibly due to removing complexity from the I/O thread. Yet another advantage is that the I/O thread doesn't have to copy packets which would slow down packet distribution, ACK generation, etc.. The buffer belongs to the call and is allocated initially at 2K, sufficiently large to hold a whole jumbo subpacket, but the buffer will be increased in size if needed. However, to take this work, MSG_PEEK may cause a later packet to be decrypted into the buffer, in which case the earlier one will need re-decrypting for a subsequent recvmsg(). Note that rx_pkt_offset may legitimately see 0 as a valid offset now, so switch to using USHRT_MAX to indicate an invalid offset. Note also that I would generally prefer to replace the buffers of the current sk_buff with a new kmalloc'd buffer of the right size, ditching the old data and frags as this makes the handling of MSG_PEEK easier and removes the re-decryption issue, but this looks like quite a complicated thing to achieve. skb_morph() looks half way to what I want, but I don't want to have to allocate a new sk_buff. | ||||
| CVE-2026-85234 | 1 Redhat | 2 Enterprise Linux, Hummingbird | 2026-10-13 | 7.5 High |
| A flaw was found in tftp-hpa. When the `in.tftpd` remap engine processes an inverse remap rule that also aborts with a non-empty custom error message, it can pass invalid match offsets to the `genmatchstring()` function. This leads to out-of-bounds read/write operations. A remote, unauthenticated attacker can exploit this vulnerability by sending a specially crafted request, causing the daemon to crash and resulting in a denial of service. | ||||