Export limit exceeded: 10276 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (10276 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-26004 | 1 Getsentry | 1 Sentry | 2026-03-18 | N/A |
| Sentry is a developer-first error tracking and performance monitoring tool. Versions prior to 26.1.0 have a cross-organization Insecure Direct Object Reference (IDOR) vulnerability in Sentry's GroupEventJsonView endpoint. Version 26.1.0 patches the issue. | ||||
| CVE-2026-31832 | 1 Umbraco | 2 Cms, Umbraco Cms | 2026-03-18 | 5.4 Medium |
| Umbraco is an ASP.NET CMS. From 14.0.0 to before 16.5.1 and 17.2.2, A broken object-level authorization vulnerability exists in a backoffice API endpoint that allows authenticated users to assign domain-related data to content nodes without proper authorization checks. The issue is caused by insufficient authorization enforcement on the affected API endpoint, whereby via an API call, domains can be set on content nodes that the editor does not have permission to access (either via user group privileges or start nodes). This vulnerability is fixed in 16.5.1 and 17.2.2. | ||||
| CVE-2026-28500 | 2 Linuxfoundation, Onnx | 2 Onnx, Onnx | 2026-03-18 | 8.6 High |
| Open Neural Network Exchange (ONNX) is an open standard for machine learning interoperability. In versions up to and including 1.20.1, a security control bypass exists in onnx.hub.load() due to improper logic in the repository trust verification mechanism. While the function is designed to warn users when loading models from non-official sources, the use of the silent=True parameter completely suppresses all security warnings and confirmation prompts. This vulnerability transforms a standard model-loading function into a vector for Zero-Interaction Supply-Chain Attacks. When chained with file-system vulnerabilities, an attacker can silently exfiltrate sensitive files (SSH keys, cloud credentials) from the victim's machine the moment the model is loaded. As of time of publication, no known patched versions are available. | ||||
| CVE-2026-30791 | 6 Apple, Google, Linux and 3 more | 7 Iphone Os, Macos, Android and 4 more | 2026-03-18 | 7.5 High |
| Use of a Broken or Risky Cryptographic Algorithm vulnerability in rustdesk-client RustDesk Client rustdesk-client on Windows, MacOS, Linux, iOS, Android, WebClient (Config import, URI scheme handler, CLI --config modules) allows Retrieve Embedded Sensitive Data. This vulnerability is associated with program files flutter/lib/common.Dart, hbb_common/src/config.Rs and program routines parseRustdeskUri(), importConfig(). This issue affects RustDesk Client: through 1.4.5. | ||||
| CVE-2026-30884 | 1 Mdjnelson | 1 Moodle-mod Customcert | 2026-03-18 | 9.6 Critical |
| mdjnelson/moodle-mod_customcert is a Moodle plugin for creating dynamically generated certificates with complete customization via the web browser. Prior to versions 4.4.9 and 5.0.3, a teacher who holds `mod/customcert:manage` in any single course can read and silently overwrite certificate elements belonging to any other course in the Moodle installation. The `core_get_fragment` callback `editelement` and the `mod_customcert_save_element` web service both fail to verify that the supplied `elementid` belongs to the authorized context, enabling cross-course information disclosure and data tampering. Versions 4.4.9 and 5.0.3 fix the issue. | ||||
| CVE-2026-3419 | 1 Fastify | 1 Fastify | 2026-03-18 | 5.3 Medium |
| Fastify incorrectly accepts malformed `Content-Type` headers containing trailing characters after the subtype token, in violation of RFC 9110 §8.3.1(https://httpwg.org/specs/rfc9110.html#field.content-type). For example, a request sent with Content-Type: application/json garbage passes validation and is processed normally, rather than being rejected with 415 Unsupported Media Type. When regex-based content-type parsers are in use (a documented Fastify feature), the malformed value is matched against registered parsers using the full string including the trailing garbage. This means a request with an invalid content-type may be routed to and processed by a parser it should never have reached. Impact: An attacker can send requests with RFC-invalid Content-Type headers that bypass validity checks, reach content-type parser matching, and be processed by the server. Requests that should be rejected at the validation stage are instead handled as if the content-type were valid. Workarounds: Deploy a WAF rule to protect against this Fix: The fix is available starting with v5.8.1. | ||||
| CVE-2026-23217 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: riscv: trace: fix snapshot deadlock with sbi ecall If sbi_ecall.c's functions are traceable, echo "__sbi_ecall:snapshot" > /sys/kernel/tracing/set_ftrace_filter may get the kernel into a deadlock. (Functions in sbi_ecall.c are excluded from tracing if CONFIG_RISCV_ALTERNATIVE_EARLY is set.) __sbi_ecall triggers a snapshot of the ringbuffer. The snapshot code raises an IPI interrupt, which results in another call to __sbi_ecall and another snapshot... All it takes to get into this endless loop is one initial __sbi_ecall. On RISC-V systems without SSTC extension, the clock events in timer-riscv.c issue periodic sbi ecalls, making the problem easy to trigger. Always exclude the sbi_ecall.c functions from tracing to fix the potential deadlock. sbi ecalls can easiliy be logged via trace events, excluding ecall functions from function tracing is not a big limitation. | ||||
| CVE-2026-22186 | 1 Openmicroscopy | 1 Bio-formats | 2026-03-18 | 7.1 High |
| Bio-Formats versions up to and including 8.3.0 contain an XML External Entity (XXE) vulnerability in the Leica Microsystems metadata parsing component (e.g., XLEF). The parser uses an insecurely configured DocumentBuilderFactory when processing Leica XML-based metadata files, allowing external entity expansion and external DTD loading. A crafted metadata file can trigger outbound network requests (SSRF), access local system resources where readable, or cause a denial of service during XML parsing. | ||||
| CVE-2026-30933 | 2 Filebrowser, Gtsteffaniak | 2 Filebrowser, Filebrowser | 2026-03-18 | 7.5 High |
| FileBrowser Quantum is a free, self-hosted, web-based file manager. Prior to 1.3.1-beta and 1.2.2-stable, the remediation for CVE-2026-27611 is incomplete. Password protected shares still disclose tokenized downloadURL via /public/api/share/info. This vulnerability is fixed in 1.3.1-beta and 1.2.2-stable. | ||||
| CVE-2026-31899 | 2 Courtbouillon, Kozea | 2 Cairosvg, Cairosvg | 2026-03-18 | 7.5 High |
| CairoSVG is an SVG converter based on Cairo, a 2D graphics library. Prior to Kozea/CairoSVG has exponential denial of service via recursive <use> element amplification in cairosvg/defs.py. This causes CPU exhaustion from a small input. | ||||
| CVE-2025-68467 | 1 Darkreader | 1 Darkreader | 2026-03-18 | 3.4 Low |
| Dark Reader is an accessibility browser extension that makes web pages colors dark. The dynamic dark mode feature of the extension works by analyzing the colors of web pages found in CSS style sheet files. In order to analyze cross-origin style sheets (stored on websites different from the original web page), Dark Reader requests such files via a background worker, ensuring the request is performed with no credentials and that the content type of the response is a CSS file. Prior to Dark Reader 4.9.117, this style content was assigned to an HTML Style Element in order to parse and loop through style declarations, and also stored in page's Session Storage for performance gains. This could allow a website author to request a style sheet from a locally running web server, for example by having a link pointing to `http[:]//localhost[:]8080/style[.]css`. The brute force of the host name, port and file name would be unlikely due to performance impact, that would cause the browser tab to hang shortly, but it could be possible to request a style sheet if the full URL was known in advance. As per December 18, 2025 there is no known exploit of the issue. The problem has been fixed in version 4.9.117 on December 3, 2025. The style sheets are now parsed using modern Constructed Style Sheets API and the contents of cross-origin style sheets is no longer stored in page's Session Storage. Version 4.9.118 (December 8, 2025) restricts cross-origin requests to localhost aliases, IP addresses, hosts with ports and non-HTTPS resources. The absolute majority of users have received an update 4.1.117 or 4.9.118 automatically within a week. However users must ensure their automatic updates are not blocked and they are using the latest version of the extension by going to chrome://extensions or about:addons pages in browser settings. Users utilizing manual builds must upgrade to version 4.9.118 and above. Developers using `darkreader` NPM package for their own websites are likely not affected, but must ensure the function passed to `setFetchMethod()` for performing cross-origin requests works within the intended scope. Developers using custom forks of earlier versions of Dark Reader to build other extensions or integrating into their apps or browsers must ensure they perform cross-origin requests safely and the responses are not accessible outside of the app or extension. | ||||
| CVE-2026-23186 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify() The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal. Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective. The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them. In addition, notice that hwmon_device_register_with_info() may fail in which case resource->hwmon_dev will become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case to acpi_power_meter_notify() and acpi_power_meter_remove(). | ||||
| CVE-2026-23165 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: sfc: fix deadlock in RSS config read Since cited commit, core locks the net_device's rss_lock when handling ethtool -x command, so driver's implementation should not lock it again. Remove the latter. | ||||
| CVE-2026-23157 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: btrfs: do not strictly require dirty metadata threshold for metadata writepages [BUG] There is an internal report that over 1000 processes are waiting at the io_schedule_timeout() of balance_dirty_pages(), causing a system hang and trigger a kernel coredump. The kernel is v6.4 kernel based, but the root problem still applies to any upstream kernel before v6.18. [CAUSE] From Jan Kara for his wisdom on the dirty page balance behavior first. This cgroup dirty limit was what was actually playing the role here because the cgroup had only a small amount of memory and so the dirty limit for it was something like 16MB. Dirty throttling is responsible for enforcing that nobody can dirty (significantly) more dirty memory than there's dirty limit. Thus when a task is dirtying pages it periodically enters into balance_dirty_pages() and we let it sleep there to slow down the dirtying. When the system is over dirty limit already (either globally or within a cgroup of the running task), we will not let the task exit from balance_dirty_pages() until the number of dirty pages drops below the limit. So in this particular case, as I already mentioned, there was a cgroup with relatively small amount of memory and as a result with dirty limit set at 16MB. A task from that cgroup has dirtied about 28MB worth of pages in btrfs btree inode and these were practically the only dirty pages in that cgroup. So that means the only way to reduce the dirty pages of that cgroup is to writeback the dirty pages of btrfs btree inode, and only after that those processes can exit balance_dirty_pages(). Now back to the btrfs part, btree_writepages() is responsible for writing back dirty btree inode pages. The problem here is, there is a btrfs internal threshold that if the btree inode's dirty bytes are below the 32M threshold, it will not do any writeback. This behavior is to batch as much metadata as possible so we won't write back those tree blocks and then later re-COW them again for another modification. This internal 32MiB is higher than the existing dirty page size (28MiB), meaning no writeback will happen, causing a deadlock between btrfs and cgroup: - Btrfs doesn't want to write back btree inode until more dirty pages - Cgroup/MM doesn't want more dirty pages for btrfs btree inode Thus any process touching that btree inode is put into sleep until the number of dirty pages is reduced. Thanks Jan Kara a lot for the analysis of the root cause. [ENHANCEMENT] Since kernel commit b55102826d7d ("btrfs: set AS_KERNEL_FILE on the btree_inode"), btrfs btree inode pages will only be charged to the root cgroup which should have a much larger limit than btrfs' 32MiB threshold. So it should not affect newer kernels. But for all current LTS kernels, they are all affected by this problem, and backporting the whole AS_KERNEL_FILE may not be a good idea. Even for newer kernels I still think it's a good idea to get rid of the internal threshold at btree_writepages(), since for most cases cgroup/MM has a better view of full system memory usage than btrfs' fixed threshold. For internal callers using btrfs_btree_balance_dirty() since that function is already doing internal threshold check, we don't need to bother them. But for external callers of btree_writepages(), just respect their requests and write back whatever they want, ignoring the internal btrfs threshold to avoid such deadlock on btree inode dirty page balancing. | ||||
| CVE-2026-1629 | 1 Mattermost | 2 Mattermost, Mattermost Server | 2026-03-18 | 4.3 Medium |
| Mattermost versions 10.11.x <= 10.11.10 Fail to invalidate cached permalink preview data when a user loses channel access which allows the user to continue viewing private channel content via previously cached permalink previews until cache reset or relogin.. Mattermost Advisory ID: MMSA-2026-00580 | ||||
| CVE-2026-23111 | 1 Linux | 1 Linux Kernel | 2026-03-18 | 7.8 High |
| In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix inverted genmask check in nft_map_catchall_activate() nft_map_catchall_activate() has an inverted element activity check compared to its non-catchall counterpart nft_mapelem_activate() and compared to what is logically required. nft_map_catchall_activate() is called from the abort path to re-activate catchall map elements that were deactivated during a failed transaction. It should skip elements that are already active (they don't need re-activation) and process elements that are inactive (they need to be restored). Instead, the current code does the opposite: it skips inactive elements and processes active ones. Compare the non-catchall activate callback, which is correct: nft_mapelem_activate(): if (nft_set_elem_active(ext, iter->genmask)) return 0; /* skip active, process inactive */ With the buggy catchall version: nft_map_catchall_activate(): if (!nft_set_elem_active(ext, genmask)) continue; /* skip inactive, process active */ The consequence is that when a DELSET operation is aborted, nft_setelem_data_activate() is never called for the catchall element. For NFT_GOTO verdict elements, this means nft_data_hold() is never called to restore the chain->use reference count. Each abort cycle permanently decrements chain->use. Once chain->use reaches zero, DELCHAIN succeeds and frees the chain while catchall verdict elements still reference it, resulting in a use-after-free. This is exploitable for local privilege escalation from an unprivileged user via user namespaces + nftables on distributions that enable CONFIG_USER_NS and CONFIG_NF_TABLES. Fix by removing the negation so the check matches nft_mapelem_activate(): skip active elements, process inactive ones. | ||||
| CVE-2026-4208 | 1 Typo3 | 1 Extension "e-mail Mfa Provider" | 2026-03-18 | N/A |
| The extension fails to properly reset the generated MFA code after successful authentication. This leads to a possible MFA bypass for future login attempts by providing an empty string as MFA code to the extensions MFA provider. | ||||
| CVE-2026-28779 | 1 Apache | 1 Airflow | 2026-03-18 | 7.5 High |
| Apache Airflow versions 3.1.0 through 3.1.7 session token (_token) in cookies is set to path=/ regardless of the configured [webserver] base_url or [api] base_url. This allows any application co-hosted under the same domain to capture valid Airflow session tokens from HTTP request headers, allowing full session takeover without attacking Airflow itself. Users are recommended to upgrade to Apache Airflow 3.1.8 or later, which resolves this issue. | ||||
| CVE-2026-23232 | 1 Linux | 1 Linux Kernel | 2026-03-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Revert "f2fs: block cache/dio write during f2fs_enable_checkpoint()" This reverts commit 196c81fdd438f7ac429d5639090a9816abb9760a. Original patch may cause below deadlock, revert it. write remount - write_begin - lock_page --- lock A - prepare_write_begin - f2fs_map_lock - f2fs_enable_checkpoint - down_write(cp_enable_rwsem) --- lock B - sync_inode_sb - writepages - lock_page --- lock A - down_read(cp_enable_rwsem) --- lock A | ||||
| CVE-2026-23130 | 1 Linux | 1 Linux Kernel | 2026-03-17 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix dead lock while flushing management frames Commit [1] converted the management transmission work item into a wiphy work. Since a wiphy work can only run under wiphy lock protection, a race condition happens in below scenario: 1. a management frame is queued for transmission. 2. ath12k_mac_op_flush() gets called to flush pending frames associated with the hardware (i.e, vif being NULL). Then in ath12k_mac_flush() the process waits for the transmission done. 3. Since wiphy lock has been taken by the flush process, the transmission work item has no chance to run, hence the dead lock. >From user view, this dead lock results in below issue: wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticate with xxxxxx (local address=xxxxxx) wlp8s0: send auth to xxxxxx (try 1/3) wlp8s0: authenticated wlp8s0: associate with xxxxxx (try 1/3) wlp8s0: aborting association with xxxxxx by local choice (Reason: 3=DEAUTH_LEAVING) ath12k_pci 0000:08:00.0: failed to flush mgmt transmit queue, mgmt pkts pending 1 The dead lock can be avoided by invoking wiphy_work_flush() to proactively run the queued work item. Note actually it is already present in ath12k_mac_op_flush(), however it does not protect the case where vif being NULL. Hence move it ahead to cover this case as well. Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c5-00302-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.115823.3 | ||||