🚨 CVE-2026-10654
A race condition in the Zephyr Bluetooth Classic RFCOMM host stack (subsys/bluetooth/host/classic/rfcomm.c) mishandles a simultaneous bidirectional session disconnect. When the local device has initiated a session teardown (state BT_RFCOMM_STATE_DISCONNECTING, DISC sent, RTX timer armed) and the connected peer concurrently sends its own DISC frame for dlci 0, rfcomm_handle_disc() invokes rfcomm_session_disconnected(), which unconditionally forced the session to BT_RFCOMM_STATE_DISCONNECTED without ever calling bt_l2cap_chan_disconnect().
Because the recovery timer was also cancelled and a later UA is ignored in the DISCONNECTED state, the session becomes permanently wedged: the underlying L2CAP channel is never released and the session slot in the fixed bt_rfcomm_pool[CONFIG_BT_MAX_CONN] array is never reclaimed (its conn pointer stays set).
Subsequent bt_rfcomm_dlc_connect() calls on that connection fail with -EINVAL due to the invalid session state, so RFCOMM service is denied for that peer, and repeated occurrences can exhaust the session pool. The DISC frame is peer-controlled over the air, but exploitation requires the peer's DISC to collide with a local-initiated disconnect (a high-complexity timing race). Impact is availability/resource-leak only; there is no memory-safety, confidentiality, or integrity consequence. The defect shipped in released versions (present in v4.4.0 and earlier).
The fix only transitions to DISCONNECTED when the session is not already in DISCONNECTING, preserving the proper L2CAP teardown path.
🎖@cveNotify
A race condition in the Zephyr Bluetooth Classic RFCOMM host stack (subsys/bluetooth/host/classic/rfcomm.c) mishandles a simultaneous bidirectional session disconnect. When the local device has initiated a session teardown (state BT_RFCOMM_STATE_DISCONNECTING, DISC sent, RTX timer armed) and the connected peer concurrently sends its own DISC frame for dlci 0, rfcomm_handle_disc() invokes rfcomm_session_disconnected(), which unconditionally forced the session to BT_RFCOMM_STATE_DISCONNECTED without ever calling bt_l2cap_chan_disconnect().
Because the recovery timer was also cancelled and a later UA is ignored in the DISCONNECTED state, the session becomes permanently wedged: the underlying L2CAP channel is never released and the session slot in the fixed bt_rfcomm_pool[CONFIG_BT_MAX_CONN] array is never reclaimed (its conn pointer stays set).
Subsequent bt_rfcomm_dlc_connect() calls on that connection fail with -EINVAL due to the invalid session state, so RFCOMM service is denied for that peer, and repeated occurrences can exhaust the session pool. The DISC frame is peer-controlled over the air, but exploitation requires the peer's DISC to collide with a local-initiated disconnect (a high-complexity timing race). Impact is availability/resource-leak only; there is no memory-safety, confidentiality, or integrity consequence. The defect shipped in released versions (present in v4.4.0 and earlier).
The fix only transitions to DISCONNECTED when the session is not already in DISCONNECTING, preserving the proper L2CAP teardown path.
🎖@cveNotify
GitHub
bluetooth: classic: rfcomm: fix race condition in session disconnect · zephyrproject-rtos/zephyr@c67b59f
Fix a race condition in RFCOMM session disconnection when both local
and peer devices initiate disconnection simultaneously.
Add state check in `rfcomm_session_disconnected()` to only transition
t...
and peer devices initiate disconnection simultaneously.
Add state check in `rfcomm_session_disconnected()` to only transition
t...
🚨 CVE-2026-10655
The asynchronous SNTP client in Zephyr (subsys/net/lib/sntp/sntp.c, sntp_close_async) closed the UDP socket file descriptor directly from the calling thread immediately after detaching it from the network socket service, without synchronizing with the socket-service poll thread.
The socket service thread polls each socket via zvfs_poll, which (in zsock_poll_prepare_ctx) registers a k_poll_event pointing into the socket's net_context (&ctx->recv_q) and then blocks in k_poll without holding a reference or lock. net_context objects are allocated from a fixed pool (contexts[CONFIG_NET_MAX_CONTEXTS]) and reused after close.
When sntp_close_async is invoked from a different thread than the poll thread (in the in-tree consumer subsys/net/lib/config/init_clock_sntp.c, the SNTP timeout handler runs on the system workqueue while the socket service thread is blocked in poll on the same fd), the close frees and may reuse the net_context while the poll thread still has a poller node linked into the freed object, resulting in a use-after-free / object confusion of kernel poll structures.
The SNTP timeout path is the normal no-response failure mode, so a network peer or off-path attacker who drops or delays the SNTP/NTP response can drive the racing close repeatedly (and periodically with NET_CONFIG_SNTP_INIT_RESYNC). The most likely consequence is a crash of the networking thread (denial of service), with potential memory corruption when the freed context slot is reallocated.
The fix defers the close to the socket service thread itself via net_socket_service_close (NET_SOCKET_SERVICE_CLOSE_SOCKETS), so the same thread that polls performs the close, eliminating the race. Affected releases: v4.2.0 through v4.4.0.
🎖@cveNotify
The asynchronous SNTP client in Zephyr (subsys/net/lib/sntp/sntp.c, sntp_close_async) closed the UDP socket file descriptor directly from the calling thread immediately after detaching it from the network socket service, without synchronizing with the socket-service poll thread.
The socket service thread polls each socket via zvfs_poll, which (in zsock_poll_prepare_ctx) registers a k_poll_event pointing into the socket's net_context (&ctx->recv_q) and then blocks in k_poll without holding a reference or lock. net_context objects are allocated from a fixed pool (contexts[CONFIG_NET_MAX_CONTEXTS]) and reused after close.
When sntp_close_async is invoked from a different thread than the poll thread (in the in-tree consumer subsys/net/lib/config/init_clock_sntp.c, the SNTP timeout handler runs on the system workqueue while the socket service thread is blocked in poll on the same fd), the close frees and may reuse the net_context while the poll thread still has a poller node linked into the freed object, resulting in a use-after-free / object confusion of kernel poll structures.
The SNTP timeout path is the normal no-response failure mode, so a network peer or off-path attacker who drops or delays the SNTP/NTP response can drive the racing close repeatedly (and periodically with NET_CONFIG_SNTP_INIT_RESYNC). The most likely consequence is a crash of the networking thread (denial of service), with potential memory corruption when the freed context slot is reallocated.
The fix defers the close to the socket service thread itself via net_socket_service_close (NET_SOCKET_SERVICE_CLOSE_SOCKETS), so the same thread that polls performs the close, eliminating the race. Affected releases: v4.2.0 through v4.4.0.
🎖@cveNotify
GitHub
net: sntp: fix close-while-polling in `sntp_close_async` · zephyrproject-rtos/zephyr@ef47bdf
Fix `sntp_close_async` closing the socket while the socket service is
still polling it by deferring the close operation to the socket service.
Signed-off-by: Jordan Yates <jordan@embeint.com>
still polling it by deferring the close operation to the socket service.
Signed-off-by: Jordan Yates <jordan@embeint.com>
🚨 CVE-2026-9263
The Zephyr Bluetooth controller ISO Adaptation Layer (subsys/bluetooth/controller/ll_sw/isoal.c) fails to validate the length field of a framed ISO PDU start segment. Per the Bluetooth specification a start segment (sc=0) always carries a 3-byte time_offset, so its segment-header len must be at least PDU_ISO_SEG_TIMEOFFSET_SIZE (3). isoal_check_seg_header() accepted start segments with len < 3 as valid, and isoal_rx_framed_consume() then computed length = seg_hdr->len - 3 in a uint8_t, underflowing to 253-255 when len is 0-2. That oversized length is passed to isoal_rx_append_to_sdu(), whose copy is clamped only against the destination SDU buffer size, not the source PDU length, so up to ~255 bytes of controller memory beyond the received PDU are copied (via sink_sdu_write_hci()/net_buf_add_mem) into an HCI ISO data packet and delivered to the host. The PDU and its segment headers are entirely attacker-controlled and arrive over the air, reachable through both the CIS and BIS-sync HCI data paths (hci_driver.c) and the vendor data path (ull_iso.c), so a remote CIS peer or a broadcaster the device is synced to can trigger an out-of-bounds read causing information disclosure to the host and potential denial of service (faults or malformed oversized HCI ISO packets). The flaw affects all Zephyr releases since framed ISO reception was introduced in v3.0.0. The fix rejects sc=0 segments with len < 3 in isoal_check_seg_header() and adds a guard before the subtraction in isoal_rx_framed_consume().
🎖@cveNotify
The Zephyr Bluetooth controller ISO Adaptation Layer (subsys/bluetooth/controller/ll_sw/isoal.c) fails to validate the length field of a framed ISO PDU start segment. Per the Bluetooth specification a start segment (sc=0) always carries a 3-byte time_offset, so its segment-header len must be at least PDU_ISO_SEG_TIMEOFFSET_SIZE (3). isoal_check_seg_header() accepted start segments with len < 3 as valid, and isoal_rx_framed_consume() then computed length = seg_hdr->len - 3 in a uint8_t, underflowing to 253-255 when len is 0-2. That oversized length is passed to isoal_rx_append_to_sdu(), whose copy is clamped only against the destination SDU buffer size, not the source PDU length, so up to ~255 bytes of controller memory beyond the received PDU are copied (via sink_sdu_write_hci()/net_buf_add_mem) into an HCI ISO data packet and delivered to the host. The PDU and its segment headers are entirely attacker-controlled and arrive over the air, reachable through both the CIS and BIS-sync HCI data paths (hci_driver.c) and the vendor data path (ull_iso.c), so a remote CIS peer or a broadcaster the device is synced to can trigger an out-of-bounds read causing information disclosure to the host and potential denial of service (faults or malformed oversized HCI ISO packets). The flaw affects all Zephyr releases since framed ISO reception was introduced in v3.0.0. The fix rejects sc=0 segments with len < 3 in isoal_check_seg_header() and adds a guard before the subtraction in isoal_rx_framed_consume().
🎖@cveNotify
GitHub
Bluetooth: Controller: Fix OOB read in ISOAL · zephyrproject-rtos/zephyr@28080d8
When sc=0, a framed ISO PDU segment header includes a 3-byte time_offset
field, so seg_hdr->len must be at least PDU_ISO_SEG_TIMEOFFSET_SIZE.
isoal_check_seg_header() accepted segments with ...
field, so seg_hdr->len must be at least PDU_ISO_SEG_TIMEOFFSET_SIZE.
isoal_check_seg_header() accepted segments with ...
🚨 CVE-2026-14074
Side-channel information leakage in WebAuthentication in Google Chrome on iOS prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)
🎖@cveNotify
Side-channel information leakage in WebAuthentication in Google Chrome on iOS prior to 150.0.7871.47 allowed a remote attacker to leak cross-origin data via a crafted HTML page. (Chromium security severity: Low)
🎖@cveNotify
Chrome Releases
Stable Channel Update for Desktop
The Chrome team is delighted to announce the promotion of Chrome 150 to the stable channel for Windows, Mac and Linux. This will roll out ov...
🚨 CVE-2026-54406
A malicious actor with access to the network and high privileges could exploit a Path Traversal vulnerability found in self-hosted instances of UniFi Network Application to escalate write permission on the host device.
🎖@cveNotify
A malicious actor with access to the network and high privileges could exploit a Path Traversal vulnerability found in self-hosted instances of UniFi Network Application to escalate write permission on the host device.
🎖@cveNotify
🚨 CVE-2026-54407
A malicious actor with access to the network could exploit an Improper Access Control vulnerability found in UniFi Protect Application to bypass authentication in certain UniFi Protect Application API endpoints.
🎖@cveNotify
A malicious actor with access to the network could exploit an Improper Access Control vulnerability found in UniFi Protect Application to bypass authentication in certain UniFi Protect Application API endpoints.
🎖@cveNotify
🚨 CVE-2026-55114
A malicious actor with access to the network and low privileges could exploit an Improper Access Control vulnerability found in UniFi Network Application to escalate privileges within the UniFi Network Application.
🎖@cveNotify
A malicious actor with access to the network and low privileges could exploit an Improper Access Control vulnerability found in UniFi Network Application to escalate privileges within the UniFi Network Application.
🎖@cveNotify
🚨 CVE-2026-55118
A malicious actor with access to the network,low privileges and under certain conditions could exploit an Improper Access Control vulnerability found in UniFi Network Application to escalate privileges within the UniFi Network Application.
🎖@cveNotify
A malicious actor with access to the network,low privileges and under certain conditions could exploit an Improper Access Control vulnerability found in UniFi Network Application to escalate privileges within the UniFi Network Application.
🎖@cveNotify
🚨 CVE-2026-56841
A malicious actor with access to the network and low privileges could exploit an authenticated SQL Injection vulnerability found in UniFi Protect Application to escalate privileges on the host device.
🎖@cveNotify
A malicious actor with access to the network and low privileges could exploit an authenticated SQL Injection vulnerability found in UniFi Protect Application to escalate privileges on the host device.
🎖@cveNotify
🚨 CVE-2026-13743
CubeSpace CW0057 Reaction Wheel firmware versions prior to 5.0.20 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. This could allow an attacker with physical access to the product to upload arbitrary malicious firmware to the device without authentication.
🎖@cveNotify
CubeSpace CW0057 Reaction Wheel firmware versions prior to 5.0.20 are vulnerable to an Improper Verification of Cryptographic Signature vulnerability. This could allow an attacker with physical access to the product to upload arbitrary malicious firmware to the device without authentication.
🎖@cveNotify
🚨 CVE-2026-52187
Buffer Overflow vulnerability in UTT nv518G nv518GV3v3.2.7-210919-161313 allows a remote attacker to cause a denial of service via the gohead/sub_483ba0 component
🎖@cveNotify
Buffer Overflow vulnerability in UTT nv518G nv518GV3v3.2.7-210919-161313 allows a remote attacker to cause a denial of service via the gohead/sub_483ba0 component
🎖@cveNotify
GitHub
CVEreport/518G/FUN_00483ba0/README.md at main · akuma-QAQ/CVEreport
Contribute to akuma-QAQ/CVEreport development by creating an account on GitHub.
🚨 CVE-2026-38968
ntopng through 6.6 is vulnerable to Predictable Session Identifier which can lead to Session Hijacking. HTTP session identifiers in src/HTTPserver.cpp use weak time-seeded pseudo-randomness during session creation. As a result, fresh authenticated logins can receive deterministic or colliding session cookies under attacker-controlled timing.
🎖@cveNotify
ntopng through 6.6 is vulnerable to Predictable Session Identifier which can lead to Session Hijacking. HTTP session identifiers in src/HTTPserver.cpp use weak time-seeded pseudo-randomness during session creation. As a result, fresh authenticated logins can receive deterministic or colliding session cookies under attacker-controlled timing.
🎖@cveNotify
GitHub
Further improvement to https://github.com/ntop/ntopng/commit/179a346c… · ntop/ntopng@14e2249
…eb6239fd36128ccca3efa8f9ea61eeb5
🚨 CVE-2026-38969
ruby webrick through v1.9.2 WEBrick reparses trailer Content-Length into canonical request state, enabling request smuggling.
🎖@cveNotify
ruby webrick through v1.9.2 WEBrick reparses trailer Content-Length into canonical request state, enabling request smuggling.
🎖@cveNotify
GitHub
[BUG] WEBrick reparses trailer Content-Length into canonical request state, enabling request metadata confusion / request smuggling…
Summary The latest ruby/webrick still accepts a Content-Length value from chunked request trailers and exposes it as canonical request metadata to the application. A crafted chunked request whose r...
🚨 CVE-2026-38970
pdfcpu through v0.11.1 contains an uncontrolled-recursion denial-of-service issue in pkg/pdfcpu/model/parse.go. The parser descends recursively through nested PDF objects, including arrays, via ParseObjectContext() and parseArray() without enforcing a maximum nesting depth.
🎖@cveNotify
pdfcpu through v0.11.1 contains an uncontrolled-recursion denial-of-service issue in pkg/pdfcpu/model/parse.go. The parser descends recursively through nested PDF objects, including arrays, via ParseObjectContext() and parseArray() without enforcing a maximum nesting depth.
🎖@cveNotify
GitHub
GitHub - pdfcpu/pdfcpu: PDF tooling for Go and the command line.
PDF tooling for Go and the command line. Contribute to pdfcpu/pdfcpu development by creating an account on GitHub.
🚨 CVE-2026-38971
ardupilot through Plane-4.6.3 was found to contain an out-of-bounds read issue in libraries/GCS_MAVLink/GCS_serial_control.cpp in GCS_MAVLINK::handle_serial_control().
🎖@cveNotify
ardupilot through Plane-4.6.3 was found to contain an out-of-bounds read issue in libraries/GCS_MAVLink/GCS_serial_control.cpp in GCS_MAVLINK::handle_serial_control().
🎖@cveNotify
GitHub
GitHub - ArduPilot/ardupilot: ArduPlane, ArduCopter, ArduRover, ArduSub source
ArduPlane, ArduCopter, ArduRover, ArduSub source. Contribute to ArduPilot/ardupilot development by creating an account on GitHub.
🚨 CVE-2026-52830
fast-mcp-telegram is a Telegram MCP Server. Prior to 0.19.1, fast-mcp-telegram validates HTTP Bearer tokens by joining the raw token string into a session-file path. The verifier rejects the exact reserved token telegram, but it does not reject path separators or normalize the path before checking whether the session file exists. A remote HTTP client can therefore authenticate as the default legacy session with a token such as ../fast-mcp-telegram/telegram when the documented default session file ~/.config/fast-mcp-telegram/telegram.session exists. This bypasses the reserved session name control that is intended to prevent HTTP multi-user sessions from colliding with the default stdio or legacy account. With account-prefixed MCP tools enabled, the attacker still sees and calls the prefixed tools for the default account, so the prefix middleware does not stop the session selection bypass. This vulnerability is fixed in 0.19.1.
🎖@cveNotify
fast-mcp-telegram is a Telegram MCP Server. Prior to 0.19.1, fast-mcp-telegram validates HTTP Bearer tokens by joining the raw token string into a session-file path. The verifier rejects the exact reserved token telegram, but it does not reject path separators or normalize the path before checking whether the session file exists. A remote HTTP client can therefore authenticate as the default legacy session with a token such as ../fast-mcp-telegram/telegram when the documented default session file ~/.config/fast-mcp-telegram/telegram.session exists. This bypasses the reserved session name control that is intended to prevent HTTP multi-user sessions from colliding with the default stdio or legacy account. With account-prefixed MCP tools enabled, the attacker still sees and calls the prefixed tools for the default account, so the prefix middleware does not stop the session selection bypass. This vulnerability is fixed in 0.19.1.
🎖@cveNotify
GitHub
CVE-2026-52830 - GitHub Advisory Database
fast-mcp-telegram: Bearer token path traversal bypasses reserved Telegram session protection
🚨 CVE-2026-13768
Gardyn devices expose a privileged iothubowner key. Access to this key will allow a malicious user to invoke an IoTHub Registry Manager function which returns connection information for all Gardyn Home Kit and Studio devices. Access to this key also allows a malicious user to execute arbitrary commands on a specific connected device and may allow the malicious user to pivot to other devices on the user's network.
🎖@cveNotify
Gardyn devices expose a privileged iothubowner key. Access to this key will allow a malicious user to invoke an IoTHub Registry Manager function which returns connection information for all Gardyn Home Kit and Studio devices. Access to this key also allows a malicious user to execute arbitrary commands on a specific connected device and may allow the malicious user to pivot to other devices on the user's network.
🎖@cveNotify
GitHub
CSAF/csaf_files/OT/white/2026/icsa-26-183-03.json at develop · cisagov/CSAF
CISA CSAF Security Advisories. Contribute to cisagov/CSAF development by creating an account on GitHub.
🚨 CVE-2026-54477
The admin panel lacks standard security headers, enabling clickjacking and cross-site scripting attacks.
🎖@cveNotify
The admin panel lacks standard security headers, enabling clickjacking and cross-site scripting attacks.
🎖@cveNotify
GitHub
CSAF/csaf_files/OT/white/2026/icsa-26-183-03.json at develop · cisagov/CSAF
CISA CSAF Security Advisories. Contribute to cisagov/CSAF development by creating an account on GitHub.
🚨 CVE-2026-55726
The Azure Blob Storage container used for Gardyn device logs is publicly listable without authentication. A malicious user would be able to access any device log file available in the blob storage container.
🎖@cveNotify
The Azure Blob Storage container used for Gardyn device logs is publicly listable without authentication. A malicious user would be able to access any device log file available in the blob storage container.
🎖@cveNotify
GitHub
CSAF/csaf_files/OT/white/2026/icsa-26-183-03.json at develop · cisagov/CSAF
CISA CSAF Security Advisories. Contribute to cisagov/CSAF development by creating an account on GitHub.
🚨 CVE-2026-4967
In IMS, there is a possible out of bounds read due to a missing bounds check. This could lead to remote denial of service with no additional execution privileges needed.
🎖@cveNotify
In IMS, there is a possible out of bounds read due to a missing bounds check. This could lead to remote denial of service with no additional execution privileges needed.
🎖@cveNotify
🚨 CVE-2026-8804
Puppet resource_api (shipped in Puppet Core 8.x and Puppet Enterprise 2023.8.x and 2025.x) does not preserve the sensitive flag on parameters defined via the resource-api, causing values such as passwords to be stored in cleartext in the agent's local transaction state cache. Affected versions of the resource_api module include all versions between 1.5.0 - 1.9.1 and 2.0.0 The issue was fixed in puppet resource_api 1.9.2 and 2.0.1 released with Puppet Core 8.20.0 and PE 2023.8.10 & PE 2025.11.0.
🎖@cveNotify
Puppet resource_api (shipped in Puppet Core 8.x and Puppet Enterprise 2023.8.x and 2025.x) does not preserve the sensitive flag on parameters defined via the resource-api, causing values such as passwords to be stored in cleartext in the agent's local transaction state cache. Affected versions of the resource_api module include all versions between 1.5.0 - 1.9.1 and 2.0.0 The issue was fixed in puppet resource_api 1.9.2 and 2.0.1 released with Puppet Core 8.20.0 and PE 2023.8.10 & PE 2025.11.0.
🎖@cveNotify