Export limit exceeded: 351058 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (351058 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-43486 | 1 Linux | 1 Linux Kernel | 2026-05-14 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: arm64: contpte: fix set_access_flags() no-op check for SMMU/ATS faults contpte_ptep_set_access_flags() compared the gathered ptep_get() value against the requested entry to detect no-ops. ptep_get() ORs AF/dirty from all sub-PTEs in the CONT block, so a dirty sibling can make the target appear already-dirty. When the gathered value matches entry, the function returns 0 even though the target sub-PTE still has PTE_RDONLY set in hardware. For a CPU with FEAT_HAFDBS this gathered view is fine, since hardware may set AF/dirty on any sub-PTE and CPU TLB behavior is effectively gathered across the CONT range. But page-table walkers that evaluate each descriptor individually (e.g. a CPU without DBM support, or an SMMU without HTTU, or with HA/HD disabled in CD.TCR) can keep faulting on the unchanged target sub-PTE, causing an infinite fault loop. Gathering can therefore cause false no-ops when only a sibling has been updated: - write faults: target still has PTE_RDONLY (needs PTE_RDONLY cleared) - read faults: target still lacks PTE_AF Fix by checking each sub-PTE against the requested AF/dirty/write state (the same bits consumed by __ptep_set_access_flags()), using raw per-PTE values rather than the gathered ptep_get() view, before returning no-op. Keep using the raw target PTE for the write-bit unfold decision. Per Arm ARM (DDI 0487) D8.7.1 ("The Contiguous bit"), any sub-PTE in a CONT range may become the effective cached translation and software must maintain consistent attributes across the range. | ||||
| CVE-2026-43489 | 1 Linux | 1 Linux Kernel | 2026-05-14 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: liveupdate: luo_file: remember retrieve() status LUO keeps track of successful retrieve attempts on a LUO file. It does so to avoid multiple retrievals of the same file. Multiple retrievals cause problems because once the file is retrieved, the serialized data structures are likely freed and the file is likely in a very different state from what the code expects. The retrieve boolean in struct luo_file keeps track of this, and is passed to the finish callback so it knows what work was already done and what it has left to do. All this works well when retrieve succeeds. When it fails, luo_retrieve_file() returns the error immediately, without ever storing anywhere that a retrieve was attempted or what its error code was. This results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace, but nothing prevents it from trying this again. The retry is problematic for much of the same reasons listed above. The file is likely in a very different state than what the retrieve logic normally expects, and it might even have freed some serialization data structures. Attempting to access them or free them again is going to break things. For example, if memfd managed to restore 8 of its 10 folios, but fails on the 9th, a subsequent retrieve attempt will try to call kho_restore_folio() on the first folio again, and that will fail with a warning since it is an invalid operation. Apart from the retry, finish() also breaks. Since on failure the retrieved bool in luo_file is never touched, the finish() call on session close will tell the file handler that retrieve was never attempted, and it will try to access or free the data structures that might not exist, much in the same way as the retry attempt. There is no sane way of attempting the retrieve again. Remember the error retrieve returned and directly return it on a retry. Also pass this status code to finish() so it can make the right decision on the work it needs to do. This is done by changing the bool to an integer. A value of 0 means retrieve was never attempted, a positive value means it succeeded, and a negative value means it failed and the error code is the value. | ||||
| CVE-2026-46300 | 1 Linux | 1 Kernel | 2026-05-14 | 7.8 High |
| A flaw was found in the Linux kernel's XFRM ESP-in-TCP subsystem. This vulnerability, known as Fragnesia, allows a local attacker to achieve arbitrary byte writes into the kernel page cache of read-only files. | ||||
| CVE-2026-33378 | 1 Grafana | 1 Grafana | 2026-05-14 | 6.5 Medium |
| Using the $__timeGroup macro, one can achieve an OOM by overloading the server. This requires a SQL datasource. If the server is set up to auto-restart, the impact is minimal or non-existent, as the attack can take upwards of half an hour to crash the server. | ||||
| CVE-2026-28374 | 1 Grafana | 1 Grafana | 2026-05-14 | 4.3 Medium |
| Editors could delete any annotation, even those they do not have read access to. The editor user cannot create or read the annotations. | ||||
| CVE-2026-44656 | 1 Vim | 1 Vim | 2026-05-14 | 5.3 Medium |
| Vim is an open source, command line text editor. Prior to version 9.2.0435, an OS command injection vulnerability exists in Vim's :find command-line completion. When the path option contains backtick-enclosed shell commands, those commands are executed during file name completion. Because the path option lacks the P_SECURE flag, it can be set from a modeline, allowing an attacker who controls the contents of a file to execute arbitrary shell commands when the user opens that file in Vim and triggers :find completion. This issue has been patched in version 9.2.0435. | ||||
| CVE-2026-44431 | 2 Python, Urllib3 | 2 Urllib3, Urllib3 | 2026-05-14 | 5.3 Medium |
| urllib3 is an HTTP client library for Python. From 1.23 to before 2.7.0, cross-origin redirects followed from the low-level API via ProxyManager.connection_from_url().urlopen(..., assert_same_host=False) still forward these sensitive headers. This vulnerability is fixed in 2.7.0. | ||||
| CVE-2026-42307 | 1 Vim | 1 Vim | 2026-05-14 | 4.4 Medium |
| Vim is an open source, command line text editor. Prior to version 9.2.0383, an OS command injection vulnerability exists in the netrw standard plugin bundled with Vim. By inducing a user to open a crafted URL (e.g., using the sftp:// or file:// protocol handlers), an attacker can execute arbitrary shell commands with the privileges of the Vim process. This issue has been patched in version 9.2.0383. | ||||
| CVE-2025-32425 | 1 Significant-gravitas | 1 Autogpt | 2026-05-14 | N/A |
| AutoGPT is a platform that allows users to create, deploy, and manage continuous artificial intelligence agents that automate complex workflows. In AutoGPT, the execution process is recorded to the console (stdout/stderr), and deployed in container mode, which is automatically captured by Docker and stored as "container logs". However, prior to 0.6.32, there is no limit on the log size when the container is deployed. When the number of user accesses is too large, the log on the server disk will be too large, causing disk resource exhaustion and eventually causing DoS. autogpt-platform-beta-v0.6.32 fixes the issue. | ||||
| CVE-2026-46445 | 1 Alinto | 1 Sogo | 2026-05-14 | 7.1 High |
| SOGo before 5.12.7, when PostgreSQL is used, allows SQL injection. | ||||
| CVE-2026-42190 | 1 Redwoodjs | 2 Redwoodsdk, Sdk | 2026-05-14 | 5.3 Medium |
| RedwoodSDK is a server-first React framework. From version 1.0.0-beta.50 to before version 1.2.3, server actions in rwsdk apply HTTP method enforcement but no origin validation. A request originating from a different origin that the browser treats as same-site can invoke a server action with the victim's session cookie attached. This issue has been patched in version 1.2.3. | ||||
| CVE-2026-44919 | 1 Openstack | 1 Ironic | 2026-05-14 | 4.3 Medium |
| In OpenStack Ironic through 35.x before a3f6d73, during image handling, an infinite loop in checksum calculations can occur via the file:///dev/zero URL. | ||||
| CVE-2026-43680 | 1 Claris | 1 Filemaker Cloud | 2026-05-14 | 7.2 High |
| A Remote Code Execution vulnerability in Claris FileMaker Cloud allowed a user with Admin Console privileges to bypass a front-end restriction on OS Script schedule types and execute arbitrary operating system commands on the underlying host. This issue is fixed in FileMaker Cloud 2.22.0.5. | ||||
| CVE-2026-43685 | 1 Claris | 1 Filemaker Cloud | 2026-05-14 | 7.2 High |
| A Remote Code Execution vulnerability in Claris FileMaker Cloud allowed a user with Admin Console privileges to inject arbitrary operating system commands through unsanitized input in the External ODBC Data Source connection test feature. This issue is fixed in FileMaker Cloud 2.22.0.5. | ||||
| CVE-2026-46446 | 1 Alinto | 1 Sogo | 2026-05-14 | 7.1 High |
| SOGo before 5.12.7, when PostgreSQL or MariaDB is used, and cleartext passwords are stored, allows SQL injection. This is related to c_password = '%@' in changePasswordForLogin. | ||||
| CVE-2026-44432 | 2 Python, Urllib3 | 2 Urllib3, Urllib3 | 2026-05-14 | 7.5 High |
| urllib3 is an HTTP client library for Python. From 2.6.0 to before 2.7.0, urllib3 could decompress the whole response instead of the requested portion (1) during the second HTTPResponse.read(amt=N) call when the response was decompressed using the official Brotli library or (2) when HTTPResponse.drain_conn() was called after the response had been read and decompressed partially (compression algorithm did not matter here). These issues could cause urllib3 to fully decode a small amount of highly compressed data in a single operation. This could result in excessive resource consumption (high CPU usage and massive memory allocation for the decompressed data) on the client side. This vulnerability is fixed in 2.7.0. | ||||
| CVE-2026-5089 | 1 Toddr | 1 Yaml::syck | 2026-05-14 | 7.3 High |
| YAML::Syck versions before 1.38 for Perl has an out-of-bounds read. The base60 (sexagesimal) parsing code in perl_syck.h has a buffer underflow bug in both int#base60 and float#base60 handlers. When processing the leftmost segment of a colon-separated value (e.g., the 1 in 1:30:45), the inner while loop can decrement a pointer past the start of the string buffer: while ( colon >= ptr && *colon != ':' ) { colon--; } if ( *colon == ':' ) *colon = '\0'; // colon may be ptr-1 here When no colon is found (final/leftmost segment), colon becomes ptr-1, and the subsequent *colon dereference reads one byte before the allocated buffer. | ||||
| CVE-2026-5798 | 1 Stel Order | 1 Stel Order | 2026-05-14 | N/A |
| Unsafe object reference (IDOR) in Stel Order v3.25.1 and earlier versions, specifically in the ‘/app/FrontController’ endpoint, through manipulation of the ‘employeeID’ parameter. An authenticated attacker could exploit this vulnerability to access information about any employee (first names, last names, roles, job titles, and vacation records, among others) by modifying that identifier in requests sent to the server. | ||||
| CVE-2026-5790 | 1 Stel Order | 1 Stel Order | 2026-05-14 | N/A |
| Stored Cross-Site Scripting (XSS) in Stel Order v3.25.1 and earlier, located at the ‘/app/FrontController’ endpoint via the ‘legalName’ and ‘employeeID’ parameters. The lack of proper input sanitization allows an attacker to inject malicious code that is persistently stored in the database. When other users or administrators access the affected sections, the code executes in their browsers, enabling the theft of session cookies and account hijacking. | ||||
| CVE-2025-12008 | 2026-05-14 | 8.8 High | ||
| Authorization bypass through User-Controlled key vulnerability in APPYAP Technology and Information Inc. Yaay Social Media App allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects Yaay Social Media App: from 3.8.0 through 24102025. | ||||