| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Arkon through 0.9.2 contains a missing authorization vulnerability in list_skill_versions that allows authenticated employees to read other departments' skill version metadata by bypassing the can_access_skill check. Attackers holding the default skill:read permission can request GET /api/skills/{slug}/versions for another department's skill to obtain version numbers, hashes, storage paths and changelogs. |
| Exrick XBoot through 3.3.4 contains an authorization bypass vulnerability that allows authenticated users to read user records of any department by ignoring role data scope. Attackers can request GET /xboot/user/getByDepartmentId/{departmentId} with arbitrary department ids to retrieve usernames, real names, mobile numbers, emails and status. |
| Cube-studio through 2026.09.01 contains a missing authorization vulnerability in myapp/views/view_pipeline.py that allows authenticated users to view or copy other project groups' pipelines by id. Attackers can enumerate sequential pipeline ids via the web, log, monitoring, pod, and copy_pipeline endpoints to expose DAGs, cluster names, namespaces, Argo workflow ids, and pod names, or clone pipelines. |
| Cube-studio through 2026.09.01 contains an insecure direct object reference vulnerability that allows authenticated users to stop, reset, clear or redeploy other users' notebooks and services by id. Attackers can pass sequential ids to lifecycle endpoints in view_notebook.py, view_inferenceserving.py and view_serving.py to delete pods and take production inference endpoints offline. |
| REBUILD through 4.5.0 contains a missing authorization vulnerability in TaskCommentController.commentList that allows authenticated low-privileged users to read task comments without project membership checks. Attackers can supply the id of a task in a private project to the /project/comments/list endpoint to retrieve its comment content and attachment references. |
| ChatWiki through 2.9.6 contains an insecure direct object reference vulnerability that allows authenticated users to access another tenant's form filters by supplying arbitrary form_id values. Attackers can send sequential form_id values to getFormFilterList, getFormFilterInfo and updateFormFilterSort to read filter rules and overwrite another tenant's filter sort order. |
| FreeRDP before 3.32.0 contains a NULL pointer dereference vulnerability in the websocket transport that allows a malicious gateway to crash clients by sending zero-length pings. When the payload length is zero, websocket_reply_pong passes a nullptr stream to websocket_reply_close, triggering an assertion failure that terminates the client process and causes denial of service. |
| ZenTao PMS through 22.6 contains an authorization bypass vulnerability in action::editComment that allows authenticated users to read and overwrite other users' comments by supplying an arbitrary actionID. Attackers can iterate sequential action ids to modify comments on bugs, stories, tasks, and documents in products and projects they cannot access, and view targeted comment content and attachments. |
| Dokploy through 0.30.8 contains a cross-organization authorization bypass in the port tRPC router that allows authenticated owners or admins of any organization to manage other tenants' ports because the target application's organization is never verified. Attackers supplying a known portId or applicationId to port.create, port.one, port.update, or port.delete can read, modify, delete, or add port mappings, disrupting how victim services are published. |
| An Authorization Bypass Through User-Controlled Key vulnerability affecting Tuleap Enterprise Edition from 17.0 through 17.5 could allow an attacker with tracker administration rights on one tracker to update or delete fields of all the trackers on the instance. |
| Improper Certificate Validation vulnerability in hexpm hex_core allows an attacker who can intercept HTTPS connections to impersonate hex.pm, repo.hex.pm or any other repository or API server to programs that use hex_core's default HTTP adapter on Erlang/OTP 24, or on OTP 25 when the operating system's CA certificates can't be loaded.
hex_core:default_config/0 selects the built-in hex_http_httpc adapter. For an HTTPS request whose adapter config has no ssl option, hex_http_httpc:http_options/2 builds options that verify the server certificate against public_key:cacerts_get/0. When that call raises, the adapter prints a warning and sends the request without ssl options, so httpc uses the defaults of the ssl application, which before OTP 26 don't verify the server certificate. public_key:cacerts_get/0 doesn't exist on OTP 24, so every HTTPS request falls back there, and on OTP 25 it raises when no CA store is found. hex_core versions before 0.11.0 never set ssl options, so they don't verify the server certificate on OTP 25 and earlier whether or not a CA store is found.
The fallback was intended and documented, but the documentation didn't make clear that it meant no certificate verification. Since hex_core 0.8.2 the README has warned that the built-in httpc adapter "has insecure default settings" and recommended other HTTP clients, and the adapter prints "using default ssl options which are insecure" on every request that falls back. hex_core 0.11.0 added certificate verification with the changelog entry "Use secure SSL defaults for OTP 25+". Neither the README nor the warning says that the server certificate isn't verified, the README doesn't say which OTP versions the warning applies to, and on OTP 25 without CA certificates the warning tells users to upgrade to OTP 25 or later, which they already run. This advisory is published so that users who took those notices as general advice know their HTTPS requests weren't authenticated.
This issue affects hex_core: from 0.1.0 before 0.20.0. |
| An authorization bypass through user-controlled key vulnerability has been reported to affect Video Station. If exploited, the vulnerability could allow remote attackers to obtain sensitive data.
We have already fixed the vulnerability in the following version:
Video Station 5.8.8 and later |
| Url redirection to untrusted site ('open redirect') in Windows BitLocker allows an unauthorized attacker to bypass a security feature with a physical attack. |
| Url redirection to untrusted site ('open redirect') in Active Directory Federation Services (AD FS) allows an unauthorized attacker to perform spoofing over a network. |
| RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 and 4.3.3, AMQP 1.0 management exchange.declare skips alternate-exchange permission check. pUT /exchanges/:name (lines 192-240) checks only configure on the declared exchange and passes XArgs straight to rabbitexchange:declare/7. It omits the checkreadpermitted(X) + checkwritepermitted(AE) that rabbitchannel.erl:2540-2548 enforces for the alternate-exchange argument on the AMQP 0-9-1 path. The same file already implements the analogous DLX check for queues (lines 708-719), confirming this is a missing-check bug rather than intentional A user with only configure on exchange X can route X's unroutable messages into an alternate exchange they have no write permission AMQP 1.0 enabled (default in RabbitMQ 4.x) Attacker has configure on at least one exchange but lacks write on the target. This issue is fixed in versions 4.2.9 and 4.3.3. |
| Wheels 4.0.0 through 4.1.2 before 4.2.0 replaces incoming scope conditions with a primary-key condition in findByKey() and exists(key=). For exists(key=), production with error information disabled returns true for an out-of-scope key instead of throwing. Applications relying on scopes for ownership or tenant authorization can therefore load and subsequently modify or delete another user's or tenant's record when the key comes from a request. The 4.2.0 fix combines key conditions with incoming scope, query-builder or where conditions in findByKey(), exists(key=), updateByKey() and deleteByKey(). Other scope-aware finders, aggregates, updateAll() and deleteAll() are not affected. |
| RabbitMQ is a messaging and streaming broker. From 4.2.0 until 4.2.9 and 4.3.3, OAuth2 isinteger(Exp) guard skips token-expiry checks for float exp. validatetokenexpiry/1 (lines 208-214) and expirytimestamp/1 (138-144) both guard with 'when isinteger(Exp)' and fall through to ok/never for float values. josejwt:verify validates only the signature, not exp. With float exp, no expiry validation occurs anywhere in the If the IdP emits exp as a JSON float (RFC 7519 permits fractional NumericDate), both the login-time expiry check and the mid-connection disconnect timer are silently skipped , an already-expired token is accepted, and connections never time OAuth2 backend enabled IdP emits float exp (uncommon; mainstream IdPs emit integers) Attacker possesses a previously-valid signed. This issue is fixed in versions 4.2.9 and 4.3.3. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp
l2cap_ecred_reconf_rsp() calls l2cap_chan_del() without holding
l2cap_chan_lock(). Every other l2cap_chan_del() caller in the file
acquires the lock first. A remote BLE device can send a crafted
L2CAP ECRED reconfiguration response to corrupt the channel list
while another thread is iterating it.
Add l2cap_chan_hold() and l2cap_chan_lock() before l2cap_chan_del(),
and l2cap_chan_unlock() and l2cap_chan_put() after, matching the
pattern used in l2cap_ecred_conn_rsp() and l2cap_conn_del(). |
| In the Linux kernel, the following vulnerability has been resolved:
PCI: Fix pci_slot_trylock() error handling
Commit a4e772898f8b ("PCI: Add missing bridge lock to pci_bus_lock()")
delegates the bridge device's pci_dev_trylock() to pci_bus_trylock() in
pci_slot_trylock(), but it forgets to remove the corresponding
pci_dev_unlock() when pci_bus_trylock() fails.
Before a4e772898f8b, the code did:
if (!pci_dev_trylock(dev)) /* <- lock bridge device */
goto unlock;
if (dev->subordinate) {
if (!pci_bus_trylock(dev->subordinate)) {
pci_dev_unlock(dev); /* <- unlock bridge device */
goto unlock;
}
}
After a4e772898f8b the bridge-device lock is no longer taken, but the
pci_dev_unlock(dev) on the failure path was left in place, leading to the
bug.
This yields one of two errors:
1. A warning that the lock is being unlocked when no one holds it.
2. An incorrect unlock of a lock that belongs to another thread.
Fix it by removing the now-redundant pci_dev_unlock(dev) on the failure
path.
[Same patch later posted by Keith at
https://patch.msgid.link/20260116184150.3013258-1-kbusch@meta.com] |
| The Bluetooth Link Layer control procedure code in subsys/bluetooth/controller/ll_sw/ull_llcp_conn_upd.c retains the received RX node while a Connection Update / Connection Parameter procedure waits for its instant, so the node can later carry the host notification (llcp_rx_node_retain(), which marks it NODE_RX_TYPE_RETAIN and thereby suppresses the normal recycling in ull.c). The default: arm of llcp_rp_cu_rx() and llcp_lp_cu_rx() — the "invalid PDU, terminate the connection" path — completed the procedure without releasing that retained node. llcp_rr_check_done() then dequeued and freed the procedure context with ctx->node_ref.rx still pointing at the retained node, dropping the last reference to it.
A peer device in radio range can reach this without pairing, bonding, or encryption. Against a peripheral, the peer sends a well-formed LL_CONNECTION_UPDATE_IND with an instant a few connection events in the future (the node is retained and the procedure enters RP_CU_STATE_WAIT_INSTANT), then, before the instant is reached, sends any other LL Control PDU such as LL_LENGTH_REQ. ull_cp_rx() routes that PDU into the active remote Connection Update procedure, which takes the invalid-PDU path. The central role is reachable symmetrically after accepting an LL_CONNECTION_PARAM_REQ, and the local-procedure variant is reachable with LL_REJECT_IND.
With CONFIG_BT_CTLR_ASSERT_DEBUG enabled (its default), the resulting state violates the invariant asserted in llcp_rr_check_done(), so the two-PDU sequence produces an immediate fatal error in the controller. With those asserts disabled, each occurrence permanently loses one node from the controller's small fixed RX pool (sized from CONFIG_BT_CTLR_RX_BUFFERS, which defaults to 1); repeating the sequence across reconnections exhausts the pool, after which the link-layer receive path operates on a NULL node. The impact is an unauthenticated, remotely triggerable denial of service persisting until reboot; there is no memory-disclosure or memory-corruption consequence, since the leaked node simply becomes unreachable. |
