| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A vulnerability was determined in EFM ipTIME AX8004M 15.09.0. Impacted is the function popen of the file /cgi/d.cgi of the component CGI Endpoint. This manipulation of the argument fname causes os command injection. The attack can be initiated remotely. The exploit has been publicly disclosed and may be utilized. The vendor was contacted early about this disclosure but did not respond in any way. |
| A vulnerability was found in code-projects Task Management System 1.0. This issue affects some unknown processing of the file /user/CommentSave.php. The manipulation of the argument comment/task_id/mineId/recId/myName/myImage results in cross site scripting. It is possible to launch the attack remotely. The exploit has been made public and could be used. |
| A vulnerability has been found in Uasoft Badaso 3.0.0-alpha. This vulnerability affects the function ApiRequest::class of the file src/Routes/api.php of the component File API. The manipulation leads to permission issues. It is possible to initiate the attack remotely. The exploit has been disclosed to the public and may be used. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability was detected in dmitriiweb article-scraper-mcp 1.0.0. This vulnerability affects the function fetch_article of the file news_scraper_mcp/server.py. The manipulation of the argument url results in server-side request forgery. The attack may be performed from remote. The exploit is now public and may be used. The project was informed of the problem early through an issue report but has not responded yet. |
| A security vulnerability has been detected in adafap api-mcp up to 92b9a5d04acfec165c7d4ef852496593aa87be06. This affects the function customAxios of the file app/api/proxy/route.ts of the component Proxy API Endpoint. The manipulation of the argument url leads to server-side request forgery. The attack is possible to be carried out remotely. This product adopts a rolling release strategy to maintain continuous delivery. Therefore, version details for affected or updated releases cannot be specified. The project was informed of the problem early through an issue report but has not responded yet. |
| A weakness has been identified in PhialsBasement KoboldCPP-MCP-Server 1.0.0. Affected by this issue is the function makeRequest of the file src/index.ts of the component BaseConfigSchema. Executing a manipulation of the argument apiUrl can lead to server-side request forgery. It is possible to launch the attack on the local host. The project was informed of the problem early through an issue report but has not responded yet. |
| A security flaw has been discovered in Handwriting-OCR handwriting-ocr-mcp-server 0.1.0. Affected by this vulnerability is the function fs.readFileSync of the file src/index.ts of the component upload_document. Performing a manipulation of the argument File results in path traversal. Attacking locally is a requirement. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability was identified in Nikolaibibo claude-comfyui-mcp 1.0.0. Affected is the function copyFileSync of the file src/tools/utils.ts of the component comfy_upload_image. Such manipulation of the argument image_path leads to path traversal. An attack has to be approached locally. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability was determined in bartekke8it56w2 new-mcp 0.1.0. This impacts the function fs.writeFileSync/fs.existsSync/fs.readFileSync of the file index.ts of the component geminithinking. This manipulation of the argument sessionCommand/sessionPath causes path traversal. The attack requires local access. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability was found in KS-GEN-AI jira-mcp-server 0.2.0. This affects the function axios.get of the file src/index.ts of the component add_attachment_from_public_url. The manipulation of the argument imageUrl results in server-side request forgery. The attack requires a local approach. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability was found in PV-Bhat gemsuite-mcp 1.0.0. Affected by this issue is some unknown functionality of the file src/handlers/unified-gemini.ts of the component gemini_search/gemini_reason/gemini_process/gemini_analyze. The manipulation of the argument file_path/file_paths results in path traversal. The attack must be initiated from a local position. The project was informed of the problem early through an issue report but has not responded yet. |
| A vulnerability has been found in NocteDefensor LudusMCP 1.0.24. Affected by this vulnerability is an unknown functionality of the file src/tools/rangeConfig.ts of the component read_range_config. The manipulation of the argument Source leads to server-side request forgery. The attack may be initiated remotely. The project was informed of the problem early through an issue report but has not responded yet. |
| A flaw has been found in NocteDefensor LudusMCP up to 1.0.24. Affected is an unknown function of the file src/tools/insertCredsRangeConfig.ts of the component insert_creds_range_config. Executing a manipulation of the argument configPath/outputPath can lead to path traversal. The attack is restricted to local execution. The project was informed of the problem early through an issue report but has not responded yet. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: drain bus_reset work on device removal
brcmf_fw_crashed() and the debugfs "reset" entry both schedule
drvr->bus_reset, whose callback recovers drvr through container_of()
and dereferences it. The removal path frees drvr (brcmf_free ->
wiphy_free) without draining the work, so a bus_reset callback pending
or running during removal can outlive drvr.
Cancellation cannot live in brcmf_detach() or brcmf_free(): the work
callback reaches teardown through the bus .reset op (PCIe
brcmf_pcie_reset -> brcmf_detach; SDIO brcmf_sdio_bus_reset ->
brcmf_sdiod_remove -> brcmf_free), so cancelling there would wait for
the running work and deadlock.
Add a per-bus mutex (bus_reset_lock) and route all arming through
brcmf_bus_schedule_reset(), which under the lock skips when the bus is
marked removing. Each bus remove entry calls
brcmf_bus_cancel_reset_work(), which under the same lock sets removing
and cancels the work. Holding the mutex across cancel_work_sync() makes
the set-removing + drain step atomic. Every producer reaches the arming
path from process context -- the PCIe firmware-halt notification runs in
the threaded IRQ handler (brcmf_pcie_isr_thread) and the SDIO hostmail
path runs from the data workqueue -- so the mutex is taken only in
sleepable contexts. Where applicable the remove entry first stops the
firmware-crash producer: on PCIe mask the mailbox and synchronize_irq;
on SDIO unregister the bus interrupt and cancel the data worker, which
also reports firmware halts through brcmf_fw_crashed(). The mutex is
initialized at bus allocation. The SDIO suspend power-off path frees
drvr through the same brcmf_sdiod_remove() and takes the same lock;
resume re-allows the work only on a successful re-probe.
Also guard brcmf_fw_crashed() against a NULL bus_if/drvr: it can fire
before brcmf_attach() wires up drvr, and it dereferences drvr
(bphy_err/brcmf_dev_coredump) before reaching the arming gate.
The bus_reset work is shared across buses, so the drain is applied to
every remove path: PCIe (the .reset op introduced by the Fixes commit),
SDIO (arms the same work through brcmf_fw_crashed()), and USB (via the
debugfs "reset" entry). cancel_work_sync() drains a running or pending
bus_reset work item before removal frees drvr, and patch 1/2 makes the
scratch-buffer release safe when reset teardown has already released
those DMA buffers.
This patch fixes the lifetime of the bus_reset work item itself. It does
not attempt to address the separate, pre-existing lifetime of the
asynchronous firmware completion started by the PCIe reset path. That
callback needs its own lifetime/ownership protocol and is being tracked
separately.
This issue was found by an in-house static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
rhashtable: clear stale iter->p on table restart
rhashtable_walk_start_check() has two restart paths when resuming a walk.
When iter->walker.tbl is valid, it re-validates iter->p against the table
and sets iter->p = NULL if the object is gone. When iter->walker.tbl is
NULL (table was freed during resize), it resets slot and skip but forgets
to clear iter->p.
rhashtable_walk_next() then dereferences the stale iter->p, reading
freed memory. This is a use-after-free.
Any caller that does multi-fragment rhashtable walks across
walk_stop/walk_start boundaries is affected. Concrete cases include
netlink_diag (__netlink_diag_dump in net/netlink/diag.c) and TIPC
(tipc_nl_sk_walk in net/tipc/socket.c).
Crash stack (netlink_diag):
BUG: KASAN: slab-use-after-free in rhashtable_walk_next+0x365/0x3c0
Read of size 8 at addr ffff88801a9d2438 (freed kmalloc-2k, offset 1080)
Call Trace:
rhashtable_walk_next+0x365/0x3c0 (lib/rhashtable.c:1016)
__netlink_diag_dump+0x160/0x760 (net/netlink/diag.c:122)
netlink_diag_dump+0xc2/0x240
netlink_dump+0x5bc/0x1270
netlink_recvmsg+0x7a3/0x980
sock_recvmsg+0x1bc/0x200
__sys_recvfrom+0x1d4/0x2c0 |
| In the Linux kernel, the following vulnerability has been resolved:
net/handshake: Take a long-lived file reference at submit
handshake_nl_accept_doit() needs the file pointer backing
req->hr_sk->sk_socket to survive the window between
handshake_req_next() and the subsequent FD_PREPARE() and get_file().
The submit-side sock_hold() does not provide that. sk_refcnt keeps
struct sock alive, but struct socket is owned by sock->file: when
the consumer fputs the last file reference, sock_release() tears
the socket down regardless of any sock_hold.
Add an hr_file pointer to struct handshake_req and acquire an
explicit reference on sock->file during handshake_req_submit().
handshake_complete() and handshake_req_cancel() release the
reference on the completion-bit-winning path.
The submit error path must also release the file reference, but
after rhashtable insertion a concurrent handshake_req_cancel() can
discover the request and race the error path. Gate the error-path
cleanup -- sk_destruct restoration, fput, and request destruction
-- with test_and_set_bit(HANDSHAKE_F_REQ_COMPLETED), the same
serialization handshake_complete() and handshake_req_cancel()
already use. When cancel has already claimed ownership, the submit
error path returns without touching the request; socket teardown
handles final destruction.
The accept-side dereferences are not yet retargeted; that change
comes in the next patch. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: logitech-dj: Fix maxfield check in DJ short report validation
Commit b6a57912854e ("HID: logitech-dj: Prevent REPORT_ID_DJ_SHORT
related user initiated OOB write") added validation for the DJ short
output report, but the error path dereferences rep->field[0] even when
rep->maxfield is zero.
Commit 8b9a097eb2fc ("HID: logitech-dj: fix wrong detection of bad
DJ_SHORT output report") made the check conditional on rep being present,
but a crafted descriptor can still create report ID 0x20 with only padding
output items. hid-core registers the report, ignores the padding field,
and leaves rep->maxfield as zero.
In that case the validation enters the rep->maxfield < 1 branch and then
dereferences rep->field[0]->report_count while printing the error message,
causing a NULL pointer dereference during probe. This is reproducible with
uhid by emulating a Logitech receiver with a padding-only DJ short output
report:
BUG: KASAN: null-ptr-deref in logi_dj_probe+0xb1/0x754 [hid_logitech_dj]
Read of size 4 at addr 0000000000000028 by task kworker/4:1/129
...
Call Trace:
logi_dj_probe+0xb1/0x754 [hid_logitech_dj]
hid_device_probe+0x329/0x3f0 [hid]
really_probe+0x162/0x570
__device_attach+0x137/0x2c0
bus_probe_device+0x38/0xc0
device_add+0xa56/0xce0
hid_add_device+0x19c/0x280 [hid]
uhid_device_add_worker+0x2c/0xb0 [uhid]
Reject the zero-field report before printing the field report_count. |
| In the Linux kernel, the following vulnerability has been resolved:
net/handshake: hand off the pinned file reference to accept_doit
handshake_req_next() removes the request from the per-net
pending list and drops hn_lock before handshake_nl_accept_doit()
reads req->hr_sk->sk_socket and dereferences sock->file (once in
FD_PREPARE() and again in get_file()). In that window a
consumer running tls_handshake_cancel() followed by sockfd_put()
(svc_sock_free) or __fput_sync() (xs_reset_transport) releases
sock->file. sock_release() then runs sock_orphan(), zeroing
sk_socket, and frees the struct socket. The accept-side code
either reads NULL through sk_socket or chases freed memory.
The submit-side sock_hold() does not prevent this. sk_refcnt
protects struct sock, but struct socket and sock->file are
independently refcounted via the file descriptor the consumer
owns. Pinning sk leaves sock and sock->file unprotected.
Retarget the accept-side dereferences at req->hr_file, which was
pinned at submit time, instead of req->hr_sk->sk_socket->file.
Pinning on its own is not sufficient: a consumer that cancels
between handshake_req_next() returning and accept_doit reaching
FD_PREPARE() takes the !remove_pending() branch in
handshake_req_cancel() and drops hr_file before the accept side
takes its own reference. Hand off an additional file reference
inside handshake_req_next(), under hn_lock, so the accept side
operates on a reference that no concurrent handshake_req_cancel()
can revoke. FD_PREPARE() consumes that handed-off reference,
either by transferring it to the new fd in fd_publish() or by
dropping it in the cleanup destructor on error; the explicit
get_file() that previously balanced FD_PREPARE() is therefore
redundant and goes away.
Update handshake_req_cancel_test2 and _test3 to simulate the
FD_PREPARE() consumption with an fput() so the kunit file-count
assertions stay balanced. |
| In the Linux kernel, the following vulnerability has been resolved:
net/handshake: Drain pending requests at net namespace exit
The arguments to list_splice_init() in handshake_net_exit() are
reversed. The call moves the local empty "requests" list onto
hn->hn_requests, leaving the local list empty, so the subsequent
drain loop runs zero iterations. Pending handshake requests that
had not yet been accepted are not torn down when the net namespace
is destroyed; each one keeps a reference on a socket file and on
the handshake_req allocation.
Pass the source and destination in the documented order
(list_splice_init(list, head) moves list onto head) so the pending
list is transferred to the local scratch list and drained through
handshake_complete().
Fixing the splice direction exposes a list-corruption race. After
the splice each req->hr_list still has non-empty link pointers,
threading the stack-local scratch list rather than hn_requests.
A concurrent handshake_req_cancel() -- for example, from sunrpc's
TLS timeout on a kernel socket whose netns reference was not
taken -- finds the request through the rhashtable, calls
remove_pending(), and sees !list_empty(&req->hr_list).
__remove_pending_locked() then list_del_init()s an entry off the
scratch list while the drain iterates, corrupting it. The same
call arriving after the drain loop has run list_del() on an
entry hits LIST_POISON instead.
Have remove_pending() check HANDSHAKE_F_NET_DRAINING under
hn_lock and report not-found when drain is in progress. The
drain has already taken ownership; handshake_complete()'s existing
test_and_set on HANDSHAKE_F_REQ_COMPLETED still arbitrates
between drain and cancel for who calls the consumer's hp_done. Use
list_del_init() rather than list_del() in the drain so req->hr_list
does not carry LIST_POISON after drain releases the entry.
The DRAINING guard in remove_pending() makes cancel return false,
but cancel still falls through to test_and_set_bit on
HANDSHAKE_F_REQ_COMPLETED and drops the request's hr_file reference.
Without another pin, if that is the last reference, sk_destruct frees
the request while it is still linked on the drain loop's local list.
Pin each request's hr_file under hn_lock before releasing the list,
and drop that drain pin after the loop finishes with the request. |
| In the Linux kernel, the following vulnerability has been resolved:
netconsole: avoid OOB reads, msg is not nul-terminated
msg passed to netconsole from the console subsystem is not guaranteed
to be nul-terminated. Before recent
commit 7eab73b18630 ("netconsole: convert to NBCON console infrastructure")
the message would be placed in printk_shared_pbufs, a static global
buffer, so KASAN had harder time catching OOB accesses. Now we see:
printk: console [netcon_ext0] enabled
BUG: KASAN: slab-out-of-bounds in string+0x1f7/0x240
Read of size 1 at addr ffff88813b6d4c00 by task pr/netcon_ext0/594
CPU: 65 UID: 0 PID: 594 Comm: pr/netcon_ext0 Not tainted 6.19.0-11754-g4246fd6547c9
Call Trace:
kasan_report+0xe4/0x120
string+0x1f7/0x240
vsnprintf+0x655/0xba0
scnprintf+0xba/0x120
netconsole_write+0x3fe/0xa10
nbcon_emit_next_record+0x46e/0x860
nbcon_kthread_func+0x623/0x750
Allocated by task 1:
nbcon_alloc+0x1ea/0x450
register_console+0x26b/0xe10
init_netconsole+0xbb0/0xda0
The buggy address belongs to the object at ffff88813b6d4000
which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 0 bytes to the right of
allocated 3072-byte region [ffff88813b6d4000, ffff88813b6d4c00) |
