CVE Feed

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in WP Chill Gallery PhotoBlocks photoblocks-grid-gallery allows Stored XSS.This issue affects Gallery PhotoBlocks: from n/a through 1.3.7.

Missing Authorization vulnerability in ThimPress LearnPress learnpress allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects LearnPress: from n/a through 4.4.11.

Missing Authorization vulnerability in TMS Amelia ameliabooking allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Amelia: from n/a through 2.4.10.

Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in TMS Amelia ameliabooking allows Stored XSS.This issue affects Amelia: from n/a through 2.4.12.

SQL injection in the database-query custom resource handlers in the Amazon Web Services (AWS) Cloud Development Kit (CDK) @aws-cdk/aws-redshift-alpha module before 2.274.0-alpha.0 could allow a third party who can influence construct property values to run SQL statements with Amazon Redshift superuser privileges, including granting access to all cluster users. The statements are reachable through crafted user names, comments, or passwords. To remediate this issue, users should upgrade to version 2.274.0-alpha.0 or later and review existing table grants to PUBLIC.

zip is a zip library for Rust that supports reading and writing simple ZIP files. From 1.3.0 until 9.0.0, ZipArchive::extract in src/read/mod.rs calls Vec::with_capacity for a symbolic link target using the attacker-controlled ZIP64 uncompressed_size before reading entry data. A small archive can request an impossible capacity, causing the infallible allocation path to abort the process before the entry is validated. The failure cannot be contained with catch_unwind or a worker thread, allowing repeated denial of service in archive-processing applications. This issue is fixed in version 9.0.0.

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Awesomemotive Easy Digital Downloads easy-digital-downloads allows Leveraging Race Conditions.This issue affects Easy Digital Downloads: from n/a through 3.7.1.

zip is a zip library for Rust that supports reading and writing simple ZIP files. From 7.2.0 until 9.0.0, ZipArchive::extract and ZipArchive::extract_unwrapped_root_dir use safe_prepare_path in src/read/zipfile.rs and simplified_components in src/path.rs to validate symbolic link targets with a lexical prefix comparison rather than resolving each intermediate link. An attacker who knows or can guess the absolute extraction destination can create a chain whose apparent target remains under the destination while an intermediate symlink resolves outside it, allowing attacker-controlled files to be created or overwritten with the extracting process's privileges. On Windows, discarded drive and UNC prefixes can permit a single-link escape when the process has SeCreateSymbolicLinkPrivilege, such as through administrator rights or Developer Mode. This regression is distinct from CVE-2025-29787. This issue is fixed in version 9.0.0.

zip is a zip library for Rust that supports reading and writing simple ZIP files. From 5.1.0 until 9.0.0, applications built with the legacy-zip feature can reserve output capacity from an attacker-controlled ZIP64 uncompressed size before validating the compressed stream. The ShrinkDecoder path in src/legacy/shrink.rs can panic with a capacity overflow during ZipArchive::extract, and the Reduce and Implode decoders contain the same unbounded preallocation pattern. An unhandled panic can terminate an archive-processing service. This issue is fixed in version 9.0.0.

zip is a zip library for Rust that supports reading and writing simple ZIP files. From 0.6.0 until 9.0.0, the AES entry reader in src/aes.rs verifies its HMAC only when the attacker-controlled data counter reaches zero. If the underlying bounded reader reaches the real end of the archive while data_remaining is still positive, or if an encrypted entry has no payload, the reader can return a clean end of stream without reading and comparing the authentication tag. Applications using by_index_decrypt, by_name_decrypt, by_path_decrypt, or password-enabled by_index_with_options can therefore accept modified plaintext without an authentication error. This issue is fixed in version 9.0.0.

A weakness has been identified in Akuvox Akubela HyPanel PS51 51.130.40.26. The impacted element is an unknown function of the file /login. Executing a manipulation of the argument engrmode with the input admin can lead to improper authentication. The attack may be launched remotely. The vendor was contacted early about this disclosure but did not respond in any way.

