Export limit exceeded: 421918 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (1442 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-90979 | 1 Apache | 1 Karaf | 2026-10-08 | 7.3 High |
| LDAPCache and LDAPBackingEngine build LDAP search filters for user lookup and role lookup by textually substituting the placeholders %u, %dn, and %fqdn (drawn from the login name, the resolved user DN, and its fully qualified namespace form) into administrator-configured filter templates (userFilter, roleFilter). Before the fix, the only sanitization applied to the substituted value was double backslashed: filter = filter.replaceAll(Pattern.quote("%u"), Matcher.quoteReplacement(user)); filter = filter.replace("\\", "\\\\"); This does not escape the other characters RFC 4515 requires escaping in an LDAP search filter: *, (, ), and NUL. A login name containing any of these can change the structure of the resulting filter rather than being matched as a literal value (e.g. a crafted username can turn an equality match into a wildcard match, or close/reopen filter clauses), widening what the search returns and potentially causing a login or role lookup to match an LDAP entry other than the intended one, over-granting roles, and depending on deployment-specific filter templates, potentially affecting which account a login resolved to. It's not exploitable through every entry points: LDAPLoginModule and LDAPPubkeyLoginModule both called Util.doRFC2254Encoding() (correct RFC 4515 escaping) on the login name before handing it to LDAPCache, which masked the missing escaping in LDAPCache for those two call paths. Using LDAPCache directly (bypassing the login modules) does not reproduce through the normal LDAPLoginModule/LDAPPubkeyLoginModule authentication flow for this reason. It does reproduce through two other call paths that reach LDAPCache/LDAPBackingEngine without any prior escaping: * GSSAPILdapLoginModule passes the NameCallback name straight through, unescaped. * LDAPBackingEngine (listRoles) passes principal.getName() straight through, unescaped. | ||||
| CVE-2026-106273 | 1 Google | 1 Chrome | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in Video in Google Chrome prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-106275 | 1 Google | 2 Android, Chrome | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Low) | ||||
| CVE-2026-106258 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in ANGLE in Google Chrome on on Windows prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-98137 | 1 Linux | 1 Linux Kernel | 2026-10-08 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: ntfs: treat any nonzero dio zero-range return as an error ntfs_dio_zero_range() returns either 0 or a negative errno from blkdev_issue_zeroout(); it never returns a positive value. The zeroing failure check in ntfs_attr_fallocate() therefore never fired, so a failed zeroing operation was silently ignored: the loop kept going, the newly allocated clusters were folded into initialized_size and the write could succeed leaving stale on-disk data. Treat any nonzero return as an error and abort the allocation. | ||||
| CVE-2026-106290 | 1 Google | 2 Android, Chrome | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker who had compromised the renderer process to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106395 | 1 Google | 2 Android, Chrome | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in Dawn in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106184 | 1 Google | 1 Chrome | 2026-10-08 | 4.3 Medium |
| Uninitialized resource in Media in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-106202 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in ANGLE in Google Chrome on on Windows prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-106223 | 1 Google | 2 Android, Chrome | 2026-10-08 | 4.7 Medium |
| Uninitialized resource in GPU in Google Chrome on on Android prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: Medium) | ||||
| CVE-2026-106215 | 2 Google, Microsoft | 2 Chrome, Windows | 2026-10-07 | 4.7 Medium |
| Uninitialized resource in ANGLE in Google Chrome on on Windows prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2018-14647 | 6 Canonical, Debian, Fedoraproject and 3 more | 15 Ubuntu Linux, Debian Linux, Fedora and 12 more | 2026-10-07 | 7.5 High |
| Python's elementtree C accelerator failed to initialise Expat's hash salt during initialization. This could make it easy to conduct denial of service attacks against Expat by constructing an XML document that would cause pathological hash collisions in Expat's internal data structures, consuming large amounts CPU and RAM. The vulnerability exists in Python versions 3.7.0, 3.6.0 through 3.6.6, 3.5.0 through 3.5.6, 3.4.0 through 3.4.9, 2.7.0 through 2.7.15. | ||||
| CVE-2026-106231 | 2 Apple, Google | 2 Macos, Chrome | 2026-10-07 | 4.7 Medium |
| Uninitialized resource in Dawn in Google Chrome on on Mac prior to 155.0.8059.39 allowed a remote attacker to read memory outside the sandbox via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2025-5777 | 2 Citrix, Netscaler | 4 Netscaler Application Delivery Controller, Netscaler Gateway, Adc and 1 more | 2026-10-07 | 7.5 High |
| Insufficient input validation leading to memory overread when the NetScaler is configured as a Gateway (VPN virtual server, ICA Proxy, CVPN, RDP Proxy) OR AAA virtual server | ||||
| CVE-2026-106379 | 1 Google | 1 Chrome | 2026-10-07 | 4.3 Medium |
| Uninitialized resource in Skia in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-106245 | 1 Google | 1 Chrome | 2026-10-07 | 4.3 Medium |
| Uninitialized resource in ANGLE in Google Chrome prior to 155.0.8059.39 allowed a remote attacker to obtain cross-origin data via a crafted HTML page. (Chromium security severity: High) | ||||
| CVE-2026-59782 | 1 Zabbix | 1 Zabbix | 2026-10-05 | 4.9 Medium |
| The JavaScript preprocessing (Duktape) engine on Zabbix server has a vulnerability where a limited administrator is able to read raw heap data potentially resulting in leaked data from other running preprocessors not available to said administrator. | ||||
| CVE-2026-92834 | 1 Apache | 1 Thrift | 2026-10-04 | N/A |
| Use of uninitialized resource, Return of wrong status code vulnerability in Apache Thrift C++ WebSocket server. This issue affects Apache Thrift: before 0.25.0. Users are recommended to upgrade to version 0.25.0, which fixes the issue. | ||||
| CVE-2026-98109 | 1 Linux | 1 Linux Kernel | 2026-10-03 | 4.7 Medium |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_core: Fix race condition during device registration In hci_register_dev(), the power_on work item is queued to hdev->req_workqueue before initializing hdev->adv_monitors_idr and registering the MSFT extension via msft_register(). For devices marked with quirks such as HCI_QUIRK_RAW_DEVICE, the HCI_UNCONFIGURED flag is set on the device. When the power_on work item runs concurrently on another CPU, hci_power_on() detects that the device is unconfigured and immediately invokes hci_dev_do_close(), which calls msft_do_close(). Concurrently, msft_register() allocates the msft structure and exposes it to hdev->msft_data prior to calling mutex_init(&msft->filter_lock). If msft_do_close() executes while hdev->msft_data is already assigned but the mutex has not yet been initialized, mutex_lock(&msft->filter_lock) operates on an uninitialized mutex, triggering a DEBUG_LOCKS warning: DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: kernel/locking/mutex.c:625 at __mutex_lock_common kernel/locking/mutex.c:625 [inline] WARNING: kernel/locking/mutex.c:625 at __mutex_lock+0x12d8/0x1550 kernel/locking/mutex.c:821 ... Call Trace: <TASK> msft_do_close+0x308/0x7b0 net/bluetooth/msft.c:693 hci_dev_close_sync+0x86b/0x10a0 net/bluetooth/hci_sync.c:5522 hci_dev_do_close net/bluetooth/hci_core.c:499 [inline] hci_power_on+0x32c/0x750 net/bluetooth/hci_core.c:937 process_one_work kernel/workqueue.c:3322 [inline] process_scheduled_works+0xa8e/0x14e0 kernel/workqueue.c:3405 worker_thread+0x92d/0xe10 kernel/workqueue.c:3486 kthread+0x388/0x470 kernel/kthread.c:436 ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245 </TASK> Fix this by moving the queue_work() call in hci_register_dev() to after idr_init(&hdev->adv_monitors_idr) and msft_register(hdev) so that device structures and extensions are fully initialized before asynchronous tasks can access them. Additionally, assign hdev->msft_data in msft_register() only after mutex_init(&msft->filter_lock) has completed. | ||||
| CVE-2026-97963 | 1 Linux | 1 Linux Kernel | 2026-10-03 | 5.5 Medium |
| In the Linux kernel, the following vulnerability has been resolved: net: stmmac: initialize ptp_lock at probe time priv->ptp_lock is only initialized in stmmac_ptp_register(), which runs during __stmmac_open(). However, the lock is also used while the interface is down and has never been opened: tc_taprio_configure() invokes the PTP gettime64() callback to compute the EST base time when offloading a TAPRIO schedule, and stmmac_get_time() takes priv->ptp_lock. Using an uninitialized rwlock is undefined behaviour. Move the rwlock_init() to __stmmac_dvr_probe(), together with the other private locks, so that ptp_lock is always valid regardless of the interface state. | ||||