Vulnerabilidades

*** Pendiente de traducción *** A malicious actor who lures an authenticated user to a malicious page could exploit a Cross-Origin Resource Sharing (CORS) misconfiguration found in UniFi OS to trigger actions in UniFi OS using that user's session.

*** Pendiente de traducción *** A malicious actor with access to the network could exploit a Path Traversal vulnerability found in UniFi Protect Floodlight devices to access files on the UniFi Protect Floodlight.

*** Pendiente de traducción *** A malicious actor with access to the network could exploit an Improper Input Validation vulnerability found in UniFi Network Application to execute a Denial of Service (DoS) attack on the application.

*** Pendiente de traducción *** A malicious actor with access to the network and low privileges could exploit a series of authenticated SQL Injection vulnerabilities found in UniFi OS to escalate privileges within such UniFi OS devices or instances.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** A malicious actor with access to the network could exploit an Improper Access Control vulnerability found in UniFi Protect Application to bypass authentication for data streaming.

*** Pendiente de traducción *** A malicious actor with access to the network and under certain conditions could exploit an Improper Initialization vulnerability found in UniFi Protect Application to bypass authentication in UniFi Protect Cameras.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: fix UAF in l2cap_sock_cleanup_listen() vs l2cap_conn_del()<br /> <br /> bt_accept_dequeue() unlinks a not-yet-accepted child from the parent<br /> accept queue and release_sock()s it before returning, so the returned<br /> sk has no caller reference and is unlocked.<br /> <br /> l2cap_sock_cleanup_listen() walks these children on listening-socket<br /> close. A concurrent HCI disconnect drives hci_rx_work -&gt;<br /> l2cap_conn_del() which runs l2cap_chan_del() + l2cap_sock_kill() and<br /> frees the child sk and its l2cap_chan; cleanup_listen() then uses both:<br /> <br /> BUG: KASAN: slab-use-after-free in l2cap_sock_kill<br /> l2cap_sock_kill / l2cap_sock_cleanup_listen / __x64_sys_close<br /> Freed by: l2cap_conn_del -&gt; l2cap_sock_close_cb -&gt; l2cap_sock_kill<br /> <br /> This is distinct from the two fixes already in this area: commit<br /> e83f5e24da741 ("Bluetooth: serialize accept_q access") serialises the<br /> accept_q list/poll and takes temporary refs inside bt_accept_dequeue(),<br /> and CVE-2025-39860 serialises the userspace close()/accept() race by<br /> calling cleanup_listen() under lock_sock() in l2cap_sock_release().<br /> Neither covers l2cap_conn_del() running from hci_rx_work, so this UAF<br /> still reproduces on current bluetooth/master.<br /> <br /> Take the reference at the source: bt_accept_dequeue() does sock_hold()<br /> while sk is still locked, before release_sock(); callers sock_put().<br /> cleanup_listen() pins the chan with l2cap_chan_hold_unless_zero() under<br /> a brief child sk lock (serialising vs l2cap_sock_teardown_cb()), drops<br /> it before l2cap_chan_lock(), and skips a duplicate l2cap_sock_kill() on<br /> SOCK_DEAD. conn-&gt;lock is not taken here: cleanup_listen() runs under<br /> the parent sk lock and that would invert<br /> conn-&gt;lock -&gt; chan-&gt;lock -&gt; sk_lock (lockdep).<br /> <br /> KASAN/SMP: an unprivileged listen/close vs HCI-disconnect race produced<br /> 12 use-after-free reports per run before this change; 0, and no lockdep<br /> report, over 1600+ raced iterations after it on bluetooth/master.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: L2CAP: use chan timer to close channels in cleanup_listen()<br /> <br /> l2cap_chan_close() removes the channel from conn-&gt;chan_l, which<br /> must be done under conn-&gt;lock. cleanup_listen() runs under the<br /> parent sk_lock, so acquiring conn-&gt;lock would invert the<br /> established conn-&gt;lock -&gt; chan-&gt;lock -&gt; sk_lock order.<br /> <br /> Instead of calling l2cap_chan_close() directly, schedule<br /> l2cap_chan_timeout with delay 0 to close the channel<br /> asynchronously. The timeout handler already acquires conn-&gt;lock<br /> and chan-&gt;lock in the correct order.<br /> <br /> The timer is only armed when chan-&gt;conn is still set: if it is<br /> already NULL, l2cap_conn_del() has already processed this channel<br /> (l2cap_chan_del + l2cap_sock_teardown_cb + l2cap_sock_close_cb),<br /> so there is nothing left to do. If l2cap_conn_del() races in<br /> after the timer is armed, __clear_chan_timer() inside<br /> l2cap_chan_del() cancels it; if the timer has already fired, the<br /> handler returns harmlessly because chan-&gt;conn was cleared.

*** Pendiente de traducción *** A malicious actor with access to the network and low privileges could exploit a Server-Side Request Forgery (SSRF) to escalate privileges within such UniFi OS devices or instances.

*** Pendiente de traducción *** A malicious actor with access to the network and low privileges could exploit an Improper Input Validation vulnerability found in UniFi OS to execute a Command Injection on the host device.