zip is a zip library for Rust that supports reading and writing simple ZIP files. Through 9.0.4, ZipArchive treats Central Directory File Header filenames as authoritative while ZipStreamReader extracts using Local File Header filenames without reconciling the duplicate metadata in src/read/stream.rs. A crafted archive can therefore appear benign to a component that inspects the central directory but cause a streaming extractor to write a different attacker-selected path and content, potentially overwriting files used by a downstream service. This issue is fixed in version 9.0.5.

Use of hard-coded cryptographic key vulnerability in Johnson Controls Kantech Entrapass allows Padding Oracle Crypto Attack. This issue affects Kantech Entrapass: before 9.20.

Cleartext storage of sensitive information in memory vulnerability in Johnson Controls Kantech Entrapass allows Retrieve Embedded Sensitive Data. This issue affects Kantech Entrapass: before 9.20.

Pyrus Sync for Windows contains a local privilege escalation vulnerability caused by missing authorization controls in its PyrusSyncService Windows service, which allow an attacker with unprivileged access to create files using the ISyncService contract.

A security flaw has been discovered in 2K Games Sid Meier's Civilization VI 1.0.12.68. The affected element is the function loadstring of the component Lua sandbox. Performing a manipulation results in type confusion. The attack may be initiated remotely. The exploit has been released to the public and may be used for attacks. The patch is named Hotfix November 2026. The vendor was contacted early about this disclosure.

The Espressif AES driver drivers/crypto/crypto_esp32_aes.c advertises a multi-session cipher API — it hands out up to CONFIG_ESP32_CRYPTO_AES_SESSIONS_MAX (default 4) independent sessions, each carrying its own key and direction. The AES peripheral, however, has a single chip-global set of key and mode registers, and aes_begin_session() programmed them exactly once, at session start, outside the aes_lock mutex that serialises the transforms. The per-operation handlers aes_ecb_op(), aes_cbc_op() and aes_ctr_op() then ran aes_hal_transform_block() against whatever key and direction the registers happened to hold. As a result, once a second session is opened with a different key, every subsequent operation on the first session silently uses the second session's key and direction, and no error is reported. Because the key programming happened outside the lock, the correct usage pattern of "each thread does begin, then op, then free on its own session" also races: a second thread's cipher_begin_session() landing between the first thread's begin and its operation makes that operation run under the second thread's key. An attacker who can induce session creation on the device — for example a protocol peer whose connection causes a session key to be installed — can influence which key is resident when a victim operation runs. The impact is a cryptographic failure rather than memory corruption: data the application believed it was protecting under one key is encrypted or decrypted under another. Where the resident key is one the attacker knows or supplied, the affected plaintext becomes recoverable by that attacker, and the operation's direction (encrypt versus decrypt) can likewise be inverted. Exposure requires an application that holds two or more concurrent sessions with different keys against this driver; no in-tree Zephyr subsystem does so today (the 802.15.4 security layer, which does open two sessions, uses CCM mode, which this driver rejects), so the risk falls on application code that uses the documented multi-session API. The fix removes all hardware access from aes_begin_session() and reprograms the key and direction at the top of every operation, inside aes_lock, so the chip-global registers can no longer be observed stale by another session.

In the Bluetooth Classic Hands-Free Profile Audio Gateway role, hfp_ag_create() in subsys/bluetooth/host/classic/hfp_ag.c starts an SDP discovery toward the peer, which links the embedded ag->sdp_param._node into the SDP client's pending request list in subsys/bluetooth/host/classic/sdp.c. If the subsequent bt_rfcomm_dlc_connect() call fails, bt_hfp_ag_connect() cleaned up by memset()-ing the entire AG object while that node was still linked, and while ag->slc_work could still be queued on the system work queue. An in-flight SDP discovery cannot be cancelled — bt_sdp_discover_cancel() is declared in the public header but has no implementation — so the request stays in the list with its func, pool and uuid pointers zeroed. The RFCOMM channel passed to bt_hfp_ag_connect() is taken from the peer's own SDP Hands-Free service record in the normal AG flow (bt_sdp_get_proto_param() performs no range validation, and samples/bluetooth/classic/handsfree_ag feeds the value straight through), so a remote BR/EDR device in radio range that advertises an RFCOMM channel outside the valid range 0x01..0x1e deterministically forces bt_rfcomm_dlc_connect() to fail and reach the wipe. Reading the peer's SDP record requires no pairing, and the peer can also trigger the failure by dropping the ACL or racing an RFCOMM DLC on the same DLCI at the right moment. When the SDP client next advances its request list, sdp_client_discover() dereferences the zeroed parameters — net_buf_alloc(param->pool, …) with a NULL pool and param->uuid->type — and the result-notification paths call through the NULL params->func. Zeroing a linked node also truncates the request list behind a stale tail pointer, and re-arming the freed AG slot re-appends the same node and can produce a self-looping list that hangs the Bluetooth RX thread. The impact is a crash or hang of the Bluetooth stack; the written value is a constant zero at a fixed static address, so no attacker-controlled write is available. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_AG that use the Audio Gateway role are affected.

