Export limit exceeded: 403520 CVEs match your query. Please refine your search to export 10,000 CVEs or fewer.
Search
Search Results (403520 CVEs found)
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2026-107577 | 1 Progressive Robot | 1 Hmailserver | 2026-10-09 | 7.5 High |
| Inefficient algorithmic complexity and a non-terminating loop in the MIME processing of received messages in Progressive Robot hMailServer 6.0.0 through 6.3.5 allow a remote unauthenticated attacker to make the mail services unavailable by sending a message. Removing a MIME header parameter whose value is empty and directly followed by a semicolon (for example a Content-Disposition with 'filename=a.bat; filename=;') entered a loop that never terminates, holding a worker thread at full load until the server is restarted; this is reached when the attachment blocker renames a blocked attachment or a filename is set over the REST API. Separately, decoding a header field that holds many RFC 2047 encoded words of an encoding other than base64 or quoted-printable, removing a parameter with many RFC 2231 continuations, and deleting many header fields of one name each took time growing with the square of the message, on the small thread pools that serve IMAP, SMTP and POP3 connections, delivery and the REST API. | ||||
| CVE-2026-107587 | 1 Progressive Robot | 1 Hmailserver | 2026-10-09 | 5.9 Medium |
| Improper certificate validation in the webmail of Progressive Robot hMailServer 6.3.2 through 6.3.5 allows a remote unauthenticated attacker to have S/MIME-encrypted mail that the account later sends to another correspondent also encrypted to the attacker's key. When its recipient opened a signed message, the webmail kept the signer's certificate for encrypting replies whether or not the server found its chain trusted, under the first e-mail address the certificate listed rather than the message's From address, and beside any certificate already held for that address. Encrypted mail later sent from the webmail to that address was encrypted to every certificate held for it, so a holder of the kept certificate's key who obtains a copy of such a message can read it. | ||||
| CVE-2026-87108 | 1 Mongodb | 1 Ops Manager | 2026-10-09 | 3.1 Low |
| An authenticated Ops Manager user with a read-only project role can retrieve a daily host monitoring record associated with a different project when they possess the required record identifier. Insufficient ownership validation can expose deployment metadata, including host and configuration details. | ||||
| CVE-2026-107914 | 1 Backdropcms | 1 Backdrop | 2026-10-09 | 7.8 High |
| Backdrop CMS 1.34 before 1.34.5 and 1.35 before 1.35.1 doesn't sufficiently protect configuration exports when delivering a compressed archive. This vulnerability is mitigated by the fact that an export must have been previously requested by someone with the "Synchronize, import, and export configuration" permission. NOTE: CVE-2026-107914 refers to the vulnerability in which config.admin.inc does not ensure that a file_unmanaged_delete operation occurs. Therefore, many archives could persist: config.tar.gz, config_0.tar.gz, config_1.tar.gz, etc. There is a separate config.module issue that could allow remote access by an anonymous user, but only for the one filename config.tar.gz. | ||||
| CVE-2026-19575 | 2026-10-09 | 7.8 High | ||
| The user-mode verification handler for the device_deinit() system call, z_vrfy_device_deinit() in kernel/device.c, validated its dev argument with K_SYSCALL_OBJ_INIT(dev, K_OBJ_ANY). k_object_validate() short-circuits its type comparison when the requested type is K_OBJ_ANY, so the check reduced to "this pointer is the base address of some kernel object the calling thread has been granted" — the object's actual type was never compared, and K_SYSCALL_OBJ_INIT also skips the initialization-state check. The sibling handlers z_vrfy_device_init() and z_vrfy_device_is_ready() already used K_OBJ_DRIVER_ANY and were unaffected. A thread running in user mode can therefore pass any kernel object it holds permission on — most usefully a thread stack object obtained from the k_thread_stack_alloc() syscall or a statically defined K_THREAD_STACK it was granted in order to spawn a child user thread — whose backing memory is writable from user mode. z_impl_device_deinit() then interprets those attacker-written bytes as a struct device: it dereferences the state pointer read out of the object, calls the function pointer read out of ops.deinit, and on success writes through state again. The result is an indirect call to an arbitrary address executed in supervisor mode, plus an arbitrary kernel read and a single-byte kernel write. Exploitation gives a local unprivileged thread full kernel code execution, defeating the CONFIG_USERSPACE isolation boundary entirely; a less precise attempt yields a supervisor-mode fault and a system crash. The defect is only reachable in builds that enable both CONFIG_USERSPACE and CONFIG_DEVICE_DEINIT_SUPPORT — with de-initialization support disabled, z_impl_device_deinit() returns -ENOTSUP without ever dereferencing the pointer. In v4.2.x and v4.3.x, CONFIG_DEVICE_DEINIT_SUPPORT defaulted to y, so every CONFIG_USERSPACE build of those releases is exposed unless the option was explicitly turned off. From v4.4.0 the option is opt-in (no default, and not selected by any in-tree subsystem), so a v4.4.x build is exposed only if it enables the option explicitly. The v4.2 line is no longer maintained and receives no backport. The fix changes the object check to K_OBJ_DRIVER_ANY, which constrains the argument to the build-generated driver object type range (K_OBJ_DRIVER_FIRST..K_OBJ_DRIVER_LAST) — the real struct device instances placed by the linker — so the state and ops.deinit fields are once again kernel-controlled. | ||||
| CVE-2026-19569 | 2026-10-09 | 8.8 High | ||
| dynamic_object_create() in kernel/userspace/userspace.c computed the backing allocation for a dynamically allocated kernel object as obj_size_get(otype) + size, and for thread stack elements as STACK_ELEMENT_DATA_SIZE(size) (a round-up plus fixed overhead), without checking either expression for unsigned wrap-around. A size close to SIZE_MAX makes the computed total wrap to a very small value, so the heap chunk handed out is a few bytes while the object descriptor is still tagged with the full requested type and registered in the kernel object table. The size argument reaches that arithmetic directly from user mode. k_object_alloc_size() is declared __syscall in include/zephyr/sys/kobject.h, its verifier z_vrfy_k_object_alloc_size() in kernel/userspace/userspace_handler.c is a bare pass-through, and z_object_alloc() only range-checks otype — nothing bounds size. The stack-element branch is additionally reachable through the k_thread_stack_alloc() syscall via kernel/dynamic.c. Because subsequent kernel-object validation checks only the object's type and initialization state, the undersized handle passes K_SYSCALL_OBJ_INIT()/K_SYSCALL_OBJ_NEVER_INIT(), and the matching init syscall (for example k_mutex_init(), k_sem_init(), or k_thread_create()) then writes a complete object over the truncated allocation. An unprivileged user-mode thread can therefore trigger a supervisor-mode out-of-bounds write into the kernel resource-pool heap, of a size and content it substantially controls, corrupting sys_heap chunk metadata and adjacent kernel objects. Under CONFIG_GEN_PRIV_STACKS the thread-stack branch additionally stores an attacker-influenced wild pointer as a user thread's privileged stack base. The practical result is escape from the CONFIG_USERSPACE sandbox — kernel-level code execution or at minimum kernel memory corruption and system compromise. Exploitation requires CONFIG_USERSPACE together with CONFIG_DYNAMIC_OBJECTS (also selected by CONFIG_DYNAMIC_THREAD under userspace), and a calling thread with an assigned resource pool. The fix rejects both overflowing computations and frees the partially built descriptor. | ||||
| CVE-2026-19574 | 2026-10-09 | 7 High | ||
| The ARM64 MMU back-end allocated address space identifiers (ASIDs) for memory domains with a bare round-robin counter in arch_mem_domain_init() (arch/arm64/core/mmu.c). VM_ASID_BITS is 8, so only 255 ASIDs exist; once the counter wrapped, arch_mem_domain_init() could hand an ASID to a new domain while a still-live domain held the same one. Domain-private mappings are installed non-global (MT_NG), so the ASID is the only tag separating one domain's cached translations from another's in the TLB. The context-switch path in z_arm64_swap_ptables() only flushes the TLB when the outgoing and incoming domains carry the same ASID, which does not cover a duplicate reached through a third domain: for domains A and C sharing an ASID and an unrelated domain B, the schedule A -> B -> C never takes the flush branch, so the ASID-tagged entries A populated remain resident while C runs. Under SMP two live domains sharing an ASID can additionally be resident on two CPUs at once, which the architecture does not allow for distinct translation-table sets. Triggering the wrap requires a CONFIG_USERSPACE application on ARM64 that creates more than 255 memory domains over its lifetime; k_mem_domain_init() and k_mem_domain_deinit() are supervisor-only APIs and are not exposed as syscalls, so an unprivileged thread cannot drive the counter directly. Once two live domains alias, however, a user-mode thread in one domain can read and write memory belonging to the other domain's partitions and thread stacks with that domain's permissions, defeating the memory-domain isolation boundary. The fix scans the live domain_list before assigning an ASID, advances the round-robin counter past ASIDs already in use, and returns -ENOMEM when all are taken, so domain creation fails closed instead of silently aliasing. | ||||
| CVE-2026-19571 | 2026-10-09 | 6.7 Medium | ||
| The ITE IT8xxx2 SHI host-command backend (subsys/mgmt/ec_host_cmd/backends/ec_host_cmd_backend_shi_ite.c) copied the 8-byte host-command request header from the SPI Rx FIFO directly into the shared receive buffer data->in_msg and only afterwards checked the protocol version and the derived packet length. The interrupt handler also accepted a chip-select assertion and an Rx-valid-length (RVLI) interrupt in any driver state other than SHI_STATE_DISABLED, so a new header could be parsed while the host-command thread was still processing the previous request out of the very same buffer. The host processor is the SPI controller and drives both chip select and the clock. After sending a well-formed request it can immediately de-assert chip select — which returns the driver to the ready state and re-enables the FIFO — and start a second transaction carrying a header with data_len = 0xFFFF. Those eight bytes are written into in_msg before the oversized length is rejected, so they land in a buffer whose contents verify_rx() in subsys/mgmt/ec_host_cmd/ec_host_cmd_handler.c has already validated. If this lands in the window before the host-command thread executes args.input_buf_size = rx_header->data_len, the framework hands the registered command handler a 65535-byte input length over a 256-byte buffer. The result is an out-of-bounds read of up to roughly 64 KiB beyond the request buffer: command handlers that copy or echo input_buf_size bytes disclose adjacent embedded-controller memory back to the host or overflow the response buffer, and a read past the end of SRAM faults the controller. The same race also allows cmd_id and cmd_ver to be swapped after checksum verification and after handler lookup. Exploitation requires the ability to drive the inter-processor SHI bus (a compromised host OS or physical access to the SPI lines) and winning a timing race, which the SPI controller can retry indefinitely. The fix parses the header into a local struct ec_host_cmd_request_header and copies it into in_msg only after the length has been bounded by sizeof(data->in_msg), and ignores chip-select and RVLI interrupts outside SHI_STATE_READY_TO_RECV/SHI_STATE_RECEIVING. A residual, bounded race remains: an end-of-transaction interrupt still resets the state to ready while the host-command thread owns the buffer, so a valid second request can still overwrite the in-flight request's contents, unlike the NPCX backend which parks in SHI_STATE_CNL_RESP_NOT_RDY while the buffer is in use. | ||||
| CVE-2026-19570 | 2026-10-09 | 8.8 High | ||
| The LE Audio Broadcast Sink in subsys/bluetooth/audio/bap_broadcast_sink.c copies subgroup metadata from a received Basic Audio Announcement (BASE) into the static Broadcast Audio Scan Service parameter structure mod_src_param without any bounds check. In base_subgroup_meta_cb() the destination element was selected as mod_src_param.subgroups[mod_src_param.num_subgroups] with no test against ARRAY_SIZE(mod_src_param.subgroups) (sized by CONFIG_BT_BAP_BASS_MAX_SUBGROUPS, default 1), and the metadata was copied with memcpy() using the raw on-air length returned by bt_bap_base_get_subgroup_codec_meta() into a metadata array sized by CONFIG_BT_AUDIO_CODEC_CFG_MAX_METADATA_SIZE (default 4). The BASE validator bt_bap_base_get_base_from_ad() only checks structural consistency and permits up to ~24 subgroups and metadata LTVs of ~240 octets. The defect is reached from the periodic advertising receive callback: pa_recv() → bt_data_parse() → pa_decode_base() → update_recv_state_base() → bt_bap_base_foreach_subgroup() → base_subgroup_meta_cb(). Every broadcast sink registers a scan-delegator receive state at creation (bt_bap_broadcast_sink_create() calls broadcast_sink_add_src()), and CONFIG_BT_BAP_BROADCAST_SINK depends on CONFIG_BT_BAP_SCAN_DELEGATOR, so the path is active in every broadcast-sink build once the device is periodic-advertising-synced. An attacker in radio range who operates a broadcast source the device syncs to — or who impersonates the advertiser address and SID of one already in use, periodic advertising data being unauthenticated — can change the BASE at will; each new BASE is re-parsed. A crafted BASE therefore writes attacker-chosen bytes past the end of a fixed static object in .bss: up to roughly 236 bytes for an oversized metadata LTV, plus whole struct bt_bap_bass_subgroup records for each subgroup beyond CONFIG_BT_BAP_BASS_MAX_SUBGROUPS. This is memory corruption of adjacent Bluetooth-audio state reachable with no pairing, bonding or GATT connection, with a potential for remote code execution in the Bluetooth RX thread; in addition, the unvalidated metadata_len is forwarded to bt_bap_scan_delegator_mod_src(), which neither clamps it nor rejects it, leading to a further copy into the receive state and to out-of-bounds memory being disclosed in the BASS receive-state notification sent to a connected Broadcast Assistant. The fix rejects a BASE carrying more subgroups than the receive state can hold (discarding the update entirely) and omits metadata that does not fit rather than copying it, and additionally honours the previously-ignored error return of the subgroup decode pass. | ||||
| CVE-2026-95184 | 1 Gnu | 1 Gnutls | 2026-10-09 | 7.5 High |
| Improper certificate validation in gnutls v3.8.13 causes the application to reject legitimate certificates for valid users, leading to a Denial of Service (DoS). | ||||
| CVE-2026-95210 | 1 Gnu | 1 Gnutls | 2026-10-09 | 9.1 Critical |
| Improper certificate validation in gnutls v3.8.13 causes the application to accept certificates containing invalid extensions. | ||||
| CVE-2026-102488 | 1 Octopus | 1 Octopus Server | 2026-10-09 | N/A |
| In affected versions, Octopus Server incorrectly evaluates multiple scoped permission assignments, allowing a highly privileged user to obtain deployment permissions beyond those actually granted to them. | ||||
| CVE-2023-5649 | 1 Broadcom | 1 Brocade Active Support Connectivity Gateway | 2026-10-09 | N/A |
| An Improper Input Validation vulnerability for the registered case credentials in Brocade ASCG before v3.0 could allow a local authenticated user to provide invalid inputs like special characters leading to a Denial of Service (DoS) when collecting “supportsave” from a Brocade Switch. | ||||
| CVE-2026-5047 | 1 Broadcom | 1 Brocade Sannav | 2026-10-09 | N/A |
| A vulnerability in Brocade SANnav before 2.4.0b and 3.0.0 prints encoded passwords and authentication tokens in log files. The vulnerability could allow an authenticated attacker with access to the log file including the SANnav supportsave to access the passwords. | ||||
| CVE-2026-5048 | 1 Broadcom | 1 Brocade Sannav | 2026-10-09 | N/A |
| In Brocade SANnav before 3.0.0a, an SQL Injection vulnerability in various external API inventories have a vulnerability that allows an authenticated attacker to inject malicious data into some of the REST API -query parameters. | ||||
| CVE-2026-5049 | 1 Broadcom | 1 Brocade Sannav | 2026-10-09 | N/A |
| A path traversal vulnerability affects the The Zone Alias Import flow feature in Brocade SANnav before 3.0.0a. A local authenticated attacker can write an uploaded content outside the intended directory. | ||||
| CVE-2026-5769 | 1 Broadcom | 1 Brocade Sannav | 2026-10-09 | N/A |
| A vulnerability in Brocade SANnav before 3.0.1 can have the Brocade Fabric OS switch admin password captured in plaintext within a memory swap file on the server hosting the Brocade SANnav Virtual Machine (VM). This can happen when the SANnav server encounters an Out Of Memory (OOM) condition. The vulnerability could allow an authenticated admin user with access to the server hosting the SANnav to potentially view the memory swap file and access the password(s). | ||||
| CVE-2026-85421 | 1 Broadcom | 1 Brocade Active Support Connectivity Gateway | 2026-10-09 | N/A |
| A critical security vulnerability has been identified in Brocade ASCG versions before 3.5.0. The HTTPS service fails to properly enforce authentication or access control checks on incoming requests. An unauthenticated attacker with network access can issue control commands, alter cluster states, and modify system configurations, leading to a complete compromise of the streaming service control plane. | ||||
| CVE-2026-85422 | 1 Broadcom | 1 Brocade Active Support Connectivity Gateway | 2026-10-09 | N/A |
| A vulnerability in Brocade ASCG version before 3.5.0 could allow an attacker to obtain a static cryptographic key hardcoded into the software binaries to secure sensitive data at rest and to protect inter-node communication protocols. An attacker who extracts this key can decrypt stored management credentials or craft forged administrative synchronization messages. | ||||
| CVE-2026-85423 | 1 Broadcom | 1 Brocade Active Support Connectivity Gateway | 2026-10-09 | N/A |
| A vulnerability has been identified in the data collection service of Brocade ASCG versions before 3.5.0. An API endpoint within the data collector service fails to perform authentication or authorization checks on incoming requests. An attacker with network access to the service can instruct the application to establish SSH connections to arbitrary hosts and execute arbitrary system commands, effectively turning the appliance into an unauthenticated proxy or execution vector. | ||||