Total
409866 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2025-5351 | 2 Libssh, Redhat | 3 Libssh, Enterprise Linux, Openshift Container Platform | 2026-09-01 | N/A | 6.5 MEDIUM |
| A flaw was found in the key export functionality of libssh. The issue occurs in the internal function responsible for converting cryptographic keys into serialized formats. During error handling, a memory structure is freed but not cleared, leading to a potential double free issue if an additional failure occurs later in the function. This condition may result in heap corruption or application instability in low-memory scenarios, posing a risk to system reliability where key export operations are performed. | |||||
| CVE-2025-4598 | 5 Debian, Linux, Oracle and 2 more | 6 Debian Linux, Linux Kernel, Linux and 3 more | 2026-09-01 | N/A | 4.7 MEDIUM |
| A vulnerability was found in systemd-coredump. This flaw allows an attacker to force a SUID process to crash and replace it with a non-SUID binary to access the original's privileged process coredump, allowing the attacker to read sensitive data, such as /etc/shadow content, loaded by the original process. A SUID binary or process has a special type of permission, which allows the process to run with the file owner's permissions, regardless of the user executing the binary. This allows the process to access more restricted data than unprivileged users or processes would be able to. An attacker can leverage this flaw by forcing a SUID process to crash and force the Linux kernel to recycle the process PID before systemd-coredump can analyze the /proc/pid/auxv file. If the attacker wins the race condition, they gain access to the original's SUID process coredump file. They can read sensitive content loaded into memory by the original binary, affecting data confidentiality. | |||||
| CVE-2025-4382 | 2026-09-01 | N/A | 5.9 MEDIUM | ||
| A flaw was found in systems utilizing LUKS-encrypted disks with GRUB configured for TPM-based auto-decryption. When GRUB is set to automatically decrypt disks using keys stored in the TPM, it reads the decryption key into system memory. If an attacker with physical access can corrupt the underlying filesystem superblock, GRUB will fail to locate a valid filesystem and enter rescue mode. At this point, the disk is already decrypted, and the decryption key remains loaded in system memory. This scenario may allow an attacker with physical access to access the unencrypted data without any further authentication, thereby compromising data confidentiality. Furthermore, the ability to force this state through filesystem corruption also presents a data integrity concern. | |||||
| CVE-2025-3576 | 2026-09-01 | N/A | 5.9 MEDIUM | ||
| A vulnerability in the MIT Kerberos implementation allows GSSAPI-protected messages using RC4-HMAC-MD5 to be spoofed due to weaknesses in the MD5 checksum design. If RC4 is preferred over stronger encryption types, an attacker could exploit MD5 collisions to forge message integrity codes. This may lead to unauthorized message tampering. | |||||
| CVE-2025-32990 | 2 Gnu, Redhat | 3 Gnutls, Enterprise Linux, Openshift Container Platform | 2026-09-01 | N/A | 6.5 MEDIUM |
| A heap-buffer-overflow (off-by-one) flaw was found in the GnuTLS software in the template parsing logic within the certtool utility. When it reads certain settings from a template file, it allows an attacker to cause an out-of-bounds (OOB) NULL pointer write, resulting in memory corruption and a denial-of-service (DoS) that could potentially crash the system. | |||||
| CVE-2025-32989 | 2 Gnu, Redhat | 3 Gnutls, Enterprise Linux, Openshift Container Platform | 2026-09-01 | N/A | 5.3 MEDIUM |
| A heap-buffer-overread vulnerability was found in GnuTLS in how it handles the Certificate Transparency (CT) Signed Certificate Timestamp (SCT) extension during X.509 certificate parsing. This flaw allows a malicious user to create a certificate containing a malformed SCT extension (OID 1.3.6.1.4.1.11129.2.4.2) that contains sensitive data. This issue leads to the exposure of confidential information when GnuTLS verifies certificates from certain websites when the certificate (SCT) is not checked correctly. | |||||
| CVE-2025-32988 | 2 Gnu, Redhat | 3 Gnutls, Enterprise Linux, Openshift Container Platform | 2026-09-01 | N/A | 6.5 MEDIUM |
| A flaw was found in GnuTLS. A double-free vulnerability exists in GnuTLS due to incorrect ownership handling in the export logic of Subject Alternative Name (SAN) entries containing an otherName. If the type-id OID is invalid or malformed, GnuTLS will call asn1_delete_structure() on an ASN.1 node it does not own, leading to a double-free condition when the parent function or caller later attempts to free the same structure. This vulnerability can be triggered using only public GnuTLS APIs and may result in denial of service or memory corruption, depending on allocator behavior. | |||||
| CVE-2026-37004 | 2026-09-01 | N/A | 9.8 CRITICAL | ||
| BerriAI litellm <=1.82.4 is vulnerable to Server-Side Template Injection (SSTI), which allows unauthenticated remote attackers to execute arbitrary OS commands via a crafted dotprompt_content parameter in the /prompts/test endpoint due to use of an unsandboxed jinja2.Environment. | |||||
| CVE-2026-19295 | 1 Langflow | 1 Langflow | 2026-09-01 | N/A | 9.9 CRITICAL |
| IBM Langflow OSS 1.0.0 through 1.11.1 allows an authenticated attacker to execute arbitrary operating system commands in the server process by saving a flow with a crafted type field value and triggering a build of a wrapper flow that references it. This allowed privilege escalation from "authenticated flow user" to arbitrary OS-level command execution under the server process identity, bypassing the LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false policy control. | |||||
| CVE-2026-19286 | 1 Langflow | 1 Langflow | 2026-09-01 | N/A | 9.8 CRITICAL |
| IBM Langflow OSS 1.0.0 through 1.11.1 could allow a remote attacker to execute arbitrary code due to improper enforcement of security restrictions on the A2A public endpoint. | |||||
| CVE-2026-18729 | 1 Langflow | 1 Langflow | 2026-09-01 | N/A | 8.8 HIGH |
| IBM Langflow OSS 1.0.0 through 1.11.1 could allow a remote authenticated attacker to execute arbitrary code due to improper control of generation of code. | |||||
| CVE-2026-82423 | 2026-09-01 | 5.5 MEDIUM | 5.4 MEDIUM | ||
| A vulnerability has been found in macrozheng mall up to 1.0.3. The affected element is an unknown function of the file /order/paySuccess of the component Payment Status Endpoint. The manipulation of the argument orderId leads to enforcement of behavioral workflow. The attack is possible to be carried out remotely. The vendor deleted the GitHub issue for this vulnerability without any explanation. | |||||
| CVE-2026-15369 | 2026-09-01 | N/A | 9.8 CRITICAL | ||
| The Custom User Registration Fields for WooCommerce plugin for WordPress is vulnerable to Privilege Escalation in versions up to, and including, 2.2.3. This is due to the plugin accepting an attacker-controlled afreg_select_user_role value from the unauthenticated WooCommerce Store API /wc/store/v1/checkout request in the af_reg_checkout_data_to_order_meta_data_block() function, persisting it in order meta, and then passing it directly to WP_User::add_role() in the af_reg_custom_order_processing_function() function (hooked to woocommerce_thankyou) without validating against the plugin's admin-configured allowed role list. This makes it possible for unauthenticated attackers to elevate their privileges to Administrator by creating an account during checkout with a modified JSON body specifying administrator (or any other role slug) as the desired role. Note: The exploit requires the "User Role Selection" setting to be enabled. | |||||
| CVE-2026-18899 | 1 Langflow | 1 Langflow | 2026-09-01 | N/A | 7.5 HIGH |
| IBM Langflow OSS 1.0.0 through 1.11.1 could allow a remote attacker to read arbitrary files due to path traversal. | |||||
| CVE-2026-17203 | 2026-09-01 | N/A | 7.5 HIGH | ||
| IBM Administration Runtime Expert for i 1R1M0 could allow a remote authenticated attacker to obtain sensitive information due to improper authentication enforcement. | |||||
| CVE-2026-7007 | 1 Zephyrproject | 1 Zephyr | 2026-09-01 | N/A | 4.6 MEDIUM |
| The Zephyr ext2 file system validates the on-disk superblock in ext2_verify_disk_superblock() (subsys/fs/ext2/ext2_impl.c) before completing a mount. The validator checked the magic number, block size, revision and feature flags, but did not verify that the on-disk fields s_blocks_per_group and s_inodes_per_group are non-zero. Both fields are read directly from the image and are later used as divisors during mount-time initialization. During mount, get_ngroups() divides and modulos s_blocks_count by s_blocks_per_group (reached via ext2_fetch_block_group() from ext2_init_fs()), and get_itable_entry() divides (ino - 1) by s_inodes_per_group when fetching the root inode (both in subsys/fs/ext2/ext2_diskops.c). A superblock with either field set to zero therefore causes an integer division by zero during the mount sequence. An attacker who can present a crafted ext2 image to a device that mounts ext2 — removable media such as an SD card or a USB mass-storage device — can trigger this. On ARMv7-M / ARMv8-M-mainline Cortex-M targets, divide-by-zero trapping is enabled (SCB_CCR_DIV_0_TRP), so the division raises a UsageFault that Zephyr treats as a fatal error, producing a denial of service. The impact is limited to availability; the malformed value is consumed only as a divisor. The fix rejects a zero s_blocks_per_group or s_inodes_per_group in the superblock validator, returning -EINVAL so the mount fails before any block-group or inode I/O occurs. | |||||
| CVE-2026-2411 | 1 Zephyrproject | 1 Zephyr | 2026-09-01 | N/A | 6.5 MEDIUM |
| Zephyr's Bluetooth host declares a GATT characteristic as two consecutive attributes: a Characteristic Declaration whose permission is hard-coded to BT_GATT_PERM_READ, and a Characteristic Value attribute that carries the application-specified security permissions (e.g. BT_GATT_PERM_READ_ENCRYPT / READ_AUTHEN / READ_LESC). The public notify and indicate APIs explicitly accept either attribute, and passing the declaration is the documented, common idiom. Before sending each notification or indication, the host re-checks link security with bt_gatt_check_perm() against params->attr in gatt_notify(), gatt_indicate(), and gatt_notify_multiple_verify_params() (subsys/bluetooth/host/gatt.c). When the application passed the Characteristic Declaration attribute, the host correctly redirected the value handle but left params->attr pointing at the declaration, so the security check evaluated the declaration's permissions (no security required) instead of the value's. As a result the encryption/authentication/LESC requirement configured on the characteristic value was skipped. The Notify-Multiple path additionally used a mask that omitted the LE Secure Connections requirement. A remote peer triggers the disclosure by connecting (optionally without pairing or encryption) and writing the Client Characteristic Configuration descriptor to enable notifications or indications, causing the server to emit the protected value over a link that has not reached the required security level. The impact is information disclosure / access-control bypass for characteristic values the application intended to expose only over a secured link; exposure depends on the application declaring encrypt/authen-required notify/indicate characteristics and on the CCC being writable at a lower security tier. There is no memory-safety or availability impact. The fix adds bt_gatt_attr_resolve_value(), which maps a declaration attribute to the following value attribute before the permission check, and switches the Notify-Multiple path to the full BT_GATT_PERM_READ_ENCRYPT_MASK so the LESC requirement is also enforced. | |||||
| CVE-2026-12051 | 2026-09-01 | N/A | 4.6 MEDIUM | ||
| The USB DFU class implementation in Zephyr's new (experimental) device_next USB device stack contains a NULL pointer dereference in handle_download() (subsys/usb/device_next/class/usbd_dfu.c). The handler computes MIN(setup->wLength, buf->len) and passes buf->data to the image write callback without checking that the buf net_buf pointer is non-NULL. The handler is reached over the USB control endpoint, driven by the USB host. For a DFU_DNLOAD (download) request with no Data OUT stage — notably the zero-length terminating download that the DFU protocol uses to end a firmware transfer — the USB core invokes the class handler with a NULL buffer. After the device has been advanced to the DFU_DNLOAD_IDLE state (by sending one valid download block and a GET_STATUS), a zero-length DFU_DNLOAD reaches handle_download() with buf == NULL, dereferencing it. The result is a NULL+offset read that triggers a fatal CPU fault, i.e. a denial of service (device crash/reset). The attacker is whatever controls the USB host the device is attached to; DFU download support must be enabled with a registered image. There is no memory corruption or information disclosure — impact is limited to availability. The fix adds an explicit if (buf != NULL) guard so the callback receives a zero-length, NULL-data transfer instead of crashing. | |||||
| CVE-2026-11985 | 2026-09-01 | N/A | 3.6 LOW | ||
| On the Zephyr ARM port, enabling the hardware FPU (CONFIG_FPU) forces the "Floating point ABI" choice, which defaults to CONFIG_FP_HARDABI. Both FP_HARDABI and FP_SOFTABI permit the compiler to emit hardware FP instructions in any function, even code that never uses floating-point types. However, the callee-saved FP registers (s16-s31 / d8-d15) are only saved and restored across a context switch when CONFIG_FPU_SHARING is enabled (arch/arm/core/cortex_m/swap_helper.S and arch/arm/core/cortex_a_r/swap_helper.S), and prior to this fix selecting an ABI did not enable FPU register sharing, which defaults off. In a build that enables the FPU with the default ABI but leaves CONFIG_FPU_SHARING disabled, the kernel preserves no callee-saved FP register state across thread switches. The documented precondition for this "unshared" mode — that only a single thread ever executes FP instructions — is silently violated because the compiler may generate FP instructions in every thread. Under CONFIG_USERSPACE, where threads are mutually isolated, this becomes an information-disclosure boundary crossing: a victim thread can leave secret-derived values in s16-s31, and a co-resident unprivileged thread can read those registers directly (FP register access is not privilege-gated), recovering data left behind by another thread. Without userspace the same defect causes cross-thread FP state corruption (a correctness fault). The leak is bounded to the 16 callee-saved single-precision registers and is opportunistic, so impact is low. The fix makes FP_HARDABI and FP_SOFTABI select CONFIG_FPU_SHARING and tags every thread with K_FP_REGS at creation, so callee-saved FP state is always preserved across context switches whenever the compiler may emit FP instructions. | |||||
| CVE-2026-11812 | 2026-09-01 | N/A | 2.5 LOW | ||
| The UpdateHub management subsystem (subsys/mgmt/updatehub/updatehub.c) drives every update operation through a single file-scope ctx structure that holds the CoAP block context, payload buffer, status code, socket, and a one-element poll-fd array fds[1]. Access to ctx was not serialized, and prepare_fds() wrote ctx.fds[ctx.nfds] and incremented ctx.nfds with no bounds check. Two independent paths mutate ctx concurrently: the background autohandler running on the system workqueue, and user-triggered operations reached through the updatehub run shell command, direct API calls, or — since the operations are exposed as syscalls — userspace threads. When a second flow enters prepare_fds() while ctx.nfds is already 1, the write lands one element past the array; by struct layout it overlaps the adjacent ctx.sock/ctx.nfds members. More broadly, the unsynchronized sharing lets two flows interleave connection setup and teardown, double-closing a socket descriptor or scribbling the shared buffers. The result is corruption of the update subsystem's internal state and denial of service of the firmware-update path; the out-of-bounds write is contained within the ctx structure and there is no demonstrated path to memory outside it or to code execution. Triggering requires a local actor able to invoke update operations (or, with CONFIG_USERSPACE, an unprivileged userspace thread) and to win a timing race against the background handler; remote peers cannot control the race timing. The fix serializes the entry points with a mutex and adds a bounds check to prepare_fds(). | |||||