bt_hfp_hf_connect() in subsys/bluetooth/host/classic/hfp_hf.c allocates the per-connection HFP Hands-Free object with hfp_hf_create(), which starts an SDP discovery by passing the object's embedded hf->sdp_param to bt_sdp_discover(). That call links the caller-owned parameter block into the SDP client's request list (session->reqs in subsys/bluetooth/host/classic/sdp.c). If the subsequent bt_rfcomm_dlc_connect() then failed, the affected code wiped the entire object with (void)memset(new_hf, 0, sizeof(*new_hf)) while that discovery was still outstanding, zeroing the sys_snode_t _node that is still linked in the SDP client's list along with the request's func, uuid and pool pointers, and zeroing the hf->slc_work work item that may already be queued on the system workqueue. The discovery could not be retracted instead: bt_sdp_discover_cancel() is declared in include/zephyr/bluetooth/classic/sdp.h but has no implementation. The failing branch is reachable with peer-supplied input. The documented use of bt_hfp_hf_connect() is to pass the RFCOMM channel read out of the remote Audio Gateway's SDP record; neither bt_sdp_get_proto_param() nor bt_hfp_hf_connect() range-checks that value, so a remote device advertising an HFP AG record with an RFCOMM channel outside 1-30 makes bt_rfcomm_dlc_connect() return -EINVAL and drives the local device into the wipe. The same branch is reached without any application misuse when the remote peer controls connection timing, for example when the RFCOMM session is in BT_RFCOMM_STATE_DISCONNECTING or the ACL is dropped between object creation and the RFCOMM call. Once the object has been wiped, the Bluetooth host continues to use it: sdp_client_alloc_buf() dereferences session->param->pool, which is now NULL, and the SDP receive paths call session->param->func() through a null function pointer, neither of which is NULL-checked. Because the wipe also clears hf->acl, the pool slot is considered free and a retry or an incoming HFP connection re-appends the same still-linked list node, turning session->reqs into a self-referential list that the host's list walkers never leave. The result is a fault or an unrecoverable hang in the Bluetooth host thread; the stray indirect call is through an all-zero pointer whose target the attacker does not control, so the practical impact is denial of service. The fix keeps the object allocated and marks it with a new BT_HFP_HF_FLAG_RELEASING flag, letting bt_hfp_hf_discover_cb() release it once the discovery completes instead of destroying it under the SDP client. Only builds with CONFIG_BT_CLASSIC and CONFIG_BT_HFP_HF enabled are affected.

