Export limit exceeded: 361690 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (361690 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-56150 | 1 Elastic | 1 Fleet Server | 2026-07-01 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Fleet Server can lead to a denial of service via Excessive Allocation (CAPEC-130). An attacker can submit a specially crafted request to an upload endpoint that causes excessive memory consumption, which may render Fleet Server unavailable. | ||||
| CVE-2026-56151 | 1 Elastic | 1 Kibana | 2026-07-01 | 6.5 Medium |
| Improper Input Validation (CWE-20) in Kibana can lead to a denial of service via Input Data Manipulation (CAPEC-153). An authenticated user can submit a specially crafted Fleet policy input that is not correctly validated, which can render Fleet agent, server, and policy management functionality unavailable. | ||||
| CVE-2026-49087 | 1 Elastic | 1 Kibana | 2026-07-01 | 6.5 Medium |
| Allocation of Resources Without Limits or Throttling (CWE-770) in Kibana can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted bulk deletion request that causes excessive resource consumption, which may render Kibana unavailable. | ||||
| CVE-2026-49088 | 1 Elastic | 1 Kibana | 2026-07-01 | 4.4 Medium |
| Insertion of Sensitive Information into Log File (CWE-532) in Kibana can lead to information disclosure. When the optional application performance monitoring (APM) instrumentation is enabled, sensitive request header values could be recorded in application logs, where they may be accessible to operators with log access. | ||||
| CVE-2026-49090 | 1 Elastic | 1 Elasticsearch | 2026-07-01 | 6.5 Medium |
| Uncontrolled Resource Consumption (CWE-400) in Elasticsearch can lead to a denial of service via Excessive Allocation (CAPEC-130). An authenticated user can submit a specially crafted bulk request that causes sustained high CPU consumption, which can render the affected node unable to process requests. | ||||
| CVE-2026-49091 | 1 Elastic | 1 Kibana | 2026-07-01 | 8 High |
| Improper Output Neutralization for Logs (CWE-117) in Kibana can lead to log injection via Log Injection-Tampering-Forging (CAPEC-93). An attacker can supply specially crafted input that is written to log files without proper neutralization. When the log files are subsequently viewed in a terminal that interprets control sequences, the injected content may alter the displayed log data. | ||||
| CVE-2026-57736 | 2 Hubspot, Wordpress | 2 Hubspot, Wordpress | 2026-07-01 | 7.4 High |
| Insertion of Sensitive Information Into Sent Data vulnerability in HubSpot allows Retrieve Embedded Sensitive Data. This issue affects HubSpot: from n/a through 11.3.51. | ||||
| CVE-2026-50283 | 2026-07-01 | N/A | ||
| Craft CMS is a content management system (CMS). Versions 5.0.0-RC1 through 5.9.20, and 4.0.0-RC1 through 4.17.13 contain an authorization issue in the AssetsController::actionReplaceFile that can delete a source asset without source delete permission by supplying both assetId and sourceAssetId. AssetsController::actionReplaceFile() supports replacing a target asset file using another existing asset as the source. The action loads: assetId -> $assetToReplace and sourceAssetId -> $sourceAsset, then enforces replace permissions using ($assetToReplace ?: $sourceAsset). When both IDs are provided, this expression resolves to the target asset so no permission check is performed against the source asset volume. When both assets are present, Craft copies the source file into the target and then deletes the source asset. There is no deletion check for for the source asset. An authenticated user who can replace files in one volume can delete assets in another volume where they do not have delete permission, as long as they can obtain a sourceAssetId, leading to broken content references and data loss. This issue has been fixed in versions 4.17.14 and 5.9.21. | ||||
| CVE-2026-14042 | 1 Google | 1 Chrome | 2026-07-01 | 4.3 Medium |
| Inappropriate implementation in Isolated Web Apps in Google Chrome prior to 150.0.7871.47 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-56016 | 2026-07-01 | 5.9 Medium | ||
| CGI::Session::ID::md5 versions before 4.49 for Perl generate predictable session ids from low-entropy sources. The generate_id method builds the session id from a MD5 digest of the process id, the epoch time, and the built-in rand() function. All three are predictable, low-entropy sources: the PID is drawn from a small range, the epoch time can be guessed or read from the HTTP Date header, and Perl's rand() is unsuitable for security purposes because it is predictable and reversible. An attacker who predicts a session id can impersonate the corresponding session and bypass authentication. | ||||
| CVE-2026-53330 | 1 Linux | 1 Linux Kernel | 2026-07-01 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bounds read in dp_get_eq_aux_rd_interval() [Why & How] The aux_rd_interval array in struct dc_lttpr_caps is declared with MAX_REPEATER_CNT - 1 (7) elements, indexed 0..6. However, the offset parameter passed to dp_get_eq_aux_rd_interval() can be as large as MAX_REPEATER_CNT (8) when a sink reports 8 LTTPR repeaters via DPCD. This leads to an out-of-bounds read of aux_rd_interval[7] when offset is 8. Fix this by growing aux_rd_interval to MAX_REPEATER_CNT elements to accommodate the full range of valid repeater counts defined by the DP spec. (cherry picked from commit a55a458a8df37a65ffda5cf721d554a8f74f6b04) | ||||
| CVE-2026-53337 | 1 Linux | 1 Linux Kernel | 2026-07-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: bonding: fix NULL pointer dereference in bond_do_ioctl() In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which can return NULL if the requested interface name does not exist. However, the subsequent slave_dbg() call is placed before the NULL check: slave_dev = __dev_get_by_name(net, ifr->ifr_slave); slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here if (!slave_dev) return -ENODEV; The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt, (slave_dev)->name, ...) which unconditionally dereferences slave_dev->name before the NULL check is performed. This results in a NULL pointer dereference kernel oops when a user calls bonding ioctl (e.g. SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave interface name. This is reachable from userspace via the bonding ioctl interface with CAP_NET_ADMIN capability, making it a potential local denial-of-service vector. Fix by moving the slave_dbg() call after the NULL check. | ||||
| CVE-2026-53339 | 1 Linux | 1 Linux Kernel | 2026-07-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: i2c: qcom-cci: Fix NULL pointer dereference in cci_remove() On all modern platforms Qualcomm CCI controller provides two I2C masters, and on particular boards only one I2C master may be initialized, and in such cases the device unbinding or driver removal causes a NULL pointer dereference, because cci_halt() is called for all two I2C masters, but a completion is initialized only for the single enabled master: % rmmod i2c-qcom-cci Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 <snip> Call trace: __wait_for_common+0x194/0x1a8 (P) wait_for_completion_timeout+0x20/0x2c cci_remove+0xc4/0x138 [i2c_qcom_cci] platform_remove+0x20/0x30 device_remove+0x4c/0x80 device_release_driver_internal+0x1c8/0x224 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 platform_driver_unregister+0x14/0x20 qcom_cci_driver_exit+0x18/0x1008 [i2c_qcom_cci] .... | ||||
| CVE-2026-53348 | 1 Linux | 1 Linux Kernel | 2026-07-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: SDCA: fix NULL pointer dereference in sdca_dev_unregister_functions sdca_dev_unregister_functions() iterates over all SDCA function descriptors and calls sdca_dev_unregister() on each func_dev without checking for NULL. When a function registration has failed partway through, or the device cleanup races with probe deferral, func_dev entries may be NULL, leading to a kernel oops: BUG: kernel NULL pointer dereference, address: 0000000000000040 RIP: 0010:device_del+0x1e/0x3e0 Call Trace: sdca_dev_unregister_functions+0x37/0x60 [snd_soc_sdca] release_nodes+0x35/0xb0 devres_release_all+0x90/0x100 device_unbind_cleanup+0xe/0x80 device_release_driver_internal+0x1c1/0x200 bus_remove_device+0xc6/0x130 device_del+0x161/0x3e0 device_unregister+0x17/0x60 sdw_delete_slave+0xb6/0xd0 [soundwire_bus] sdw_bus_master_delete+0x1e/0x50 [soundwire_bus] ... sof_probe_work+0x19/0x30 [snd_sof] This was observed on a Lenovo ThinkPad X1 Carbon G14 (Panther Lake) with the SOF audio driver probe failing due to missing Panther Lake firmware, causing the subsequent cleanup of SoundWire devices to trigger the crash. Fix this with three changes: 1) Add a NULL guard in sdca_dev_unregister() so that callers do not need to pre-validate the pointer (defense in depth). 2) In sdca_dev_unregister_functions(), skip NULL func_dev entries and clear func_dev to NULL after unregistration, making the function idempotent and safe against double-invocation. 3) In sdca_dev_register_functions(), roll back all previously registered functions when a later one fails, so the function array is never left in a partially-populated state. | ||||
| CVE-2026-53350 | 1 Linux | 1 Linux Kernel | 2026-07-01 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ASoC: wm_adsp: Fix NULL dereference when removing firmware controls In wm_adsp_control_remove() check that the priv pointer is not NULL before attempting to cleanup what it points to. When cs_dsp creates a control it calls wm_adsp_control_add_cb() so that wm_adsp can create its own private control data. There are two cases where private data is not created: 1. The control is a SYSTEM control, so an ALSA control is not created. 2. The codec driver has registered a control_add() callback that hides the control, so wm_adsp_control_add() is not called. When cs_dsp_remove destroys its control list it calls wm_adsp_control_remove() for each control. But wm_adsp_control_remove() was attempting to cleanup the private data pointed to by cs_ctl->priv without checking the pointer for NULL. | ||||
| CVE-2026-53356 | 1 Linux | 1 Linux Kernel | 2026-07-01 | N/A |
| In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix phys BO pread/pwrite with offset sg_page() returns struct page pointer not (void *) so the scaling of pread/pwrite is wrong for phys BO and wrong parts of BO would be accessed if non-zero offset is used. Last impacted platform with overlay or cursor planes using phys mapping was Gen3/945G/Lakeport. (cherry picked from commit 3e49a2f85070b2fb672c1e0fdba281a4ea3aebe6) | ||||
| CVE-2026-55661 | 2026-07-01 | N/A | ||
| Tina is a headless content management system. In versions prior to @tinacms/mdx 2.1.7 and tinacms 3.9.3, rich-text parsing and the default link/image renderers did not sanitize the url field on Slate link/image nodes. Content containing javascript: or data:text/html URLs — including case-variant, whitespace-padded, and control-character-obfuscated forms — is rendered into href/src and executes when the content is viewed. Any actor able to author rich-text content (for example a lower-privileged editor, or imported/external content) can achieve stored XSS against editors and site viewers. This issue is fixed in versions @tinacms/mdx 2.1.7 and tinacms 3.9.3. | ||||
| CVE-2026-58263 | 2026-07-01 | 7.2 High | ||
| Jodit Editor is a WYSIWYG editor with written in pure TypeScript file and image editing capabilities. In versions prior to 4.12.28, the built-in clean-html sanitizer can be bypassed by a MathML/<style> carrier that hides a dangerous element from the sanitizer's element walk, so a no-interaction event handler survives into the editor value, potentially causing Mutation XSS. When an application supplies attacker-influenced HTML to the editor's value-set or insertion paths, the sanitized output still contains a live <img ... onload=...> (or another non-onerror handler such as onfocus). A consumer that renders that output (element.innerHTML = editor.value) executes the handler with no user interaction. This issue has been fixed in version 4.12.28. | ||||
| CVE-2026-54756 | 2026-07-01 | N/A | ||
| Jodit Editor is a WYSIWYG editor with written in pure TypeScript file and image editing capabilities. In versions prior to 4.12.18, Jodit.configure(options) — and the internal ConfigMerge / ConfigProto helpers — merged user-supplied options into the editor configuration without filtering prototype-mutating keys, potentially causing a Prototype Pollution vulnerability. A payload nested under an existing plain-object option such as controls could reach and mutate Object.prototype. Applications that pass user-controlled or partially user-controlled configuration into Jodit.configure() may be vulnerable. This issue was fixed in version 4.12.18. | ||||
| CVE-2026-55886 | 2026-07-01 | N/A | ||
| Jodit Editor is a WYSIWYG editor with written in pure TypeScript file and image editing capabilities. Versions prior to 4.12.26 are vulnerable to Prototype Pollution through Jodit.modules.Helpers.set(chain, value, obj), which walks the dot-separated chain, creating and following each path segment without filtering prototype-mutating keys. A chain that begins with (or contains) __proto__, constructor, or prototype lets the final assignment reach and mutate Object.prototype. Applications that pass a user-controlled or partially user-controlled key path into Jodit.modules.Helpers.set() could be vulnerable, causing unexpected property injection, logic bypass, denial of service, or secondary security issues. This issue has been fixed in version 4.12.26. | ||||