Export limit exceeded: 373410 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Export limit exceeded: 373410 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (373410 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-70372 | 1 Koha-community | 1 Koha | 2026-08-05 | 8.8 High |
| Koha's reports/bor_issues_top.pl builds dynamic SQL in sub calculate by concatenating several user-controlled request parameters directly into the query string. The Criteria parameter is only normalized by a table-name prefix and is never whitelisted, landing verbatim in identifier positions (SELECT DISTINCTROW, GROUP BY, ORDER BY); Filter values are concatenated raw into single-quoted LIKE, BETWEEN, and comparison fragments, and the Limit parameter is appended raw to a LIMIT clause. An authenticated staff user holding the reports module permission can inject arbitrary SQL and read any table reachable by the Koha database user, including borrowers (password hashes, two-factor secrets, personal data), api_keys, and sessions. | ||||
| CVE-2026-70371 | 1 Koha-community | 1 Koha | 2026-08-05 | 8.8 High |
| Koha's reports/issues_avg_stats.pl builds dynamic SQL in sub calculate by concatenating several user-controlled request parameters directly into the query string. The Line and Column parameters are not validated against any whitelist and land verbatim in identifier positions (SELECT DISTINCTROW, GROUP BY, ORDER BY), and each Filter slot is concatenated raw into single-quoted LIKE, BETWEEN, and comparison fragments with no bound parameters. An authenticated staff user holding the reports module permission can inject arbitrary SQL and read any table reachable by the Koha database user, including borrowers (password hashes, two-factor secrets, personal data), api_keys, and sessions. | ||||
| CVE-2026-70370 | 1 Koha-community | 1 Koha | 2026-08-05 | 8.8 High |
| Koha's reports/catalogue_stats.pl builds dynamic SQL in sub calculate by interpolating the user-controlled Line and Column request parameters directly into identifier positions of the query (SELECT DISTINCTROW, GROUP BY, ORDER BY) with no whitelist validation. When Line contains itemcallnumber and the cotedigits parameter is truthy, cotedigits is additionally concatenated raw as the numeric argument of a LEFT() call. An authenticated staff user holding the reports module permission can inject arbitrary SQL and read any table reachable by the Koha database user, including borrowers (password hashes, two-factor secrets, personal data), api_keys, and sessions. | ||||
| CVE-2026-70369 | 1 Koha-community | 1 Koha | 2026-08-05 | 8.8 High |
| Koha's reports/acquisitions_stats.pl builds its per-cell statistics query in sub calculate by interpolating the user-controlled Filter request parameters directly into WHERE fragments covering aqbasket.closedate, aqorders.datereceived, aqbooksellers.name, items.homebranch, items.ccode, biblioitems.itemtype, aqbudgets.budget_code, aqorders.sort1, and aqorders.sort2. The statement is prepared and executed with no bound parameters. An authenticated staff user holding the reports module permission can inject arbitrary SQL and read any table reachable by the Koha database user, including borrowers (password hashes, two-factor secrets, personal data), borrower_password_recovery, api_keys, and sessions. | ||||
| CVE-2026-71236 | 1 Grocy | 1 Grocy | 2026-08-05 | 8.7 High |
| Grocy's API request-body parser (controllers/Api/BaseApiController.php, GetParsedAndFilteredRequestBody) purifies incoming field values with HTMLPurifier, then manually reverses HTML-entity encoding of the resulting output by replacing &lt;, &gt;, and &amp; back to <, >, and & immediately after purification. This double-decode reconstructs live HTML/script tags from the entity-encoded form that HTMLPurifier produced to neutralize them, re-introducing stored XSS across API-writable fields (products, recipes, stock, users, chores, and others) that are rendered elsewhere without re-sanitization. | ||||
| CVE-2026-71250 | 1 Firefly-iii | 1 Firefly Iii | 2026-08-05 | 4.3 Medium |
| Firefly III's webhook URL validator (IsValidWebhookUrl.php) filters most private/reserved IPv4 ranges but contains an explicit early-return that allows any resolved address in 127.0.0.0/8, permitting an authenticated user (with webhooks enabled, which is off by default) to configure a webhook targeting loopback services on the server. Additionally, the validator resolves the target hostname once via gethostbyname() at validation time, but the actual outbound request (StandardWebhookSender.php, via Guzzle) re-resolves the hostname independently at send time, allowing a DNS-rebinding attacker to pass validation against a public IP and have the real request delivered to a private or internal address. The webhook response body is only written to a server-side debug log, not returned to the triggering user, so this is a blind SSRF primitive rather than one with direct response read-back. | ||||
| CVE-2026-71245 | 1 Mautic | 1 Mautic | 2026-08-05 | 7.1 High |
| Mautic's getLeadIdsByFieldValueAction (LeadBundle/Controller/AjaxController.php) reads a field parameter from the request, sanitizes it only with InputHelper::clean() (which HTML-entity-encodes quotes and angle brackets but does not restrict other characters), and passes it into LeadRepository::buildQueryForGetLeadsByFieldValue() where it is concatenated directly as a raw SQL column identifier ($col = 'l.'.$field) rather than being validated against a whitelist of real column names or passed as a bound parameter. Since Doctrine cannot parameterize identifiers, and the sanitizer does not block spaces, parentheses, or other SQL-relevant characters, an attacker can inject SQL via the field name itself. The action requires only a valid session (any authenticated user), unlike sibling actions in the same controller that carry additional permission checks. | ||||
| CVE-2026-71247 | 1 Documenso | 1 Documenso | 2026-08-05 | 6.5 Medium |
| Documenso's sign-field-with-token.ts, used by the live document-signing UI, allows a recipient with the ASSISTANT role to fetch and complete fields belonging to any later-or-equal-order, not-yet-signed recipient in the same envelope, with no restriction on field type. The handler upserts a Signature record tied to the target field's recipientId with no check that field.type is SIGNATURE and the acting recipient owns it. A newer V2 signing path (sign-envelope-field.ts) explicitly blocks assistants from completing SIGNATURE fields, and the project's own test suite comments confirm this guard is absent from the V1 path used here. In a sequential-signing document, an assistant recipient can therefore forge another signer's signature field. | ||||
| 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-2026-64578 | 1 Linux | 1 Linux Kernel | 2026-08-05 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate compound request size before reading StructureSize2 When ksmbd validates a compound (chained) SMB2 request, ksmbd_smb2_check_message() reads pdu->StructureSize2 without first checking that the compound element is large enough to contain it. StructureSize2 is a 2-byte field at offset 64 (__SMB2_HEADER_STRUCTURE_SIZE) from the start of each element. The compound-walking logic only guarantees that a full 64-byte SMB2 header is present for the trailing element: when NextCommand is 0, len is reduced to the number of bytes remaining after next_smb2_rcv_hdr_off. A remote client can craft a compound request whose last element has exactly 64 bytes, so the 2-byte StructureSize2 read at offset 64 extends one byte past the receive buffer, producing a slab-out-of-bounds read. BUG: KASAN: slab-out-of-bounds in ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) Read of size 2 at addr ffff888012ae31ac by task kworker/0:1/14 The buggy address is located 172 bytes inside of allocated 173-byte region Workqueue: ksmbd-io handle_ksmbd_work Call Trace: ... kasan_report (mm/kasan/report.c:595) ksmbd_smb2_check_message (fs/smb/server/smb2misc.c:402) handle_ksmbd_work (fs/smb/server/server.c:119) process_one_work (kernel/workqueue.c:3314) worker_thread (kernel/workqueue.c:3397) kthread (kernel/kthread.c:436) ret_from_fork (arch/x86/kernel/process.c:158) ret_from_fork_asm (arch/x86/entry/entry_64.S:245) Reject any compound element that is too small to hold StructureSize2 before dereferencing it. | ||||
| 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 ``` | ||||