The IPv6 stack derived the long-lived secret key used to compute RFC 7217 stable interface identifiers (gen_stable_iid() in subsys/net/ip/ipv6.c) and RFC 8981 temporary interface identifiers (gen_temporary_iid() in subsys/net/ip/ipv6_pe.c) with sys_rand_get(). That API is documented as not cryptographically secure, while both RFCs require this key to be an unpredictable random value of at least 128 bits — the unpredictability of every generated IID rests entirely on it. Depending on the platform, sys_rand_get() resolves either to a hardware entropy device or, on boards whose entropy driver sets CONFIG_ENTROPY_NEEDS_PRNG, to the non-cryptographic xoshiro128++ generator in subsys/random/random_xoshiro128.c, which keeps a single global 128-bit state shared with every other sys_rand_get() consumer. Many of those consumers put their output directly on the wire (ephemeral source ports, DNS query IDs, CoAP message IDs and tokens, DHCPv6 transaction IDs, WebSocket masking keys), and the xoshiro state transition is invertible, so an observer of a device's traffic can recover the generator state and reconstruct the IID secret key. Additionally, with the entropy-device backend sys_rand_get() silently falls back to k_cycle_get_32() samples when the entropy driver fails, and returns no error, so the key could be derived from the cycle counter without the caller noticing. With the key known, stable IIDs become directly computable for any prefix (the remaining HMAC inputs — prefix, interface index, interface name, DAD counter — are guessable), and temporary IIDs become linkable after a cheap search over the mixed-in k_uptime_get_32() value. This defeats the properties both features exist to provide: an attacker can track a device across networks and prefixes, and can predict its address inside a /64 without scanning, removing the usual barrier to directly targeting the host. There is no memory-safety, integrity, or availability impact. The fix generates the key with sys_csrand_get() and aborts IID generation with -EIO when no cryptographic randomness is available, instead of silently deriving addresses from a predictable key. Both CONFIG_NET_IPV6_IID_STABLE and CONFIG_NET_IPV6_PE are experimental and disabled by default; builds using CONFIG_TEST_RANDOM_GENERATOR remain predictable by design, as sys_csrand_get() is deliberately routed back to the test generator there.

The Object Transfer Service server builds its Object Action Control Point (OACP) response indication in oacp_ind_send() (subsys/bluetooth/services/ots/ots_oacp.c). Before this fix the four-byte Checksum Value field was appended whenever the requested op code was BT_GATT_OTS_OACP_PROC_CHECKSUM_CALC, regardless of the result code. The response payload is a bare, uninitialized four-byte stack buffer declared with NET_BUF_SIMPLE_DEFINE(resp_param, sizeof(uint32_t)) in bt_gatt_ots_oacp_write(), and it is filled only on the success path of oacp_checksum_proc_validate(). On every failure path the buffer is still empty, so net_buf_simple_pull_le32() was invoked on a zero-length buffer. The OACP characteristic and its client characteristic configuration descriptor are declared with BT_GATT_PERM_WRITE and BT_GATT_PERM_READ | BT_GATT_PERM_WRITE, so no pairing, encryption, or authentication is required. Any peer within radio range that can connect to a device running the OTS server can enable OACP indications and write a nine-byte Calculate Checksum command that fails validation — for example by issuing it with no object selected, which returns BT_GATT_OTS_OACP_RES_INV_OBJ. Because oacp_command_decode() accepts the Calculate Checksum op code unconditionally (it is not guarded by CONFIG_BT_OTS_OACP_CHECKSUM_SUPPORT), builds without checksum support are reachable too: they answer BT_GATT_OTS_OACP_RES_OPCODE_NOT_SUP and take the same bad path. On builds with CONFIG_ASSERT enabled, the zero-length pull trips the assertion inside net_buf_simple_pull_mem() and panics the device, giving a remotely triggered denial of service. On builds with assertions disabled there is no check: the pull returns the untouched stack array and four bytes of uninitialized stack memory are copied into the indication and transmitted to the peer, repeatable on every request. The disclosure is bounded to four bytes per request and the write stays inside the seven-byte res indication buffer, so there is no memory corruption; the impact is uninitialized-memory disclosure plus an availability loss in assertion-enabled configurations.

