Export limit exceeded: 425863 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (95390 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2024-31828 | 1 Lavalite | 2 Cms, Lavalite | 2026-08-24 | 6.1 Medium |
| Cross Site Scripting vulnerability in Lavalite CMS v.10.1.0 allows attackers to execute arbitrary code and obtain sensitive information via a crafted payload to the URL. | ||||
| CVE-2024-3154 | 1 Redhat | 1 Openshift | 2026-08-24 | 7.2 High |
| A flaw was found in cri-o, where an arbitrary systemd property can be injected via a Pod annotation. Any user who can create a pod with an arbitrary annotation may perform an arbitrary action on the host system. | ||||
| CVE-2026-28166 | 2 Goodlayers, Wordpress | 2 Tour Master, Wordpress | 2026-08-24 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in Tourmaster <= 5.4.9 versions. | ||||
| CVE-2026-66610 | 2 Thembay, Wordpress | 2 Urna, Wordpress | 2026-08-24 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in Urna <= 2.6.2 versions. | ||||
| CVE-2026-28162 | 2 Franky, Wordpress | 2 Events Made Easy, Wordpress | 2026-08-24 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in Events Made Easy <= 3.2.5 versions. | ||||
| CVE-2026-78290 | 2 Themegrill, Wordpress | 2 Magazine Blocks, Wordpress | 2026-08-24 | 6.5 Medium |
| Contributor Cross Site Scripting (XSS) in Magazine Blocks <= 1.8.6 versions. | ||||
| CVE-2026-66917 | 1 Joomgalleryfriends.net | 1 Joomgallery Extension For Joomla | 2026-08-24 | N/A |
| Joomla Extension - joomgalleryfriends.net - Stored XSS in JoomGallery < 4.4.0 - An authenticated, privileged can store an XSS payload in any image causing JS execution in every visitor's browser. | ||||
| CVE-2026-66623 | 2 Inisev, Wordpress | 2 Social Media & Share Icons, Wordpress | 2026-08-24 | 7.1 High |
| Unauthenticated Cross Site Scripting (XSS) in Social Media & Share Icons <= 2.9.9 versions. | ||||
| CVE-2026-4561 | 2 Dvankooten, Wordpress | 2 Mc4wp: Mailchimp For Wordpress, Wordpress | 2026-08-24 | 6.4 Medium |
| The MC4WP: Mailchimp for WordPress plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the form response message post meta fields (e.g., 'text_subscribed', 'text_error') in all versions up to, and including, 4.12.0 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Author-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. | ||||
| CVE-2026-78246 | 1 Itsourcecode | 1 Online Clinic Management System | 2026-08-24 | 7.3 High |
| A vulnerability has been found in itsourcecode Online Clinic Management System 1.0. This vulnerability affects unknown code of the file success/login.php of the component Admin Login. The manipulation of the argument Username leads to sql injection. Remote exploitation of the attack is possible. The exploit has been disclosed to the public and may be used. | ||||
| CVE-2026-50290 | 1 Asymmetric-effort | 1 Specifyjs | 2026-08-23 | N/A |
| SpecifyJS is a declarative TypeScript user interface framework. Prior to version 0.2.136, CSS value sanitization stripped `expression(` and `url(javascript:` using simple regex, but could be bypassed with CSS unicode escapes (`\65xpression(`), null bytes, or CSS comments (`exp/**/ression(`). These CSS injection vectors only work in legacy browsers (IE6-IE10). SpecifyJS targets modern browsers. Starting in version 0.2.136, CSS sanitization now normalizes unicode escapes and strips CSS comments before pattern matching. Also checks for `behavior:`, `-moz-binding`, and `-o-link` patterns. | ||||
| CVE-2026-53529 | 1 Perber | 1 Leafwiki | 2026-08-23 | N/A |
| LeafWiki is a self-hosted wiki. Prior to version 0.10.2, page titles returned by the search API could be rendered as raw HTML in the frontend. A user with editor or administrator permissions could create or modify a page title containing an HTML/JavaScript payload. When another user searched for a matching term, the payload could execute in the victim’s browser. The impact depends on deployment configuration. With `--public-access` enabled, unauthenticated visitors could be affected. In authenticated-only deployments, the issue could be used for cross-user XSS against logged-in users who can access search results. The issue has been fixed in version 0.10.2 by ensuring that author-controlled page titles in search results are not interpreted as raw HTML by the browser while preserving search result highlighting. | ||||
| CVE-2026-77115 | 1 Brave | 1 Brave | 2026-08-23 | 7.1 High |
| Brave Popup Builder (brave-popup-builder) up to version 0.8.5 reflects UTM query parameters into popup form HTML without escaping them. | ||||
| CVE-2026-74494 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: reject repeated SMB2 NEGOTIATE requests Unauthenticated client can send multiple successful SMB2 NEGOTIATE requests on one connection before SESSION_SETUP. While the connection is in KSMBD_SESS_NEED_SETUP, smb2_handle_negotiate() accepts another SMB3.1.1 NEGOTIATE and overwrites conn->preauth_info with a new allocation. Only the final allocation is freed when the connection is released, leaking one object for every additional successful request. A repeated SMB2 NEGOTIATE after a dialect has been selected is a protocol violation. MS-SMB2 section 3.3.5.4 requires the server to disconnect without replying in this case. Set the connection exiting when rejecting the request, in addition to suppressing the response. Reject SMB2 NEGOTIATE unless the connection is new or is waiting for the SMB2 NEGOTIATE that follows an SMB1 multi-protocol negotiate. Serialize both SMB1 and SMB2 negotiation paths under conn->srv_mutex, since they update connection-wide dialect and negotiation state. Move the locking contract to ksmbd_smb_negotiate_common(), where the state and dialect are selected, and add ksmbd_conn_new() for consistent state access. | ||||
| CVE-2026-72216 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: remoteproc: qcom: Fix leak when custom dump_segments addition fails Free allocated minidump_region 'name' in qcom_add_minidump_segments() when failing before adding the region to 'dump_segments'. Otherwise, the 'name' is not tracked and is never freed by qcom_minidump_cleanup(). Return error when adding to 'dump_segments' fails. | ||||
| CVE-2026-72077 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Input: ims-pcu - fix firmware leak in async update The firmware object was not being released if validation failed. Use __free(firmware) to ensure the firmware is always released. | ||||
| CVE-2026-72058 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: ixp4xx_hss: fix duplicate HDLC netdev allocation ixp4xx_hss_probe() allocates two HDLC netdevs. The first one is stored in ndev, initialized, and registered with register_hdlc_device(). The second one is stored in port->netdev and later used by the remove path for unregister_hdlc_device() and free_netdev(). This means that the registered netdev is not the same object that is unregistered and freed on remove. It also leaks the first allocation if the second alloc_hdlcdev() call fails, and the first allocation is not checked before ndev is used. Older code allocated the HDLC netdev only once and stored the same object in both the local variable and port->netdev. The buggy conversion split this into two alloc_hdlcdev() calls. A later rename changed the local variable name to ndev, but the underlying mismatch remained. Fix this by allocating the HDLC netdev only once and assigning the same object to port->netdev. | ||||
| CVE-2026-72023 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: fix SQB pointer leak on init failure otx2_init_hw_resources() initializes SQ aura and pool resources before several later setup steps. On failure, err_free_sq_ptrs only frees SQB pages, leaving the per-SQ sqb_ptrs arrays behind. Use otx2_free_sq_res() for the SQ unwind path and let it free sqb_ptrs even when sq->sqe has not been allocated yet. The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1. An x86_64 allyesconfig build showed no new warnings. As we do not have an OcteonTX2 PF device and the corresponding AF mailbox setup to test with, no runtime testing was able to be performed. | ||||
| CVE-2026-72017 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: macb: drop in-flight Tx SKBs on close The MACB driver has since forever leaked the outgoing SKBs that have not yet been marked as completed. They live in queue->tx_skb which gets freed without remorse nor checking. macb_free_consistent() gets called in a few codepaths, but only close will trigger the added expressions. In macb_open() and macb_alloc_consistent() failure cases, queues' tx_skb just got allocated and are empty. | ||||
| CVE-2026-68150 | 1 Linux | 1 Linux Kernel | 2026-08-23 | 4.1 Medium |
| In the Linux kernel, the following vulnerability has been resolved: fs/super: fix emergency thaw double-unlock of s_umount do_thaw_all() iterates over all superblocks via __iterate_supers() with SUPER_ITER_EXCL, which acquires s_umount exclusively before calling the callback and releases it afterwards. However, the callback do_thaw_all_callback() calls thaw_super_locked() which unconditionally releases s_umount on every code path. This results in a second unlock attempt in __iterate_supers() that corrupts the rwsem state, triggering a DEBUG_RWSEMS warning: [ 182.601148] sysrq: Emergency Thaw of all frozen filesystems [ 182.601865] ------------[ cut here ]------------ [ 182.602375] DEBUG_RWSEMS_WARN_ON((rwsem_owner(sem) != current) && !rwsem_test_oflags(sem, RWSEM_NONSPINNABLE)): count = 0x0, magic = 0xffff99b1011e5870, owner = 0x0, curr 0xffff99b101b06c80, list not empty [ 182.603817] WARNING: kernel/locking/rwsem.c:1412 at up_write+0xa3/0x170, CPU#2: kworker/2:1/53 [ 182.604578] Modules linked in: [ 182.604864] CPU: 2 UID: 0 PID: 53 Comm: kworker/2:1 Not tainted 7.2.0-rc4-00001-gbd3bd93ea98a-dirty #4 PREEMPT(lazy) [ 182.605711] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1kylin1 04/01/2014 [ 182.606417] Workqueue: events do_thaw_all [ 182.606750] RIP: 0010:up_write+0xaf/0x170 [ 182.607076] Code: 19 3a 92 48 0f 44 c2 48 8b 55 08 48 8b 55 00 4c 8b 45 08 48 8b 55 00 48 8d 3d ad 91 e0 01 48 8b 4d 20 50 48 c7 c6 f0 8c 26 92 <67> 48 0f b9 3a e8 d7 93 4e 00 58 eb 81 48 83 7f 18 00 48 c7 c2 8d [ 182.608563] RSP: 0018:ffffb670001d7e08 EFLAGS: 00010246 [ 182.609007] RAX: ffffffff92349e8d RBX: 0000000000000000 RCX: ffff99b1011e5870 [ 182.609595] RDX: 0000000000000000 RSI: ffffffff92268cf0 RDI: ffffffff92914d10 [ 182.610283] RBP: ffff99b1011e5870 R08: 0000000000000000 R09: ffff99b101b06c80 [ 182.610847] R10: ffff99b10139a808 R11: fefefefefefefeff R12: 0000000000000000 [ 182.611414] R13: ffffffff90cf74d0 R14: 0000000000000000 R15: ffff99b1011e5800 [ 182.612009] FS: 0000000000000000(0000) GS:ffff99b1eaaee000(0000) knlGS:0000000000000000 [ 182.612670] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 182.613146] CR2: 00000000005c631c CR3: 00000000013ee000 CR4: 00000000000006f0 [ 182.613722] Call Trace: [ 182.613946] <TASK> [ 182.614130] __iterate_supers+0x128/0x150 [ 182.614463] do_thaw_all+0x1b/0x30 [ 182.614759] process_scheduled_works+0xbb/0x3f0 [ 182.615150] ? __pfx_worker_thread+0x10/0x10 [ 182.615499] worker_thread+0x129/0x270 [ 182.615816] ? __pfx_worker_thread+0x10/0x10 [ 182.616201] kthread+0xe2/0x120 [ 182.616469] ? __pfx_kthread+0x10/0x10 [ 182.616792] ret_from_fork+0x15b/0x240 [ 182.617115] ? __pfx_kthread+0x10/0x10 [ 182.617426] ret_from_fork_asm+0x1a/0x30 [ 182.617761] </TASK> [ 182.617968] ---[ end trace 0000000000000000 ]--- [ 182.618412] Emergency Thaw complete Fix this by switching to SUPER_ITER_UNLOCKED and acquiring s_umount in the callback via super_lock_excl() before calling thaw_super_locked(). This matches the locking pattern expected by thaw_super_locked() and eliminates the double unlock. While at it, remove the dead 'return;' at the end of do_thaw_all_callback(). | ||||