Export limit exceeded: 361835 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.

Search

Search Results (361835 CVEs found)

CVE Vendors Products Updated CVSS v3.1
CVE-2026-57426 2026-07-02 7.1 High
Unauthenticated Cross Site Scripting (XSS) in Modula - PRO <= 2.10.8 versions.
CVE-2026-57677 2026-07-02 9.8 Critical
Unauthenticated PHP Object Injection in Novalnet Payment Gateway for WooCommerce <= 12.10.3 versions.
CVE-2026-57684 2026-07-02 6.5 Medium
Contributor Cross Site Scripting (XSS) in TheFox <= 3.9.70 versions.
CVE-2026-57690 2026-07-02 4.3 Medium
Unauthenticated Cross Site Request Forgery (CSRF) in Werkstatt <= 4.7.2 versions.
CVE-2026-57749 2026-07-02 7.5 High
Contributor Local File Inclusion in SportsPress Pro <= 2.7.29 versions.
CVE-2026-32280 2 Go Standard Library, Golang 2 Crypto/x509, Go 2026-07-02 7.5 High
During chain building, the amount of work that is done is not correctly limited when a large number of intermediate certificates are passed in VerifyOptions.Intermediates, which can lead to a denial of service. This affects both direct users of crypto/x509 and users of crypto/tls.
CVE-2026-57755 2026-07-02 6.5 Medium
Contributor Cross Site Scripting (XSS) in Mosaic Gallery &#8211; Advanced Gallery <= 1.2.0 versions.
CVE-2026-37106 1 Dokuwiki 1 Dokuwiki 2026-07-02 9.8 Critical
An issue in DokuWiki 2025-05-14b "Librarian" 56.2 allows a remote attacker to create an account via the register function in inc/auth.php. NOTE: this is disputed by the Supplier because this is the intentional behavior when the product is configured for self-registration (a non-default feature).
CVE-2026-57762 2026-07-02 5.9 Medium
Author Cross Site Scripting (XSS) in Simple URLs <= 151 versions.
CVE-2026-13835 1 Google 1 Chrome 2026-07-02 8.8 High
Inappropriate implementation in XML in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)
CVE-2026-13936 1 Google 1 Chrome 2026-07-02 6.5 Medium
Inappropriate implementation in Passwords in Google Chrome on Android prior to 150.0.7871.47 allowed a remote attacker to obtain potentially sensitive information from process memory via a crafted HTML page. (Chromium security severity: Medium)
CVE-2026-27402 2026-07-02 7.1 High
Unauthenticated Cross Site Scripting (XSS) in Kids Life | Children School WordPress <= 5.2 versions.
CVE-2025-58902 2026-07-02 8.1 High
Unauthenticated Local File Inclusion in Lighthouse <= 1.2.12 versions.
CVE-2026-57685 2026-07-02 4.3 Medium
Subscriber Broken Access Control in Martfury - WooCommerce Marketplace WordPress Theme <= 3.2.8 versions.
CVE-2026-57679 2026-07-02 9.3 Critical
Unauthenticated SQL Injection in GeekyBot <= 1.2.5 versions.
CVE-2026-14046 1 Google 1 Chrome 2026-07-02 4.3 Medium
Inappropriate implementation in CustomTabs in Google Chrome on Android prior to 150.0.7871.47 allowed a remote attacker to bypass same origin policy via a crafted HTML page. (Chromium security severity: Low)
CVE-2026-13323 1 Eclipse 1 Open Vsx 2026-07-02 4.1 Medium
In Open VSX Registry before 1.0.2, the /vscode/unpkg/ endpoint serves user-supplied HTML files with Content-Type: text/html and without a Content-Security-Policy or Content-Disposition: attachment response header. An unauthenticated attacker can register a publisher account, upload a VSIX containing a crafted HTML payload, and induce an authenticated user to visit the resulting URL. The browser renders the file inline in the open-vsx.org origin context, enabling session token exfiltration, persistent Personal Access Token (PAT) generation, and unauthorized publication of malicious extension versions. Because Open VSX extensions are distributed to VS Code, VSCodium, Cursor, Windsurf, and compatible editors, a compromised extension update constitutes a supply chain attack against all downstream users.
CVE-2026-53341 1 Linux 1 Linux Kernel 2026-07-02 7.0 High
In the Linux kernel, the following vulnerability has been resolved: fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh() may_decode_fh() accesses mount::mnt_ns without holding any locks; that means the mount can concurrently be unmounted, and the mnt_namespace can concurrently be freed after an RCU grace period. This race can happens as follows, assuming that the mount point was created by open_tree(..., OPEN_TREE_CLONE): thread 1 thread 2 RCU __do_sys_open_by_handle_at do_handle_open handle_to_path may_decode_fh is_mounted [mount::mnt_ns access] [mount::mnt_ns access] __do_sys_close fput_close_sync __fput dissolve_on_fput umount_tree class_namespace_excl_destructor namespace_unlock free_mnt_ns mnt_ns_tree_remove call_rcu(mnt_ns_release_rcu) mnt_ns_release_rcu mnt_ns_release kfree [mnt_namespace::user_ns access] **UAF** Fix it by taking rcu_read_lock() around the mount::mnt_ns access, like in __prepend_path(). Additionally, document the semantics of mount::mnt_ns, and use WRITE_ONCE() for writers that can race with lockless readers. This bug is unreachable unless one of the following is set: - CONFIG_PREEMPTION - CONFIG_RCU_STRICT_GRACE_PERIOD because it requires an RCU grace period to happen during a syscall without an explicit preemption. This doesn't seem to have interesting security impact; worst-case, it could leak the result of an integer comparison to userspace (from the level check in cap_capable()), cause an endless loop, or crash the kernel by dereferencing an invalid address.
CVE-2026-54430 2026-07-02 N/A
liboauth2 is vulnerable to Server-Side Request Forgery in oauth2_jose_jwks_aws_alb_resolve() function. The AWS ALB verifier reads both signer and kid from the unverified JWT header. If signer matches the configured ARN, kid is appended to alb_base_url without URL encoding or path sanitization, and the HTTP GET is issued before signature verification. This allows an attacker to force the server to send a GET request to an attacker-chosen internal path. This issue was fixed in version 2.3.0
CVE-2026-53352 1 Linux 1 Linux Kernel 2026-07-02 5.5 Medium
In the Linux kernel, the following vulnerability has been resolved: signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads() When a multi-threaded process receives a stop signal (e.g., SIGSTOP), do_signal_stop() sets JOBCTL_STOP_PENDING and JOBCTL_STOP_CONSUME on all threads and sets signal->group_stop_count to the number of threads. If one of the threads concurrently calls execve(), de_thread() invokes zap_other_threads() to kill all other threads. zap_other_threads() aborts the pending group stop by resetting signal->group_stop_count to 0 and clears the JOBCTL_PENDING_MASK for all other threads. However, it fails to clear the job control flags for the calling thread. When execve() completes, the calling thread returns to user mode and checks for pending signals. Seeing the stale JOBCTL_STOP_PENDING flag, it calls do_signal_stop(), which invokes task_participate_group_stop(). Since JOBCTL_STOP_CONSUME is still set, it attempts to decrement the already-zero signal->group_stop_count, triggering a warning: sig->group_stop_count == 0 WARNING: CPU: 1 PID: 6475 at kernel/signal.c:373 task_participate_group_stop+0x215/0x2d0 Call Trace: <TASK> do_signal_stop+0x3be/0x5c0 kernel/signal.c:2619 get_signal+0xa8c/0x1330 kernel/signal.c:2884 arch_do_signal_or_restart+0xbc/0x840 arch/x86/kernel/signal.c:337 exit_to_user_mode_loop+0x8c/0x4d0 kernel/entry/common.c:98 do_syscall_64+0x33e/0xf80 arch/x86/entry/syscall_64.c:100 entry_SYSCALL_64_after_hwframe+0x77/0x7f </TASK> Fix this race condition by clearing the JOBCTL_PENDING_MASK for the calling thread in zap_other_threads(), ensuring it does not retain any stale job control state after the thread group is destroyed. This aligns with other functions that tear down a thread group and abort group stops, such as zap_process() and complete_signal(), which correctly clear these flags for all threads including the current one.