The Bluetooth host pre-allocates a bt_conn object (a "reservation") from the fixed acl_conns[] pool for every connectable advertising set it starts, in le_adv_start_add_conn() in subsys/bluetooth/host/adv.c. When an incoming peripheral connection completes, find_pending_connect() in subsys/bluetooth/host/hci_core.c looked that reservation up using only the identity and the peer address, with a directed-then-undirected fallback, and had no knowledge of which advertising set actually terminated. With CONFIG_BT_EXT_ADV_MAX_ADV_SET > 1, where the LE Enhanced Connection Complete event is cached until the LE Advertising Set Terminated event identifies the set, this lookup can return the reservation belonging to a different, still-running advertising set. The defect is reachable over the air by any adjacent device. If an application runs two connectable extended advertising sets on the same identity — one undirected and one directed at a peer P (the common "directed reconnect to a bonded central while still accepting new centrals" pattern) — a remote initiator whose address maps to P connecting on the undirected set causes the directed set's reservation to be consumed instead. The initiator address is chosen freely by the remote device and is not authenticated at link establishment, so no bonding, pairing or prior relationship is required to trigger the mis-attribution. The undirected set's own reservation is then stranded: its BT_ADV_ENABLED flag has already been cleared, and le_adv_stop_free_conn() — the only path that returns a reservation to the pool — is reached only for sets that are still enabled, so bt_le_ext_adv_stop() returns early and the object is never released. Each occurrence permanently consumes one CONFIG_BT_MAX_CONN slot until bt_disable() or reboot. In application patterns that restart the directed advertising set after each disconnect, an attacker can repeat the sequence until the pool is exhausted, after which connectable advertising fails with -ENOMEM and the device can no longer accept connections. As a side effect the directed set keeps advertising without a reservation, so a genuine connection on it is dropped by bt_hci_disconnect(). The impact is availability only; no memory corruption or information disclosure results, and configurations with a single advertising set are unaffected.

A vulnerability was identified in Sunwood-ai-labs github-kanban-mcp-server up to 0.4.0. Impacted is the function handleListIssues of the file src/handlers/issue-handlers.ts. Such manipulation of the argument state/labels leads to os command injection. The attack can be launched remotely. Upgrading to version 0.4.1 is recommended to address this issue. The name of the patch is 253d93bbdf7ee9fe42bd8fdf15feea93ae59cbae. It is suggested to upgrade the affected component.

Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS) vulnerability in Magepeople inc. WpEvently mage-eventpress allows Code Injection.This issue affects WpEvently: from n/a through 5.7.9.

Mattermost versions 11.7.x <= 11.7.10 fail to restrict which built-in roles can be assigned to a team member via the API, which allows a team admin to grant a team member permissions beyond those permitted by the configured permission scheme via the {{update-team-member-roles}} REST API.. Mattermost Advisory ID: MMSA-2026-00734

Syncplify Server! 6.0.0 before 8.8.0 contains a path traversal vulnerability that allows attackers with a symbolic link placed inside a user's home folder to access files outside the virtual filesystem root because confinement is enforced only against the requested path and not the on-disk destination of the link. Attackers can leverage a symlink or, on Windows, a directory junction that points outside the jail to read or access restricted files beyond the intended home-folder boundary.

Syncplify Server! before 8.8.0 contains an access control bypass vulnerability that allows authenticated SFTP users to evade per-path permission overrides by exploiting case-insensitive filesystem path resolution and 8.3 short names. Attackers can address a protected directory using alternate capitalization or its 8.3 short name to perform file uploads and downloads that the configured override is intended to deny, resulting in unauthorized file access.

Arm Keil MDK-Middleware 8.0.0-8.3.0 may allow DHCPv6 Option-Walk Over-Reads and Unintended Data Retransmission

Arm Keil MDK-Middleware 8.3.0 may allow out-of-bounds reads and writes to the FTP Server RX Buffer

A vulnerability was determined in DeepSeek Harness up to 0.2.0-rc.2. This issue affects some unknown processing of the file packages/client/connection/src/browser-auth.ts of the component Browser Auth. This manipulation causes improper authorization. The attack can be initiated remotely. The vendor was contacted early about this disclosure but did not respond in any way.

Arm Keil MDK-Middleware 8.0.0-8.3.0 may allow pre-authentication out-of-bounds read in SNMP processing

OpenHands Software Agent SDK before 1.52.0 contains an unauthenticated remote code execution vulnerability where the DockerWorkspace and Apptainer workspace launchers bind the sandbox agent server to all network interfaces (0.0.0.0) with an empty session_api_keys list, disabling authentication by default. Attackers who can reach the published container port can send unauthenticated HTTP and WebSocket requests to execute arbitrary shell commands as root in the sandbox, access the mounted workspace, and read plaintext secrets from the secrets store.

