Export limit exceeded: 362087 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (362087 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-53038 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ima_fs: Correctly create securityfs files for unsupported hash algos ima_tpm_chip->allocated_banks[i].crypto_id is initialized to HASH_ALGO__LAST if the TPM algorithm is not supported. However there are places relying on the algorithm to be valid because it is accessed by hash_algo_name[]. On 6.12.40 I observe the following read out-of-bounds in hash_algo_name: ================================================================== BUG: KASAN: global-out-of-bounds in create_securityfs_measurement_lists+0x396/0x440 Read of size 8 at addr ffffffff83e18138 by task swapper/0/1 CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.40 #3 Call Trace: <TASK> dump_stack_lvl+0x61/0x90 print_report+0xc4/0x580 ? kasan_addr_to_slab+0x26/0x80 ? create_securityfs_measurement_lists+0x396/0x440 kasan_report+0xc2/0x100 ? create_securityfs_measurement_lists+0x396/0x440 create_securityfs_measurement_lists+0x396/0x440 ima_fs_init+0xa3/0x300 ima_init+0x7d/0xd0 init_ima+0x28/0x100 do_one_initcall+0xa6/0x3e0 kernel_init_freeable+0x455/0x740 kernel_init+0x24/0x1d0 ret_from_fork+0x38/0x80 ret_from_fork_asm+0x11/0x20 </TASK> The buggy address belongs to the variable: hash_algo_name+0xb8/0x420 Memory state around the buggy address: ffffffff83e18000: 00 01 f9 f9 f9 f9 f9 f9 00 01 f9 f9 f9 f9 f9 f9 ffffffff83e18080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffffff83e18100: 00 00 00 00 00 00 00 f9 f9 f9 f9 f9 00 05 f9 f9 ^ ffffffff83e18180: f9 f9 f9 f9 00 00 00 00 00 00 00 04 f9 f9 f9 f9 ffffffff83e18200: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9 ================================================================== Seems like the TPM chip supports sha3_256, which isn't yet in tpm_algorithms: tpm tpm0: TPM with unsupported bank algorithm 0x0027 That's TPM_ALG_SHA3_256 == 0x0027 from "Trusted Platform Module 2.0 Library Part 2: Structures", page 51 [1]. See also the related U-Boot algorithms update [2]. Thus solve the problem by creating a file name with "_tpm_alg_<ID>" postfix if the crypto algorithm isn't initialized. This is how it looks on the test machine (patch ported to v6.12 release): # ls -1 /sys/kernel/security/ima/ ascii_runtime_measurements ascii_runtime_measurements_tpm_alg_27 ascii_runtime_measurements_sha1 ascii_runtime_measurements_sha256 binary_runtime_measurements binary_runtime_measurements_tpm_alg_27 binary_runtime_measurements_sha1 binary_runtime_measurements_sha256 policy runtime_measurements_count violations [1]: https://trustedcomputinggroup.org/wp-content/uploads/Trusted-Platform-Module-2.0-Library-Part-2-Version-184_pub.pdf [2]: https://lists.denx.de/pipermail/u-boot/2024-July/558835.html | ||||
| CVE-2026-50703 | 1 Frappe | 2 Framework, Frappe Framework | 2026-06-24 | N/A |
| A Stored Cross-Site Scripting (XSS) vulnerability exists in Frappe Framework version 17.0.0-dev due to improper neutralization of user-controlled input in the Desk desktop icon renderer. | ||||
| CVE-2026-9616 | 2 Verenigingvanregistrars, Wordpress | 2 Generate Security.txt, Wordpress | 2026-06-24 | 4.3 Medium |
| The Generate Security.txt plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.0.12. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete the site's security.txt file from the server filesystem or create the .well-known directory by directly invoking the delete_securitytxt or create_wellknown_folder AJAX actions. | ||||
| CVE-2026-12095 | 2 Bytuncay, Wordpress | 2 Kargo Takip, Wordpress | 2026-06-24 | 7.2 High |
| The Kargo Takip plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.2 via the 'api_url' parameter. This makes it possible for unauthenticated attackers to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services. The script echoes internal API response data (specifically the value of any 'auth' key in a JSON response body) verbatim back to the attacker's browser, enabling direct exfiltration of responses from internal services such as cloud instance metadata endpoints. | ||||
| CVE-2026-7617 | 2 Secufor, Wordpress | 2 Secufor Oauth, Wordpress | 2026-06-24 | 5.3 Medium |
| The Secufor_OAuth plugin for WordPress is vulnerable to unauthorized access in all versions up to, and including, 1.0.7. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for unauthenticated attackers to disconnect the WordPress site from its linked Secufor account by clearing the plugin's stored login token and user login configuration. | ||||
| CVE-2026-9175 | 2 Ajitdas, Wordpress | 2 Devs Accounting – Simple Accounting And Invoicing Solution, Wordpress | 2026-06-24 | 5.3 Medium |
| The Devs Accounting – Simple Accounting and Invoicing Solution plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.2.0. This is due to the get_single_account() REST API callback being registered with a permission_callback that unconditionally returns true, providing no authentication or authorization checks on the /devs-accounting/v1/get-account/<id> endpoint. This makes it possible for unauthenticated attackers to read arbitrary private financial account records (including account name, bank name, and opening balance) by enumerating the numeric account ID, resulting in sensitive information disclosure. | ||||
| CVE-2026-10091 | 2 Cgarvey, Wordpress | 2 Email Javascript Cloak, Wordpress | 2026-06-24 | 7.2 High |
| The Email JavaScript Cloak plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's 'email' shortcode in all versions up to, and including, 1.03 due to insufficient input sanitization and output escaping on user supplied attributes. This makes it possible for authenticated attackers, with contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | ||||
| CVE-2026-47375 | 1 Nocodb | 1 Nocodb | 2026-06-24 | 6 Medium |
| NocoDB is software for building databases as spreadsheets. Prior to 2026.04.1, an authenticated user with columnAdd permission on a Postgres-backed base can inject arbitrary SQL into the formula engine via the optional direction argument of ARRAYSORT(...). The value is unrestricted by formula validation and embedded into a knex.raw ORDER BY clause, executing during column creation and on every subsequent record read of the formula column. The vulnerability is specific to the Postgres mapping for ARRAYSORT in packages/nocodb/src/db/functionMappings/pg.ts. This vulnerability is fixed in 2026.04.1. | ||||
| CVE-2026-53055 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/sec2 - prevent req used-after-free for sec During packet transmission, if the system is under heavy load, the hardware might complete processing the packet and free the request memory (req) before the transmission function finishes. If the software subsequently accesses this req, a use-after-free error will occur. The qp_ctx memory exists throughout the packet sending process, so replace the req with the qp_ctx. | ||||
| CVE-2026-53057 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iommu/riscv: Add IOTINVAL after updating DDT/PDT entries Add riscv_iommu_iodir_iotinval() to perform required TLB and context cache invalidations after updating DDT or PDT entries, as mandated by the RISC-V IOMMU specification (Section 6.3.1 and 6.3.2). | ||||
| CVE-2026-53067 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-ep-msi: Fix error unwind and prevent double alloc pci_epf_alloc_doorbell() stores the allocated doorbell message array in epf->db_msg/epf->num_db before requesting MSI vectors. If MSI allocation fails, the array is freed but the EPF state may still point to freed memory. Clear epf->db_msg and epf->num_db on the MSI allocation failure path so that later cleanup cannot double-free the array and callers can retry allocation. Also return -EBUSY when doorbells have already been allocated to prevent leaking or overwriting an existing allocation. | ||||
| CVE-2026-53076 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix OOB in pcpu_init_value An out-of-bounds read occurs when copying element from a BPF_MAP_TYPE_CGROUP_STORAGE map to another pcpu map with the same value_size that is not rounded up to 8 bytes. The issue happens when: 1. A CGROUP_STORAGE map is created with value_size not aligned to 8 bytes (e.g., 4 bytes) 2. A pcpu map is created with the same value_size (e.g., 4 bytes) 3. Update element in 2 with data in 1 pcpu_init_value assumes that all sources are rounded up to 8 bytes, and invokes copy_map_value_long to make a data copy, However, the assumption doesn't stand since there are some cases where the source may not be rounded up to 8 bytes, e.g., CGROUP_STORAGE, skb->data. the verifier verifies exactly the size that the source claims, not the size rounded up to 8 bytes by kernel, an OOB happens when the source has only 4 bytes while the copy size(4) is rounded up to 8. | ||||
| CVE-2026-53078 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix same-register dst/src OOB read and pointer leak in sock_ops When a BPF sock_ops program accesses ctx fields with dst_reg == src_reg, the SOCK_OPS_GET_SK() and SOCK_OPS_GET_FIELD() macros fail to zero the destination register in the !fullsock / !locked_tcp_sock path. Both macros borrow a temporary register to check is_fullsock / is_locked_tcp_sock when dst_reg == src_reg, because dst_reg holds the ctx pointer. When the check is false (e.g., TCP_NEW_SYN_RECV state with a request_sock), dst_reg should be zeroed but is not, leaving the stale ctx pointer: - SOCK_OPS_GET_SK: dst_reg retains the ctx pointer, passes NULL checks as PTR_TO_SOCKET_OR_NULL, and can be used as a bogus socket pointer, leading to stack-out-of-bounds access in helpers like bpf_skc_to_tcp6_sock(). - SOCK_OPS_GET_FIELD: dst_reg retains the ctx pointer which the verifier believes is a SCALAR_VALUE, leaking a kernel pointer. Fix both macros by: - Changing JMP_A(1) to JMP_A(2) in the fullsock path to skip the added instruction. - Adding BPF_MOV64_IMM(si->dst_reg, 0) after the temp register restore in the !fullsock path, placed after the restore because dst_reg == src_reg means we need src_reg intact to read ctx->temp. | ||||
| CVE-2026-47386 | 1 Nocodb | 1 Nocodb | 2026-06-24 | N/A |
| NocoDB is software for building databases as spreadsheets. Prior to 2026.05.1, two concurrent token-exchange requests using the same OAuth authorization code could each mint a distinct valid (access_token, refresh_token) pair, breaking the single-use guarantee that PKCE relies on. This vulnerability is fixed in 2026.05.1. | ||||
| CVE-2026-46550 | 1 Nocodb | 1 Nocodb | 2026-06-24 | 5.4 Medium |
| NocoDB is software for building databases as spreadsheets. Prior to 2026.04.1, the refresh-token cookie was set with httpOnly: true but missing both the secure flag and the sameSite attribute. Over plain HTTP the cookie could be intercepted on the network; without sameSite, browsers attached it to cross-site POSTs, enabling CSRF against the token-refresh endpoint. This vulnerability is fixed in 2026.04.1. | ||||
| CVE-2026-52952 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: iommu: Fix WARN_ON in __iommu_group_set_domain_nofail() due to reset In __iommu_group_set_domain_internal(), concurrent domain attachments are rejected when any device in the group is recovering. This is necessary to fence concurrent attachments to a multi-device group where devices might share the same RID due to PCI DMA alias quirks, but triggers the WARN_ON in __iommu_group_set_domain_nofail(). Other IOMMU_SET_DOMAIN_MUST_SUCCEED callers in detach/teardown paths, such as __iommu_group_set_core_domain and __iommu_release_dma_ownership, should not be rejected, as the domain would be freed anyway in these nofail paths while group->domain is still pointing to it. So pci_dev_reset_iommu_done() could trigger a UAF when re-attaching group->domain. Honor the IOMMU_SET_DOMAIN_MUST_SUCCEED flag, allowing the callers through the group->recovery_cnt fence, so as to update the group->domain pointer. Instead add a gdev->blocked check in the device iteration loop, to prevent any concurrent per-device detachment. | ||||
| CVE-2026-52959 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: virt: sev-guest: Do not use host-controlled page order in cleanup path When issuing an extended guest request (SVM_VMGEXIT_EXT_GUEST_REQUEST), get_ext_report() allocates a buffer to retrieve a certificate blob from the host, keeping track of its size in report_req->certs_len. However, the host may return SNP_GUEST_VMM_ERR_INVALID_LEN, indicating an invalid buffer size, as well as the expected length of such buffer. get_ext_report() subsequently updates report_req->certs_len with the host-controlled value, and cleans up the buffer by computing a page order from such value. This is incorrect, as the host-provided length may not match the page order of the original allocation, potentially resulting in corruption in the page allocator. Fix this by using alloc_pages_exact() instead, and reusing @npages to compute the size passed to free_pages_exact(). For consistency, also use @npages to compute the size when allocating the pages, even though this last change has no functional effect. | ||||
| CVE-2026-52961 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ceph: fix BUG_ON in __ceph_build_xattrs_blob() due to stale blob size The generic/642 test-case can reproduce the kernel crash: [40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr ceph_con_workfn [40243.612715] RIP: 0010:__ceph_build_xattrs_blob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] <TASK> [40243.628188] __prep_cap+0x3fd/0x4a0 [40243.628789] ? do_raw_spin_unlock+0x4e/0xe0 [40243.629474] ceph_check_caps+0x46a/0xc80 [40243.630094] ? __lock_acquire+0x4a2/0x2650 [40243.630773] ? find_held_lock+0x31/0x90 [40243.631347] ? handle_cap_grant+0x79f/0x1060 [40243.632068] ? lock_release+0xd9/0x300 [40243.632696] ? __mutex_unlock_slowpath+0x3e/0x340 [40243.633429] ? lock_release+0xd9/0x300 [40243.634052] handle_cap_grant+0xcf6/0x1060 [40243.634745] ceph_handle_caps+0x122b/0x2110 [40243.635415] mds_dispatch+0x5bd/0x2160 [40243.636034] ? ceph_con_process_message+0x65/0x190 [40243.636828] ? lock_release+0xd9/0x300 [40243.637431] ceph_con_process_message+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] process_message+0x16/0x1a0 [40243.639915] ? sg_free_table+0x39/0x90 [40243.640572] ceph_con_v2_try_read+0xf58/0x2120 [40243.641255] ? lock_acquire+0xc8/0x300 [40243.641863] ceph_con_workfn+0x151/0x820 [40243.642493] process_one_work+0x22f/0x630 [40243.643093] ? process_one_work+0x254/0x630 [40243.643770] worker_thread+0x1e2/0x400 [40243.644332] ? __pfx_worker_thread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? __pfx_kthread+0x10/0x10 [40243.646125] ret_from_fork+0x3f8/0x480 [40243.646752] ? __pfx_kthread+0x10/0x10 [40243.647316] ? __pfx_kthread+0x10/0x10 [40243.647919] ret_from_fork_asm+0x1a/0x30 [40243.648556] </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intel_rapl_msr intel_rapl_common intel_uncore_frequency_common skx_edac_common nfit kvm_intel kvm irqbypass joydev ghash_clmulni_intel aesni_intel rapl input_leds mac_hid psmouse vga16fb serio_raw vgastate floppy i2c_piix4 pata_acpi bochs qemu_fw_cfg i2c_smbus sch_fq_codel rbd dm_crypt msr parport_pc ppdev lp parport efi_pstore [40243.654766] ---[ end trace 0000000000000000 ]--- Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the required_blob_size computation to before the __build_xattrs() call, introducing a race. __build_xattrs() releases and reacquires i_ceph_lock during execution. In that window, handle_cap_grant() may update i_xattrs.blob with a newer MDS-provided blob and bump i_xattrs.version. When __bui ---truncated--- | ||||
| CVE-2026-52971 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: net: ena: PHC: Fix potential use-after-free in get_timestamp Move the phc->active check and resp pointer assignment to after acquiring the spinlock. Previously, phc->active was checked without holding the lock, and resp was cached from ena_dev->phc.virt_addr before the lock was acquired. If ena_com_phc_destroy() runs between the lockless active check and the lock acquisition, it sets active=false, releases the lock, frees the DMA memory, and sets virt_addr=NULL. The get_timestamp path would then read a NULL virt_addr and dereference it. With both the active check and the pointer read under the lock, destroy cannot free the memory while get_timestamp is using it. | ||||
| CVE-2026-53007 | 1 Linux | 1 Linux Kernel | 2026-06-24 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ice: fix potential NULL pointer deref in error path of ice_set_ringparam() ice_set_ringparam nullifies tstamp_ring of temporary tx_rings, without clearing ICE_TX_RING_FLAGS_TXTIME bit. When ICE_TX_RING_FLAGS_TXTIME is set and the subsequent ice_setup_tx_ring() call fails, a NULL pointer dereference could happen in the unwinding sequence: ice_clean_tx_ring() -> ice_is_txtime_cfg() == true (ICE_TX_RING_FLAGS_TXTIME is set) -> ice_free_tx_tstamp_ring() -> ice_free_tstamp_ring() -> tstamp_ring->desc (NULL deref) Clear ICE_TX_RING_FLAGS_TXTIME bit to avoid the potential issue. Note that this potential issue is found by manual code review. Compile test only since unfortunately I don't have E830 devices. | ||||