Vulnerabilities

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, POST /api/v1/node-custom-function lacks route-level authorization, allowing any authenticated user or API key to submit arbitrary JavaScript to the Custom JS Function node. When E2B_APIKEY is not configured — the common deployment case — Flowise executes this code inside a NodeVM sandbox. This sandbox can be escaped, allowing an attacker to reach the host process object and execute system commands via child_process. The result is authenticated remote code execution on the Flowise server host. This issue has been patched in version 3.1.2.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, when credentials are fetched with a credentialName filter parameter, the encryptedData field is not stripped from the response. The code properly omits encryptedData when no filter is used but fails to do so when a filter is used. This issue has been patched in version 3.1.2.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, all CRUD endpoints for OpenAI Assistants Vector Store have no authentication middleware and the route path /api/v1/openai-assistants-vector-store is not in WHITELIST_URLS. However, it is also not protected by the main auth middleware when accessed via API key — the route requires API key auth (not whitelisted), but no permission checks exist on any operation. This issue has been patched in version 3.1.2.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, assistant create and update mass-assignment allows cross-workspace assistant takeover. This issue has been patched in version 3.1.2.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, CustomTemplate create and update mass-assignment allows cross-workspace template takeover. This issue has been patched in version 3.1.2.

Buffer Over-read vulnerability in Apache HTTP Server via outbound OCSP requests to an attacker controlled OCSP server<br /> <br /> This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.<br /> <br /> Users are recommended to upgrade to version 2.4.68, which fixes the issue.

Out-of-bounds Read vulnerability in Apache HTTP Server with mod_headers and mod_mime and multiple response languages.<br /> <br /> This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.

Improper Privilege Management vulnerability in Apache HTTP Server 2.4.67 and earlier allows local .htaccess authors to read files with the privileges of the httpd user.<br /> <br /> This issue affects Apache HTTP Server: from through 2.4.67.<br /> <br /> Users are recommended to upgrade to version 2.4.68, which fixes the issue.

Loop with Unreachable Exit Condition (&amp;#39;Infinite Loop&amp;#39;) vulnerability in the mod_proxy_ftp module in Apache HTTP Server with an attacker controlled backend FTP server.<br /> <br /> This issue affects undefined: from 2.4.0 through 2.4.67.<br /> <br /> Users are recommended to upgrade to version 2.4.68, which fixes the issue.

Buffer Underwrite vulnerability in Apache HTTP Server on crafted regular expressions in the configuration.<br /> <br /> This issue affects Apache HTTP Server: from 2.4.0 through 2.4.67.<br /> <br /> Users are recommended to upgrade to version 2.4.68, which fixes the issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io-wq: check that the predecessor is hashed in io_wq_remove_pending()<br /> <br /> io_wq_remove_pending() needs to fix up wq-&gt;hash_tail[] if the cancelled<br /> work was the tail of its hash bucket. When doing this, it checks whether<br /> the preceding entry in acct-&gt;work_list has the same hash value, but<br /> never checks that the predecessor is hashed at all. io_get_work_hash()<br /> is simply atomic_read(&amp;work-&gt;flags) &gt;&gt; IO_WQ_HASH_SHIFT, and the hash<br /> bits are never set for non-hashed work, so it returns 0. Thus, when a<br /> hashed bucket-0 work is cancelled while a non-hashed work is its list<br /> predecessor, the check spuriously passes and a pointer to the non-hashed<br /> io_kiocb is stored in wq-&gt;hash_tail[0].<br /> <br /> Because non-hashed work is dequeued via the fast path in<br /> io_get_next_work(), which never touches hash_tail[], the stale pointer<br /> is never cleared. Therefore, after the non-hashed io_kiocb completes and<br /> is freed back to req_cachep, wq-&gt;hash_tail[0] is a dangling pointer. The<br /> io_wq is per-task (tctx-&gt;io_wq) and survives ring open/close, so the<br /> dangling pointer persists for the lifetime of the task; the next hashed<br /> bucket-0 enqueue dereferences it in io_wq_insert_work() and<br /> wq_list_add_after() writes through freed memory.<br /> <br /> Add the missing io_wq_is_hashed() check so a non-hashed predecessor<br /> never inherits a hash_tail[] slot.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: hci_uart: fix UAFs and race conditions in close and init paths<br /> <br /> Vulnerabilities leading to Use-After-Free (UAF) and Null Pointer<br /> Dereference (NPD) conditions were observed in the lifecycle management<br /> of hci_uart.<br /> <br /> The primary issue arises because the workqueues (init_ready and<br /> write_work) are only flushed/cancelled if the HCI_UART_PROTO_READY<br /> flag is set during TTY close. If a hangup occurs before setup completes,<br /> hci_uart_tty_close() skips the teardown of these workqueues and<br /> proceeds to free the `hu` struct. When the scheduled work executes<br /> later, it blindly dereferences the freed `hu` struct.<br /> <br /> Furthermore, several data races and UAFs were identified in the teardown<br /> sequence:<br /> 1. Calling hci_uart_flush() from hci_uart_close() without effectively<br /> disabling write_work causes a race condition where both can concurrently<br /> double-free hu-&gt;tx_skb. This happens because protocol timers can<br /> concurrently invoke hci_uart_tx_wakeup() and requeue write_work.<br /> 2. Calling hci_free_dev(hdev) before hu-&gt;proto-&gt;close(hu) causes a UAF<br /> when vendor specific protocol close callbacks dereference hu-&gt;hdev.<br /> 3. In the initialization error paths, failing to take the proto_lock<br /> write lock before clearing PROTO_READY leads to races with active<br /> readers. Additionally, hci_uart_tty_receive() accesses hu-&gt;hdev<br /> outside the read lock, leading to UAFs if the initialization error<br /> path frees hdev concurrently.<br /> <br /> Fix these synchronization and lifecycle issues by:<br /> 1. Re-ordering hci_uart_tty_close() to clear HCI_UART_PROTO_READY first,<br /> followed immediately by a cancel_work_sync(&amp;hu-&gt;write_work). Clearing<br /> the flag locks out concurrent protocol timers from successfully invoking<br /> hci_uart_tx_wakeup(), effectively rendering the cancellation permanent<br /> and preventing the tx_skb double-free.<br /> 2. Note: Clearing PROTO_READY early causes hci_uart_close() to skip<br /> hu-&gt;proto-&gt;flush(). This is perfectly safe in the tty_close path<br /> because hu-&gt;proto-&gt;close() executes shortly after, which intrinsically<br /> purges all protocol SKB queues and tears down the state.<br /> 3. Relocating hu-&gt;proto-&gt;close(hu) strictly prior to hci_free_dev(hdev)<br /> across all close and error paths to prevent vendor-level UAFs.<br /> 4. Moving the hdev-&gt;stat.byte_rx increment in hci_uart_tty_receive()<br /> inside the proto_lock read-side critical section to safely synchronize<br /> with device unregistration.<br /> 5. Adding cancel_work_sync(&amp;hu-&gt;write_work) to hci_uart_close() to safely<br /> flush the workqueue before hci_uart_flush() is invoked via the HCI core.<br /> 6. Utilizing cancel_work_sync() instead of disable_work_sync() across<br /> all paths to prevent permanently breaking user-space retry capabilities.