A vulnerability was found in DeepSeek Harness up to 0.1.0-rc.5. This vulnerability affects the function createContext of the file packages/extensions/cordis-host-runner/src/sandbox.ts. The manipulation results in sandbox issue. It is possible to launch the attack remotely. The vendor was contacted early about this disclosure but did not respond in any way.

**UNSUPPORTED WHEN ASSIGNED**  Authorization bypass in Apache Vysper, all versions. Apache Vysper is an XMPP (Jabber) server library. Its XEP-0077 (In-Band Registration) implementation is missing an authentication check, allowing any authenticated user to compromise other accounts. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative.

**UNSUPPORTED WHEN ASSIGNED**  Unbounded allocation in XML parsing in Apache Vysper; all versions, may lead to an out of memory condition. This issue affects all versions of Apache Vysper. Apache Vysper is an XMPP (Jabber) server library. As this project is retired, we do not plan to release a version that fixes this issue. Users are recommended to find an alternative.

Open5GS 2.6.1 through 2.8.0 contains an out-of-bounds read vulnerability in parse_scheme_output() in lib/sbi/conv.c during SUCI de-concealment due to incomplete length validation. Remote unauthenticated UEs or SBI peers can submit a crafted SUCI with a 42-byte scheme output to a UDM, triggering a heap over-read past the buffer.

Open5GS 1.3.0 through 2.8.0 contains a heap out-of-bounds write vulnerability in parse_multipart() that allows unauthenticated attackers to corrupt memory by supplying an empty multipart boundary. Attackers can send a single crafted multipart/related request to the SBI interface of any network function, overflowing the lookbehind buffer and crashing it.

Netty netty-tcnative before 2.0.84.Final contains an SNI hostname spoofing vulnerability that allows remote unauthenticated clients to alter hostnames via JNI NewStringUTF decoding. Attackers can send overlong encodings like 0xC0 0x80 in the ClientHello server_name to confuse SNI-based certificate selection, access decisions, and logging.

Netty netty-tcnative before 2.0.84.Final contains a denial of service vulnerability in the tcn_write_to_bytebuffer BIO write callback that overreports bytes consumed. Remote TLS 1.3 peers can provoke queued post-handshake records like NewSessionTicket or KeyUpdate to truncate flights, fail connections, or abort the JVM process.

netty-tcnative 2.0.66.Final before 2.0.84.Final built against OpenSSL 3.x contains a use-after-free vulnerability in ssl_tlsext_ticket_key_cb during session ticket key rotation. Remote clients performing TLS handshakes while setSessionTicketKeys0 frees the shared key array cause OpenSSL to read freed HMAC keys, crashing or corrupting ticket processing.

Netty netty-tcnative before 2.0.84.Final contains a heap buffer overflow vulnerability in the tcn_write_to_bytebuffer BIO callback caused by failing to wrap the non-application ring buffer write index. Remote TLS peers can drive handshake, renegotiation, or post-handshake messages into this buffer, triggering an out-of-bounds memcpy that crashes the JVM process.

HtmlSanitizer before 9.2.1039 and 10.0 prereleases before 10.0.1037-beta contains a cross-site scripting vulnerability because SanitizeDom(string) never sanitizes attributes on the html and body wrapper elements. Attackers can supply input with a second body or html tag carrying event handlers like onload, executing script when applications render serialized document or body outer HTML.

Timescale pgvectorscale before 0.9.1 contains a type confusion vulnerability that allows low-privileged database users to corrupt memory by shadowing pgvector's vector type or operators. Attackers with CREATE privilege on the vectorscale schema can pre-create shadow objects, then build and query DiskANN indexes over crafted values to cause out-of-bounds reads and writes, disclosing memory, crashing the server, or escalating privileges.

Bucket Squatting in Google Cloud Run MCP versions prior to 1.11.0 on Google Cloud Platform allows an attacker to intercept and access proprietary source code, execute arbitrary code and exfiltrate data. Users must upgrade to Cloud Run MCP version 1.11.0 or later.

