| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| SiYuan before v3.8.4 does not HTML-escape stored flashcard block content before interpolating it into the card-manager list markup. Block content returned by /api/riff/getRiffCards is inserted into a card item template in app/src/card/viewCards.ts and assigned to listElement.innerHTML, so content such as <img src=invalid onerror=...> becomes an executable event-handler attribute. Because the SiYuan desktop (Electron) main window is created with nodeIntegration enabled and contextIsolation disabled, an administrator who opens the card manager on a workspace containing attacker-supplied flashcard content (for example introduced through contribution or import) executes the attacker's script in a privileged renderer, which can lead to arbitrary code execution on the host. The affected endpoint remains behind authentication and administrator-role checks; this is an untrusted-content-to-privileged-renderer issue, not an authorization bypass. |
| AVideo contains a stored cross-site scripting vulnerability in the video trailer1 field rendered unsanitized within an inline onclick JavaScript string. Attackers with video upload permission can store HTML entity-encoded payloads that bypass isValidURL() validation and are decoded by the browser to break out of the JavaScript string, executing arbitrary code in any visitor's session including administrators. |
| Flowise (npm packages `flowise` and `flowise-components`) through 3.1.4 looks up credentials by ID without filtering on the requesting user's workspace (findOneBy({ id: credentialId }) with no workspaceId condition) in several code paths: getAllOpenaiAssistants/getSingleOpenaiAssistant (GET /api/v1/openai-assistants and /api/v1/openai-assistants/:id), uploadFilesToAssistant (POST /api/v1/openai-assistants-file/upload/), deleteAssistant (DELETE /api/v1/assistants/:id, reachable by first importing a poisoned assistant row via POST /api/v1/export-import/import), and the shared helper used by getVoices (GET /api/v1/text-to-speech/voices). An authenticated user of one workspace can supply a credential UUID belonging to another workspace, causing the server to decrypt and use that workspace's OpenAI or ElevenLabs API key on the attacker's behalf. No patched version was available at the time of publication. |
| Flowise through 3.1.4 does not enforce authorization on the BullMQ admin dashboard. When the server runs in queue mode with the dashboard enabled and not in cloud mode (MODE=queue, ENABLE_BULLMQ_DASHBOARD=true, and !isCloud()), the /admin/queues mount is protected only by the verifyTokenForBullMQDashboard middleware, which validates the JWT but performs no role, permission, or workspace/organization scoping check; the mount also lies outside /api/v1/* so the global API gate does not apply. As a result, any authenticated user — including the lowest-privileged member of any tenant — can reach the full Bull-Board UI and view all queues and job payloads across the entire instance, including chat inputs and overrideConfig (which may carry credentials and prompts), chatflow.flowData graph definitions with custom function source code, credential IDs and system prompts, chatIds, files, and the originating orgId/workspaceId. The dashboard's write actions (retry, remove, promote, clean) are likewise usable across tenants. No patched version is available as of the advisory. |
| Flowise through 3.1.4 contains missing route-level RBAC checks on chat message endpoints that allow low-privileged API keys to read and delete chat history. Attackers with valid but low-privileged API keys can access GET and DELETE chat message routes without required flow permissions to read chat histories, prompts, model responses, and delete messages. |
| In the Linux kernel, the following vulnerability has been resolved:
ALSA: caiaq: Fix potential double-free at error path
The fix for caiaq driver's resource management to handle the errors
tries to release the resources in a common destructor call, but as a
sashiko review for another patch suggested, some of the audio
resources such as URBs have been already freed, and this may lead to a
double-free.
For addressing the double-free, call the common destructor function
from each place, and assure that the resource pointers get cleared. |
| In the Linux kernel, the following vulnerability has been resolved:
net/rds: acquire RDS_IN_XMIT in rds_tcp_reset_callbacks()
rds_tcp_reset_callbacks() quiesces the transmit path by setting the
path state to RDS_CONN_RESETTING and then waiting for RDS_IN_XMIT to
be sampled clear before swapping the underlying socket and calling
rds_send_path_reset().
Sampling the bit clear is not the same as owning it: rds_send_xmit()
can re-acquire RDS_IN_XMIT right after the wait_event() returns. Its
state recheck after taking the lock is a store-buffering pattern (the
resetter writes the state and reads the bit, the sender writes the
bit and reads the state) and acquire_in_xmit() is only an acquire
operation, so on weakly ordered architectures both sides can miss
each other's write and the transmit path then runs concurrently with
rds_send_path_reset() rewriting cp_xmit_* state - which is exactly
what the comment above rds_send_path_reset() tells its callers to
prevent.
Take the lock instead, hold it across the socket swap and
rds_send_path_reset(), and release it with a wake-up at the end. The
lock-ordering constraint documented above the wait still holds: the
lock is acquired before lock_sock(), so a sender inside tcp_sendmsg()
can never be waited on while we hold the socket lock.
Two details of the old code go away with the same change:
- t_sock is now read only after the lock is acquired. The old code
cached it before waiting; the teardown in rds_conn_shutdown()
releases that socket and clears t_sock, so a pointer cached before
the wait can be stale by the time the accept path resumes. Reading
it under RDS_IN_XMIT is what makes the exclusion complete once the
teardown owns the same lock, which the next patch arranges; until
then the teardown still only samples the bit, and the two paths
remain as exposed to each other as they are today.
- The old !osock early path called rds_send_path_reset() with no
serialization at all. It now runs under the lock like the normal
path. The conditional RDS_CONN_RESETTING transition of the
previous patch happens before the socket check either way: a path
found without a socket is either still connecting (its reconnect
worker blocked on t_conn_path_lock) and legitimately goes
RESETTING -> UP on the new socket, or it has been torn down
meanwhile and is dropped.
The in-function comment describing the old wait-based quiesce is
rewritten to describe the lock-based one, and the stale block comment
above the function (which still described a return value and an
incomplete list of t_sock writers) is refreshed to name all four
writers - the connect, accept, teardown and swap paths - and what
serializes each of them. |
| In the Linux kernel, the following vulnerability has been resolved:
bonding: do not clear curr_active_slave prematurely when releasing all slaves
When releasing all slaves during bond destruction (all == true),
__bond_release_one() unconditionally clears bond->curr_active_slave to
NULL in every iteration.
If a backup slave is released before the active slave,
bond_alb_deinit_slave() triggers rlb_teach_disabled_mac_on_primary(),
which increments the active slave dev promiscuity counter and sets
bond_info->primary_is_promisc = 1.
Because bond->curr_active_slave was prematurely cleared to NULL when
releasing the backup slave, the subsequent iteration releasing the active
slave evaluates oldcurrent as NULL, so bond_change_active_slave(bond, NULL)
is skipped. Consequently, bond_alb_handle_active_change() is never called
to decrement the promiscuity counter, permanently leaking promiscuous
mode on the physical device after bond teardown.
When oldcurrent == slave, bond_change_active_slave(bond, NULL) already sets
bond->curr_active_slave to NULL. We only need to avoid selecting a new
active slave when all == true. Replace the if (all) branch with
if (!all && oldcurrent == slave). |
| The AIL Framework (ail-project/ail-framework) contains a stored cross-site scripting (XSS) vulnerability in two Jinja2 templates that render popovers for matched, tracked, or tagged content: var/www/templates/chats_explorer/block_message.html and var/www/templates/objects/item/show_item.html. In both templates, dynamic values associated with this content, including icon color, icon style, icon glyph, subtype, identifier, name, description, and matched value, are interpolated directly into the data-content HTML attribute of Bootstrap popover elements without appropriate output encoding. Because the popovers are configured with data-html="true", the content is interpreted as HTML in the victim's browser. An authenticated attacker who can influence matched, tracked, or tagged content may inject arbitrary HTML or JavaScript into these values. When a victim displays the affected popover, the injected markup may execute in the victim's session, potentially enabling data exfiltration or actions with the victim's privileges. The vulnerability is classified as stored XSS because the malicious payload can persist in the affected match, tracking, or tag-related data and be delivered to users who view the affected content. |
| The AIL Framework crawler splash domain page (showDomain.html) is vulnerable to stored cross-site script injection (XSS). User-supplied data originating from imported crawler captures—specifically item IDs, URLs, and screenshot file paths—was interpolated directly into inline JavaScript contexts within the HTML template. This included an onclick attribute that embedded raw screenshot and URL values into a JavaScript function call, and an inline script block that assigned a screenshot value to a JavaScript variable without escaping. An attacker with a user-role API client could craft a malicious crawler capture import containing JavaScript payloads in these fields. When any user (including privileged users) subsequently viewed the affected domain page, the injected script would execute in the victim's browser context, potentially allowing session hijacking, data exfiltration, or unauthorized actions on behalf of the victim. The vulnerability is stored in the application's data layer and triggered upon page rendering, requiring no further interaction beyond loading the domain view. |
| Improper Exposure of Resource to Wrong Sphere in the host file helper (gofer) in Google gVisor prior to commit 573a9e73cf844f on Linux platforms with CUSE enabled allows a local attacker with container image deployment privileges to achieve root code execution on the host system. By including a /dev/cuse character device node in a container image, opening the device passes through to the host, allowing the sandboxed attacker to register a host device and exploit CUSE unrestricted ioctl handling to overwrite root udev helper memory. |
| A vulnerability has been found in Zhonglun CloudPos up to 3.0.1.76. This issue affects the function OpenLocalBrowser of the file ZlPos/ZlPos/Bizlogic/JSBridge.cs of the component JSBridge. Such manipulation of the argument url leads to code injection. The attack can be executed remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. |
| BerriAI LiteLLM before 1.101.0-rc.1 contains a tenant isolation bypass vulnerability in the semantic cache layer that allows authenticated users to read other tenants' cached responses by exploiting a metadata key mismatch between _get_semantic_cache_tenant_scope() and _get_metadata_variable_name(). Attackers holding a valid virtual key can submit semantically similar prompts on affected routes such as /v1/responses and /bedrock/* to retrieve cached responses containing other tenants' personally identifiable information, financial data, or source code, and can cause agentic front-ends to auto-execute attacker-supplied tool calls under victim credentials by returning cached function_call or tool_calls payloads to a different principal. |
| In the Linux kernel, the following vulnerability has been resolved:
sctp: fix soft lockup from unpadded ASCONF-ACK parameter iteration
sctp_verify_asconf() walks ASCONF-ACK parameters with
sctp_walk_params(), which advances by SCTP_PAD4(length), while the
consumer sctp_get_asconf_response() iterates the same parameters
advancing by the raw length, without padding. A single odd-length
parameter desynchronises the two walks and makes the consumer
interpret attacker-controlled bytes at a misaligned offset.
When those bytes yield a length of zero, the while loop over
asconf_ack_len makes no progress, spinning forever in softirq
context, and the watchdog reports a soft lockup. All reads stay
within the received skb, so the lockup is a pure remote denial of
service. A remote peer can trigger it with a crafted ASCONF-ACK on
an ADD-IP enabled association with an outstanding ASCONF (RFC 5061
section 4.1.2 requires the chunk to be authenticated, but the
predefined empty key id 0 allows the peer to compute the same
association HMAC from publicly exchanged parameters, so the gate
does not help).
The SCTP_PARAM_ERR_CAUSE case of sctp_verify_asconf() also performs
no length check, letting a parameter without a complete error
header reach the consumer, which reads errhdr.cause past the end of
the parameter, an out-of-bounds read.
Reject SCTP_PARAM_ERR_CAUSE parameters shorter than
sizeof(struct sctp_addip_param) + sizeof(struct sctp_errhdr) at the
verifier, and advance the consumer iterator with the same padding
rule as the verifier to keep the two walks in lockstep. The verifier
change guarantees a complete error header in every ERR_CAUSE
parameter the consumer can see, so the consumer's asconf_ack_len
check is dropped and it returns err_param->cause directly. The
consumer padding fix is still required because odd lengths remain
valid for SCTP_PARAM_ERR_CAUSE per RFC 5061.
The issue was found by ZeroHive, a vulnerability hunting agent at
Tencent Yunding Lab. |
| Improper Neutralization of Special Elements in Output Used by a Downstream Component in the colour control escape code handler in kitty from 0.47.3 before 0.49.0 allows a program writing to the terminal to execute an arbitrary command in the user's shell, because color_control() in kitty/window.py answers a query for an unrecognised field name by placing that field name into the reply, and write_escape_code_to_child() in kitty/screen.c then writes the reply to the pseudoterminal master, where it is not distinguishable from input typed by the user, without neutralising it for the shell that reads it. The payload is reduced to printable ASCII before the field name is echoed, which is the restriction introduced in 0.47.3 as the fix for CVE-2026-54057, and the record and field separators ; and = are consumed as delimiters, but every other printable character survives, which is sufficient to compose a shell command. A newline is available from handle_remote_ssh() in kitty/window.py, which writes the bytes yielded by get_ssh_data() in kittens/ssh/utils.py, the first of which begin with a newline, to the pseudoterminal master before any credential carried in the request is checked. The reply is framed as an OSC sequence carrying the escape code number, the field name, and the literal value ?. This results in execution of an attacker-chosen command with the privileges of the user running the terminal. |
| A vulnerability was detected in mathurvishal CloudClassroom-PHP-Project up to 5dadec098bfbbf3300d60c3494db3fb95b66e7be. Affected is an unknown function of the file mydetailsfaculty.php. The manipulation of the argument myfid results in sql injection. The attack can be launched remotely. The exploit is now public and may be used. This product does not use versioning. This is why information about affected and unaffected releases are unavailable. The vendor was contacted early about this disclosure but did not respond in any way. |
| In the Linux kernel, the following vulnerability has been resolved:
staging: rtl8723bs: fix mismatched free of HalData in rtw_sdio_if1_init()
padapter->HalData is allocated via vzalloc(), but incorrectly freed
using kfree() in the rtw_sdio_if1_init() error path. Using kfree() to
release this vmalloc-backed buffer can lead to memory corruption.
Use rtw_hal_data_deinit() to pair the free correctly and free
HalData with vfree().
The bug was first flagged by an experimental static analysis tool we
are developing for kernel memory-management bugs. Manual inspection
confirms that the issue is still present in current mainline.
An x86_64 allyesconfig build showed no new warnings. As we do not have
suitable RTL8723BS SDIO hardware to test with, no runtime testing was
able to be performed. |
| In the Linux kernel, the following vulnerability has been resolved:
smb/server: fix tree connection leak in smb2_tree_connect()
See the procedure below:
smb2_tree_connect
ksmbd_tree_conn_connect
xa_store(&sess->tree_conns, tree_conn->id, tree_conn)
ksmbd_counter_inc(KSMBD_COUNTER_TREE_CONNS)
ksmbd_share_tree_conn_inc(sc)
ksmbd_iov_pin_rsp // fail
status.ret = KSMBD_TREE_CONN_STATUS_NOMEM
// do not disconnect tree_conn
Disconnect the new tree connection if ksmbd_iov_pin_rsp() fails. |
| Improper Link Resolution Before File Access in the drag source staging path of the drag and drop protocol in kitty from 0.47.0 before 0.49.0 allows a program writing to the terminal to create files and directories at paths outside the staging directory, because subdir_data_for_drag() in kitty/dnd.c resolves a descendant of the staged item tree by constructing a path string and opening it with safe_open(path, O_DIRECTORY | O_RDONLY, 0) rather than by walking the tree one component at a time, so a client that declares two entries with the same name, the first a symlink whose target is an arbitrary absolute path and the second a directory, causes mkdirat() to fail with EEXIST, which the code ignores, and causes the subsequent path resolution to follow the symlink and return a directory descriptor outside the staging directory, which is then passed as the dirfd argument to add_payload() and used for every further create operation on that item and its descendants. Entry names are sanitised against path separators and dot components, but symlink targets are not validated. Files are created with O_CREAT | O_WRONLY | O_EXCL at mode 0644, so existing files cannot be overwritten, and directories are created with mkdirat() at mode 0755, so the attacker can create intermediate directories that did not previously exist. This results in the creation of files and directories at any path writable by the user running kitty, provided the symlink target is an existing directory. |
| The AIL Framework tag selector component (var/www/static/js/tags.js) is vulnerable to stored cross-site scripting (XSS). A user with the ability to create a custom tag could embed an HTML payload containing JavaScript event handlers (e.g., <img src=x onerror=alert(1)> or <svg onload=...>) in the tag name. When another authenticated user opened a page containing the tag selector, the malicious tag name was inserted into the DOM using jQuery's html property, causing the embedded script to execute in the victim's browser context.
The vulnerable code paths affected both the suggestion/combo-item rendering (_renderComboItems) and the selected-tag rendering logic. In both cases, the display value derived from the tag's displayField was passed directly to the html property of a jQuery element constructor, which parses and inserts the string as raw HTML rather than as text.
Preconditions: the attacker must have an authenticated account with permission to create custom tags, and the victim must be an authenticated user who views a page that renders the tag selector with the attacker's stored tag. The attack is stored (persistent) and does not require the victim to perform any action beyond loading the page.
Security impact: successful exploitation allows arbitrary JavaScript execution in the victim's browser within the application's origin, potentially leading to session hijacking, unauthorized data access, form manipulation, or further client-side attacks. |
