Mardi 13 octobre 2026

Finsys dockhand

Finsys Dockhand before 1.0.45 contains a server-side request forgery vulnerability in the ipCategory() function in src/lib/server/url-safety.ts, which fails to check NAT64, 6to4, and Teredo IPv6 transition ranges. Authenticated attackers can embed loopback, cloud metadata, or private IPv4 addresses in transition IPv6 literals within notification, backup, template, registry, git, or secret provider URLs to reach internal services.

duke-git lancet

Lancet through 2.3.9 contains an SSRF protection bypass vulnerability in netutil.IsInternalIP that misclassifies IPv6 private, link-local, CGNAT and transition addresses as external. Attackers can supply hostnames resolving to these address forms, including NAT64, 6to4 or Teredo embedding internal IPv4, to reach internal services or cloud metadata endpoints.

Grafana Nanogit · Grafana OSS · Grafana Enterprise

A Git server that Grafana's Git Sync (provisioning) is configured to use can exhaust Grafana's memory by returning oversized or highly compressed responses (uncontrolled resource consumption). Exploitation requires an administrator to have configured Git Sync with that server.

Grafana Enterprise · Grafana OSS

A user or service account with read-only access to Git Sync (provisioning) connections can modify a connection's configuration through its status subresource (incorrect authorization). On Grafana 12.4 the affected API is only available when the experimental provisioning feature toggle is enabled.

dromara RuoYi-Vue-Plus

RuoYi-Vue-Plus through 6.0.0 contains an insecure direct object reference vulnerability that allows authenticated users to delete other users' social login bindings by supplying their socialId. Attackers can send DELETE /auth/unlock/{socialId} requests with a victim's binding id to remove their GitHub, WeChat, or Gitee binding and stored OAuth tokens, blocking social login.

Xen

For XSA-308 logic was introduced, as VMX VMEntry checks do not like the exact combination of state which occurs when #DB in intercepted, Single Stepping is active, and blocked by STI/MovSS is active, despite this being a legitimate state to be in. The resulting VMEntry failure is fatal to the guest. Sadly there is another special sub-case of the above, with branch tracing enabled. In that case the prior adjustment would still cause a VMentry failure, as before fatal to the guest.

macrozheng mall

A weakness has been identified in macrozheng mall up to 1.0.3. This vulnerability affects the function OmsPortalOrderServiceImpl of the file /order/generateOrder of the component mall-portal. This manipulation of the argument coupon_amount/pay_amount causes business logic errors. The attack is possible to be carried out remotely. The vendor deleted the GitHub issue for this vulnerability without any explanation.

fail2ban

In fail2ban 0.10.5 through 1.1.1 before ddd879d, the sshd filter (config/filter.d/sshd.conf) accepts an "on <token>" suffix after the host address. Because OpenSSH logs the offered username verbatim, a remote unauthenticated attacker can use a username such as "x VICTIM-SOURCE-IP-ADDRESS on" to make fail2ban associate failed login attempts with an arbitrary source IP address and ban it (e.g., to block logins from a legitimate user). The default filter mode is affected.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab EE affecting all versions from 13.6 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with limited permissions to modify project CI/CD deployment rollback settings without proper authorization, due to insufficient access control checks.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab EE affecting all versions from 16.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user to approve a merge request despite having contributed commits to it, due to improper identity resolution.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an unauthenticated user to read internal notes and confidential system notes on public projects due to improper authorization in the GraphQL API.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.11 before 19.2.8, 19.3 before 19.3.6, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an unauthenticated user to read work item contents from private groups and projects due to incorrect authorization checks.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user holding a project-scoped fine-grained Personal Access Token to modify integrations belonging to a group outside the token's scope, due to incorrect authorization checks.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user controlling a Kubernetes agent to cause sensitive authentication tokens to be sent to an unintended server due to improper redirect validation in the Kubernetes proxy.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 13.8 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with reporter role to access restricted CI artifact report content they were not authorized to, due to missing authorization checks.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 15.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed a user to download package files from a public project due to improper authorization checks.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.4 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an unauthenticated user to read confidential notes on public projects due to incorrect authorization checks.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 17.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with Guest access to read confidential epic content meant to be restricted by external authorization, due to incorrect authorization checks.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 18.11 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with a project-scoped fine-grained Personal Access Token to permanently delete or modify group-level labels, due to incorrect authorization logic on label ownership scope validation.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab EE affecting all versions from 19.1 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user holding a specific granular permission to obtain a GitLab Duo Agent Platform token that bypasses governance controls, due to reliance on untrusted input in a security decision.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab EE affecting all versions from 17.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user holding a custom role with compliance framework administration permissions to configure and execute a specially crafted compliance pipeline across group projects due to improper privilege assignment.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 12.0 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain conditions, could have allowed an authenticated user with access to GitLab Pages log data to obtain access tokens and other secrets, due to insertion of sensitive request data into log files and error tracking events.

GitLab · Gitlab gitlab

GitLab has remediated an issue in GitLab CE/EE affecting all versions from 16.2 before 19.2.8, 19.3 before 19.3.5, and 19.4 before 19.4.2 that, under certain deployment configurations, could have allowed an authenticated user to poison cached page content served to other users due to improper cache key construction.

zephyrproject zephyr

The Bluetooth Mesh Access-layer delayable message queue in subsys/bluetooth/mesh/delayable_msg.c shares three intrusive lists (busy_ctx, free_ctx, free_chunks) and one k_work_delayable between two cooperative threads with no synchronization: bt_mesh_delayable_msg_manage() runs on the Bluetooth host RX thread, while delayable_msg_handler() runs on the system workqueue. Both block while the lists are in an intermediate state — the enqueuer in bt_rand(), both in bt_mesh_access_send() — which lets the other context observe torn state. delayable_msg_handler() used the result of sys_slist_get() on busy_ctx without a NULL check, and allocate_delayable_msg_ctx() tested sys_slist_is_empty() and then assumed a separate sys_slist_get() would succeed. Because CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG and CONFIG_BT_MESH_ACCESS_DELAYABLE_MSG_CTX_ENABLED default to y, every model response to a received mesh message is parked on this queue, so the enqueuer runs as a direct consequence of inbound traffic. A peer that can get access-layer messages accepted by a model (it must hold the NetKey and a bound AppKey, so a legitimate or compromised network member) controls the arrival rate, the size of the elicited responses and the destination address, and thereby controls occupancy of the 4-entry context pool and the 40-entry chunk pool. Exhausting the chunk pool forces bt_mesh_delayable_msg_manage() down the purge path, which sends and releases the only queued message and leaves busy_ctx empty while the delayable work item is still armed; if the enqueuer then yields, the handler runs against the empty list. The result is a read-modify-write through a NULL-based pointer (pending_msg->fired_time += 10) at a fixed low address on the system workqueue thread. On typical targets that faults, aborting the system workqueue thread — which stops all workqueue-driven functionality, including the mesh timing machinery — or resetting the node, so the impact is loss of availability of the affected node. The write value and address are fixed and no attacker-controlled length or index is involved, so this is not exploitable for memory corruption or code execution. The same unsynchronized window also allowed one message context to be selected and released by two contexts at once, producing duplicated transmissions, duplicated send-completion callbacks and crossed chunk ownership. The fix serializes every list mutation with a k_spinlock that is never held across a blocking call, makes push_msg_from_delayable_msgs() detach the queue head atomically so a message being sent is on no list, removes the unchecked sys_slist_get() from delayable_msg_handler(), and drops any message that reaches the front of the queue while the stack is suspended or reset.