In the Linux kernel, the following vulnerability has been resolved: dm-integrity: fix buffer overflow in inline mode with large tag size In inline mode, dm_integrity_check and dm_integrity_inline_recheck compute the checksum of each block into an on-stack buffer of HASH_MAX_DIGESTSIZE bytes. integrity_sector_checksum pads its result with zeroes up to the tag size, so if the tag size is larger than HASH_MAX_DIGESTSIZE, the padding runs past the end of the buffer. With CONFIG_STACKPROTECTOR the kernel panics in dm_integrity_check on the first read. Enlarge both buffers to hold MAX_TAG_SIZE bytes, as commit b93b6643e9b5 ("dm integrity: fix a crash with unusually large tag size") did for integrity_metadata. Note that this is not a security bug because the buffer overflow can only be triggered by root.

In the Linux kernel, the following vulnerability has been resolved: tee: shm: reject zero-sized allocations in tee_dyn_shm_alloc_helper() tee_dyn_shm_alloc_helper() derives nr_pages from a caller-supplied size and passes it to alloc_pages_exact() without checking it. For size == 0 nr_pages is 0, and alloc_pages_exact(0) calls get_order(0), which is documented as undefined and returns BITS_PER_LONG - PAGE_SHIFT. The page allocator then trips its order > MAX_PAGE_ORDER warning and fails the allocation; on a panic_on_warn kernel that ends the boot. This can be triggered by TEE_IOC_SHM_ALLOC with struct tee_ioctl_shm_alloc_data where size is 0. Reject a zero page count, as register_shm_helper() already does for the register path.

In the Linux kernel, the following vulnerability has been resolved: mm: don't schedule deferred kernel page table freeing while booting Booting with a boot-time function tracer and a filter, for example ftrace=function ftrace_filter=pud_free_pmd_page panics on 7.3-rc4 as soon as the tracer starts: [ 23.531178] Starting tracer 'function' [ 23.675800] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN NOPTI [ 23.819917] KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] [ 23.964025] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.3.0-rc4-fe2ec83746e5-with-fixes-v2+ #195 PREEMPT(undef) [ 24.252248] RIP: 0010:__queue_work+0xab/0xf00 [ 25.981629] Call Trace: [ 26.125727] <TASK> [ 26.413912] ? pagetable_free_kernel+0x20/0x120 [ 26.990283] queue_work_on+0x97/0xf0 [ 27.134382] __cpa_collapse_large_pages+0x501/0x6f0 [ 27.566662] cpa_flush+0x394/0x620 [ 27.998953] change_page_attr_set_clr+0x321/0x4a0 [ 29.151729] set_memory_rox+0xa2/0xf0 [ 29.584018] create_trampoline+0x431/0x6f0 ... [ 44.343347] Kernel panic - not syncing: Attempted to kill the idle task! The boot-time tracer is started from early_trace_init(), which runs before workqueue_init_early(). Making its trampoline read-only splits a large page, and CPA collapses it again right away. The split table has been a kernel page table since commit 9e4a3ec3411b ("x86/mm/pat: Allocate split page tables as kernel page tables"), so the collapse frees it through pagetable_free_kernel(), which queues work on system_percpu_wq - still NULL at that point. That commit is correct in itself; it only lets CPA reach pagetable_free_kernel() before the workqueue that function relies on exists. Keep putting the table on the list, but don't schedule the work while the system is still booting. A core_initcall schedules it once to free whatever was queued by then.

