| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| spimsimulator spim v9.1.24 and before is vulnerable to Buffer Overflow in the READ_SYSCALL and WRITE_SYSCALL system calls. The application verifies the legitimacy of the starting and ending addresses for memory read/write operations. By configuring the starting and ending addresses for memory read/write to point to distinct memory segments within the virtual machine, it is possible to circumvent these checks. |
| A Server-Side Request Forgery (SSRF) vulnerability has been identified in the embedded web server in various Lexmark devices. This vulnerability can be leveraged by an attacker to force the device to send an arbitrary HTTP request to a third-party server. Successful exploitation of this vulnerability can lead to internal network access / potential data disclosure from a device. |
| Meitrack T366G-L GPS Tracker devices contain an SPI flash chip (Winbond 25Q64JVSIQ) that is accessible without authentication or tamper protection. An attacker with physical access to the device can use a standard SPI programmer to extract the firmware using flashrom. This results in exposure of sensitive configuration data such as APN credentials, backend server information, and network parameter |
| When Memos 0.22 is configured to store objects locally, an attacker can create a file via the CreateResource endpoint containing a path traversal sequence in the name, allowing arbitrary file write on the server. |
| Memos 0.22 is vulnerable to Stored Cross site scripting (XSS) vulnerabilities by the upload attachment and user avatar features. Memos does not verify the content type of the uploaded data and serve it back as is. An authenticated attacker can use this to elevate their privileges when the stored XSS is viewed by an admin. |
| A vulnerability in the web-based management interface of Cisco Evolved Programmable Network Manager (EPNM) and Cisco Prime Infrastructure could allow an authenticated, remote attacker to conduct a stored cross-site scripting (XSS) attack against users of the interface of an affected system.
This vulnerability exists because the web-based management interface does not properly validate user-supplied input. An attacker could exploit this vulnerability by inserting malicious code into specific data fields in the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. To exploit this vulnerability, an attacker must have valid administrative credentials. |
| A vulnerability in the web-based management interface of Cisco Evolved Programmable Network Manager (EPNM) and Cisco Prime Infrastructure could allow an authenticated, remote attacker to obtain sensitive information from an affected system.
This vulnerability is due to improper validation of requests to API endpoints. An attacker could exploit this vulnerability by sending a valid request to a specific API endpoint within the affected system. A successful exploit could allow a low-privileged user to view sensitive configuration information on the affected system that should be restricted. To exploit this vulnerability, an attacker must have access as a low-privileged user. |
| Element Plus Link component (el-link) through 2.10.6 implements insufficient input validation for the href attribute, creating a security abstraction gap that obscures URL-based attack vectors. The component passes user-controlled href values directly to underlying anchor elements without protocol validation, URL sanitization, or security headers. This allows attackers to inject malicious URLs using dangerous protocols (javascript:, data:, file:) or redirect users to external malicious sites. While native HTML anchor elements present similar risks, UI component libraries bear additional responsibility for implementing security safeguards and providing clear risk documentation. The vulnerability enables XSS attacks, phishing campaigns, and open redirect exploits affecting applications that use Element Plus Link components with user-controlled or untrusted URL inputs. |
| Tenda W30E V16.01.0.19 (5037) was discovered to contain a stack overflow in the v17 parameter in the UploadCfg function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| A security issue has been identified in Appian Enterprise Business Process Management version 25.3. The vulnerability is related to incorrect access control, which under certain conditions could allow unauthorized access to information. NOTE: this has been disputed because the CVE Record information does not originate from the Supplier, and the report lacks specificity about why a problem exists, how the behavior could be reproduced, and whether any action could be taken to resolve the problem. |
| OPSI before 4.3 allows any client to retrieve any ProductPropertyState, including those of other clients. This can lead to privilege escalation if any ProductPropertyState contains a secret only intended to be accessible by a subset of clients. One example of this is a domain join account password for the windomain package. |
| A vulnerability in the web-based management interface of Cisco Evolved Programmable Network Manager (EPNM) could allow an authenticated, remote attacker to upload arbitrary files to an affected device.
This vulnerability is due to improper validation of files that are uploaded to the web-based management interface. An attacker could exploit this vulnerability by sending a crafted file upload request to a specific API endpoint. A successful exploit could allow the attacker to upload arbitrary files to an affected system. To exploit this vulnerability, an attacker must have at least valid Config Managers credentials on the affected device. |
| A vulnerability in Cisco Webex Meetings could have allowed an unauthenticated, remote attacker to redirect a targeted Webex Meetings user to an untrusted website. Cisco has addressed this vulnerability in the Cisco Webex Meetings service, and no customer action is needed.
This vulnerability existed because of insufficient validation of URLs that were included in a meeting-join URL. Prior to this vulnerability being addressed, an attacker could have exploited this vulnerability by including a URL to a website of their choosing in a specific value of a Cisco Webex Meetings join URL. A successful exploit could have allowed the attacker to redirect a targeted user to a website that was controlled by the attacker, possibly making the user more likely to believe the website was trusted by Webex and perform additional actions as part of phishing attacks. |
| A weakness has been identified in itsourcecode POS Point of Sale System 1.0. Impacted is an unknown function of the file /inventory/main/vendors/datatables/unit_testing/templates/dom_data_th.php. This manipulation of the argument scripts causes cross site scripting. The attack is possible to be carried out remotely. The exploit has been made available to the public and could be exploited. |
| A security vulnerability has been detected in itsourcecode POS Point of Sale System 1.0. The affected element is an unknown function of the file /inventory/main/vendors/datatables/unit_testing/templates/dymanic_table.php. Such manipulation of the argument scripts leads to cross site scripting. The attack may be performed from remote. The exploit has been disclosed publicly and may be used. |
| In the Linux kernel, the following vulnerability has been resolved:
HID: core: Harden s32ton() against conversion to 0 bits
Testing by the syzbot fuzzer showed that the HID core gets a
shift-out-of-bounds exception when it tries to convert a 32-bit
quantity to a 0-bit quantity. Ideally this should never occur, but
there are buggy devices and some might have a report field with size
set to zero; we shouldn't reject the report or the device just because
of that.
Instead, harden the s32ton() routine so that it returns a reasonable
result instead of crashing when it is called with the number of bits
set to 0 -- the same as what snto32() does. |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix oob access in cgroup local storage
Lonial reported that an out-of-bounds access in cgroup local storage
can be crafted via tail calls. Given two programs each utilizing a
cgroup local storage with a different value size, and one program
doing a tail call into the other. The verifier will validate each of
the indivial programs just fine. However, in the runtime context
the bpf_cg_run_ctx holds an bpf_prog_array_item which contains the
BPF program as well as any cgroup local storage flavor the program
uses. Helpers such as bpf_get_local_storage() pick this up from the
runtime context:
ctx = container_of(current->bpf_ctx, struct bpf_cg_run_ctx, run_ctx);
storage = ctx->prog_item->cgroup_storage[stype];
if (stype == BPF_CGROUP_STORAGE_SHARED)
ptr = &READ_ONCE(storage->buf)->data[0];
else
ptr = this_cpu_ptr(storage->percpu_buf);
For the second program which was called from the originally attached
one, this means bpf_get_local_storage() will pick up the former
program's map, not its own. With mismatching sizes, this can result
in an unintended out-of-bounds access.
To fix this issue, we need to extend bpf_map_owner with an array of
storage_cookie[] to match on i) the exact maps from the original
program if the second program was using bpf_get_local_storage(), or
ii) allow the tail call combination if the second program was not
using any of the cgroup local storage maps. |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU
syzbot reports that defer/local task_work adding via msg_ring can hit
a request that has been freed:
CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
Call Trace:
<TASK>
dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120
print_address_description mm/kasan/report.c:408 [inline]
print_report+0xd2/0x2b0 mm/kasan/report.c:521
kasan_report+0x118/0x150 mm/kasan/report.c:634
io_req_local_work_add io_uring/io_uring.c:1184 [inline]
__io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252
io_msg_remote_post io_uring/msg_ring.c:103 [inline]
io_msg_data_remote io_uring/msg_ring.c:133 [inline]
__io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151
io_msg_ring_data io_uring/msg_ring.c:173 [inline]
io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314
__io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739
io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762
io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874
io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642
io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696
ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
which is supposed to be safe with how requests are allocated. But msg
ring requests alloc and free on their own, and hence must defer freeing
to a sane time.
Add an rcu_head and use kfree_rcu() in both spots where requests are
freed. Only the one in io_msg_tw_complete() is strictly required as it
has been visible on the other ring, but use it consistently in the other
spot as well.
This should not cause any other issues outside of KASAN rightfully
complaining about it. |
| In the Linux kernel, the following vulnerability has been resolved:
fs/fhandle.c: fix a race in call of has_locked_children()
may_decode_fh() is calling has_locked_children() while holding no locks.
That's an oopsable race...
The rest of the callers are safe since they are holding namespace_sem and
are guaranteed a positive refcount on the mount in question.
Rename the current has_locked_children() to __has_locked_children(), make
it static and switch the fs/namespace.c users to it.
Make has_locked_children() a wrapper for __has_locked_children(), calling
the latter under read_seqlock_excl(&mount_lock). |
| In the Linux kernel, the following vulnerability has been resolved:
net: dsa: b53: do not enable EEE on bcm63xx
BCM63xx internal switches do not support EEE, but provide multiple RGMII
ports where external PHYs may be connected. If one of these PHYs are EEE
capable, we may try to enable EEE for the MACs, which then hangs the
system on access of the (non-existent) EEE registers.
Fix this by checking if the switch actually supports EEE before
attempting to configure it. |
