Export limit exceeded: 95075 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (95075 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-68580 | 1 Freerdp | 1 Freerdp | 2026-08-05 | 7.5 High |
| FreeRDP before 3.29.0 contains integer overflow vulnerabilities in the audio input redirection channel (audin) across ALSA, sndio, WinMM, and OpenSL ES backends that fail to validate the FramesPerPacket parameter from RDP servers. Attackers can supply a malicious FramesPerPacket value causing allocation size wraparound, resulting in heap-based buffer overflow on ALSA or denial of service on all platforms. | ||||
| CVE-2026-66310 | 1 Microsoft | 1 Edge | 2026-08-05 | 7.7 High |
| External control of file name or path in Microsoft Edge for Android allows an unauthorized attacker to disclose information locally. | ||||
| CVE-2026-18902 | 1 H3c | 1 Nx15 | 2026-08-05 | 7.2 High |
| A vulnerability was detected in H3C NX15 V100R017. Affected by this vulnerability is the function esps.wan.repeater.set/repeaterproc of the file /api/esps. Performing a manipulation of the argument my2P4key results in command injection. Remote exploitation of the attack is possible. The exploit is now public and may be used. The vendor was contacted early about this disclosure. | ||||
| CVE-2026-60009 | 1 Eclipse | 1 Theia | 2026-08-05 | 8.8 High |
| In Eclipse Theia versions up to and including 1.73.1, the `@theia/filesystem` backend binds `POST /file-upload` in every filesystem-enabled deployment. The handler takes an attacker-supplied absolute path from the multipart `uri` field and calls `fs.move(tmp, target, { overwrite: true })` with no workspace confinement and no authentication. In browser (non-Electron) deployments the connection token is enforced only on WebSocket upgrades; the HTTP middleware in `@theia/core` re-issues the cookie and calls `next()` without rejecting tokenless HTTP requests. Because `multipart/form-data` is a CORS-safelisted request type, a cross-origin web page can trigger the write with no preflight and no credentials, resulting in an unauthenticated arbitrary file write outside the workspace to any absolute path the backend process can write. This can escalate to remote code execution, for example by overwriting a startup-executed file such as `~/.bashrc`. Electron mode uses a separate `ElectronSecurityToken` and is not affected via this path. | ||||
| CVE-2026-18881 | 2 Realmag777, Wordpress | 2 Tableon – Wordpress Posts Table Filterable, Wordpress | 2026-08-05 | 7.5 High |
| The TableOn – WordPress Posts Table Filterable plugin for WordPress is vulnerable to blind SQL Injection via the `filter_data[comment_count]` parameter of the public `tableon_get_table_data` AJAX action in all versions up to, and including, 1.0.5.1. This is due to insufficient escaping on the user-supplied parameter and lack of sufficient preparation on the existing SQL query — the value is split on `:` and both halves are interpolated directly into a `posts_where` SQL clause without `intval()` casting or `$wpdb->prepare()`. This makes it possible for unauthenticated attackers to append additional SQL queries into the already-existing query that can be used to extract sensitive information from the database (researcher demonstrated extraction of database(), wp_users.user_login, and wp_users.user_pass). | ||||
| CVE-2026-6079 | 2 Ho3einie, Wordpress | 2 Material Dashboard, Wordpress | 2026-08-05 | 7.3 High |
| The Material Dashboard plugin for WordPress is vulnerable to unauthorized access and modification of data due to missing capability checks on the amd_ajax_target_task_manager() function in all versions up to, and including, 1.4.10. This makes it possible for unauthenticated attackers to enumerate all scheduled tasks (potentially exposing PII), execute arbitrary tasks, and delete any task via the public_amd_ajax_handler AJAX action. | ||||
| CVE-2026-67200 | 1 Perspective-dev | 1 Perspective | 2026-08-05 | 7.5 High |
| Perspective 5.0.0 contains a path traversal vulnerability that allows unauthenticated remote attackers to read arbitrary files from the server filesystem by including literal ../ segments in HTTP request URL paths. Attackers can bypass the insufficient query-string-stripping sanitization to traverse outside the configured asset root directory and retrieve sensitive files such as system credentials and application secrets, with results exposed cross-origin due to a wildcard Access-Control-Allow-Origin header set on all responses. | ||||
| CVE-2026-59675 | 1 Suse | 1 Rancher | 2026-08-05 | 7.5 High |
| When API audit logging is enabled, the middleware reads the entire HTTP request body into memory without enforcing a size limit on login endpoints. Because the audit middleware is positioned earlier in the handler chain than Rancher's APIBodyLimitingHandler, the body-size cap (default 1 MiB) is bypassed for requests that pass through the audit copyReqBody path. An unauthenticated attacker can send arbitrarily large request bodies to the public login endpoints, causing the Rancher Manager server process to allocate memory proportional to the supplied body size. With just a few concurrent connections, this can exhaust available memory and terminate the Rancher Manager plane process, making the Rancher API and UI unavailable and interrupting management of all downstream clusters. | ||||
| CVE-2026-7520 | 2 Mailmunch, Wordpress | 2 Mailmunch Forms For Mailchimp, Wordpress | 2026-08-05 | 8.1 High |
| The MailChimp Forms by MailMunch plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the `sign_in()` and `sign_up()` AJAX handlers in all versions up to, and including, 3.2.7. This makes it possible for authenticated attackers, with Subscriber-level access and above, to relink the site's MailMunch integration to an attacker-controlled MailMunch account by submitting attacker-supplied credentials. Once relinked, all subscriber data captured by the plugin's forms is delivered to the attacker, and the forms/landing pages rendered on the site are pulled from the attacker's MailMunch account. | ||||
| CVE-2026-21548 | 1 Unisoc | 4 T8100, T8200, T8300 and 1 more | 2026-08-05 | 7.5 High |
| In nr modem, there is a possible improper input validation. This could lead to remote denial of service with System execution privileges needed. | ||||
| CVE-2026-21549 | 1 Unisoc | 4 T8100, T8200, T8300 and 1 more | 2026-08-05 | 7.5 High |
| In modem, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed | ||||
| CVE-2026-21550 | 1 Unisoc | 4 T8100, T8200, T8300 and 1 more | 2026-08-05 | 7.5 High |
| In modem, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed | ||||
| CVE-2026-21551 | 1 Unisoc | 4 T8100, T8200, T8300 and 1 more | 2026-08-05 | 7.5 High |
| In modem, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed | ||||
| CVE-2026-21552 | 1 Unisoc | 4 T8100, T8200, T8300 and 1 more | 2026-08-05 | 7.5 High |
| In modem, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed | ||||
| CVE-2026-21553 | 1 Unisoc | 4 T8100, T8200, T8300 and 1 more | 2026-08-05 | 7.5 High |
| In modem, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed | ||||
| CVE-2026-21554 | 1 Unisoc | 1 Udx710 | 2026-08-05 | 7.5 High |
| In modem, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed | ||||
| CVE-2026-21555 | 1 Unisoc | 1 Udx710 | 2026-08-05 | 7.5 High |
| In modem, there is a possible improper input validation. This could lead to remote denial of service with no additional execution privileges needed | ||||
| CVE-2026-25703 | 1 Suse | 1 Neuvector | 2026-08-05 | 7.3 High |
| NeuVector through 5.4.9 is can potentially leak information from manager /network/graph API due to missing authentication and cached data containing sensitive information. | ||||
| CVE-2024-58070 | 1 Linux | 1 Linux Kernel | 2026-08-05 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: bpf: bpf_local_storage: Always use bpf_mem_alloc in PREEMPT_RT In PREEMPT_RT, kmalloc(GFP_ATOMIC) is still not safe in non preemptible context. bpf_mem_alloc must be used in PREEMPT_RT. This patch is to enforce bpf_mem_alloc in the bpf_local_storage when CONFIG_PREEMPT_RT is enabled. [ 35.118559] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 35.118566] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1832, name: test_progs [ 35.118569] preempt_count: 1, expected: 0 [ 35.118571] RCU nest depth: 1, expected: 1 [ 35.118577] INFO: lockdep is turned off. ... [ 35.118647] __might_resched+0x433/0x5b0 [ 35.118677] rt_spin_lock+0xc3/0x290 [ 35.118700] ___slab_alloc+0x72/0xc40 [ 35.118723] __kmalloc_noprof+0x13f/0x4e0 [ 35.118732] bpf_map_kzalloc+0xe5/0x220 [ 35.118740] bpf_selem_alloc+0x1d2/0x7b0 [ 35.118755] bpf_local_storage_update+0x2fa/0x8b0 [ 35.118784] bpf_sk_storage_get_tracing+0x15a/0x1d0 [ 35.118791] bpf_prog_9a118d86fca78ebb_trace_inet_sock_set_state+0x44/0x66 [ 35.118795] bpf_trace_run3+0x222/0x400 [ 35.118820] __bpf_trace_inet_sock_set_state+0x11/0x20 [ 35.118824] trace_inet_sock_set_state+0x112/0x130 [ 35.118830] inet_sk_state_store+0x41/0x90 [ 35.118836] tcp_set_state+0x3b3/0x640 There is no need to adjust the gfp_flags passing to the bpf_mem_cache_alloc_flags() which only honors the GFP_KERNEL. The verifier has ensured GFP_KERNEL is passed only in sleepable context. It has been an old issue since the first introduction of the bpf_local_storage ~5 years ago, so this patch targets the bpf-next. bpf_mem_alloc is needed to solve it, so the Fixes tag is set to the commit when bpf_mem_alloc was first used in the bpf_local_storage. | ||||
| CVE-2024-53111 | 1 Linux | 1 Linux Kernel | 2026-08-05 | 7.1 High |
| In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an "orig_old_start" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include <stdlib.h> #include <stdio.h> #include <err.h> #include <sys/mman.h> #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, "mmap 1"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, "mmap 2"); *p1 = 0x41; printf("first char is 0x%02hhx\n", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf("mremap() failed; first char is 0x%02hhx\n", *p1); } else { printf("mremap() succeeded; first char is 0x%02hhx\n", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ``` | ||||