Improper Restriction of XML External Entity Reference vulnerability in Apache Camel Saxon component. This issue affects Apache Camel: from 4.0.0 before 4.18.5, from 4.19.0 before 4.22.2. XQueryBuilder in camel-saxon, which evaluates expressions for the xquery language and the xquery component, built its default Saxon Configuration with parse options that set only a whitespace stripping rule, leaving the XML parser at its defaults, under which a DOCTYPE declaration is accepted and external entities are resolved. A message body of type String or byte[], or any body read as an InputStream, is first turned into a javax.xml.transform.Source by Camel's own XML type converters, which configure the parser against external entities, so those bodies were not affected. A body that was already a Source, however, was handed to Saxon unchanged, and when that Source still had to be parsed, as a stream-based Source does, Saxon parsed it with that Configuration, bypassing the protection applied to the other body types. Such a body arises, for example, after a route converts the message with convertBodyTo(Source.class), or when a component or processor earlier in the route sets the body to a stream-based Source. A DOCTYPE with an external subset, or an external entity, declared in that body was therefore resolved and expanded into the document the expression was evaluated against. An external sender whose XML reaches an XQuery expression or an xquery endpoint in that form could read files readable by the Camel process and cause the process to issue requests to hosts the document names. No non-default option is required, since the default Configuration is used whenever the route does not supply one of its own. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. If users are on the 4.18.x releases stream, then they are suggested to upgrade to 4.18.5. The 4.14.x releases stream and earlier, as well as the 4.15.x to 4.17.x and 4.19.x to 4.21.x release lines, reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, do not evaluate XQuery over a message body that is already a javax.xml.transform.Source when that body carries XML from an untrusted sender, or set the configuration option of the xquery endpoint or language to a Saxon Configuration whose parse options refuse a DOCTYPE declaration and disable external entities and external DTD loading, which is what the fixed releases now apply by default.

The boneIO Black web interface lacks proper clickjacking protections. A remote attacker can embed the control panel in an iframe on a malicious web page and trick an authenticated user on the internal network into clicking buttons that activate relays, open gates, or control blinds. This can lead to unauthorized state changes with potential physical safety consequences. Critically, due to CVE-2026-77053 (authentication disabled by default), any user on the same internal network can trigger attacker-controlled actions by visiting the malicious website. This issue was fixed in version 1.6.0.

Use of Cache Containing Sensitive Information vulnerability in Apache Camel Oauth component. This issue affects Apache Camel: from 4.19.0 before 4.22.2. OAuthClientCredentialsTokenResolver obtains OAuth 2.0 bearer tokens through the client credentials grant on behalf of the components that authenticate their outbound calls with a named OAuth profile, such as camel-openai, camel-langchain4j-agent, camel-huggingface, camel-docling, camel-a2a, camel-spring-ai-chat and the IBM watsonx components, and of applications that call the OAuthClientAuthenticationFactory SPI directly. It kept the tokens it obtained in a static cache shared by every resolver instance and every CamelContext in the JVM, and keyed that cache on the token endpoint and the client ID only, although the token request also carries the client secret and the requested scope. Two profiles that share a token endpoint and a client ID but request different scopes, or authenticate with different client secrets, therefore mapped to the same cache entry: the profile that resolved a token first populated the entry, and the other profile was then handed that token, with no token request made under its own configuration, for as long as the token remained valid. Token caching is enabled by default, and pointing several profiles at one identity provider client is an ordinary use of the profile support rather than an opt-in to an insecure setting. The outcome is an outbound request that carries a token issued for another profile's scope, which can grant broader authority than the calling profile was configured for, or reach a service the token was not issued for; with identity providers that derive a token's audience from the requested scope, a different scope can mean a token for a different service altogether. A profile configured with a different client secret was likewise served the token obtained with the other secret, without authenticating with its own. The profiles are configured by the deployment, which is trusted, so no untrusted input reaches the cache: the party that gains is the service that receives a token it was not meant to receive, which, if hostile or compromised, can replay that token within its scope. Reaching the issue requires a deployment that defines more than one profile sharing a token endpoint and client ID while differing in scope or client secret. Users are recommended to upgrade to version 4.23.0, which fixes the issue. If users are on the 4.22.x releases stream, then they are suggested to upgrade to 4.22.2. The 4.19.x to 4.21.x release lines reached end of life before this issue was resolved and will not receive a fix, so deployments on them must move to a supported release. For deployments that cannot upgrade immediately, disable token caching on every OAuth profile that shares a token endpoint and client ID with another profile, by setting camel.oauth.NAME.cache-tokens=false for a named profile or camel.oauth.cache-tokens=false for the default one, so that each resolution requests a token with that profile’s own scope and client secret, at the cost of a token request on every resolution. Alternatively, register a separate client at the identity provider for each profile that needs a different scope or client secret, so that no two such profiles share a client ID.