| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| TOTOLink A7000R V9.1.0u.6115_B20201022 was discovered to contain a stack overflow in the ssid parameter of the urldecode function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Tenda AX3 V16.03.12.10_CN was discovered to contain a stack overflow in the wpapsk_crypto parameter of the wlSetExternParameter function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted request. |
| Inappropriate implementation in Permissions in Google Chrome prior to 140.0.7339.80 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low) |
| Inappropriate implementation in Passkeys in Google Chrome prior to 140.0.7339.80 allowed a local attacker to obtain potentially sensitive information via debug logs. (Chromium security severity: Low) |
| Insufficient policy enforcement in Devtools in Google Chrome prior to 140.0.7339.80 allowed a remote attacker to leak cross-origin data via Devtools. (Chromium security severity: Low) |
| Insufficient validation of untrusted input in Downloads in Google Chrome on Android prior to 140.0.7339.80 allowed a remote attacker to perform domain spoofing via a crafted HTML page. (Chromium security severity: Low) |
| Insufficient validation of untrusted input in Devtools in Google Chrome prior to 140.0.7339.80 allowed a remote attacker to execute arbitrary code via user action in Devtools. (Chromium security severity: Low) |
| Inappropriate implementation in Permissions in Google Chrome prior to 140.0.7339.80 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low) |
| Inappropriate implementation in Downloads in Google Chrome on Windows prior to 140.0.7339.80 allowed a remote attacker to bypass Mark of the Web via a crafted HTML page. (Chromium security severity: Low) |
| Triofox versions prior to 16.7.10368.56560, are vulnerable to an Improper Access Control flaw that allows access to initial setup pages even after setup is complete. |
| supOS 5.0 allows api/image/download?fileName=../ directory traversal for reading files. |
| EIP Plus developed by Hundred Plus has an Arbitrary File Uplaod vulnerability, allowing privileged remote attackers to upload and execute web shell backdoors, thereby enabling arbitrary code execution on the server. |
| A vulnerability was found in SourceCodester Food Ordering System 1.0. Affected by this vulnerability is an unknown functionality of the file /routers/edit-orders.php. The manipulation of the argument ID results in sql injection. It is possible to launch the attack remotely. The exploit has been made public and could be used. |
| Water Management System v1.0 is vulnerable to Cross Site Scripting (XSS) in /add_vendor.php. |
| Improper Authorization in Elastic Cloud Enterprise can lead to Privilege Escalation where the built-in readonly user can call APIs that should not be allowed. The list of APIs that are affected by this issue is:
post:/platform/configuration/security/service-accounts
delete:/platform/configuration/security/service-accounts/{user_id}
patch:/platform/configuration/security/service-accounts/{user_id}
post:/platform/configuration/security/service-accounts/{user_id}/keys
delete:/platform/configuration/security/service-accounts/{user_id}/keys/{api_key_id}
patch:/user
post:/users
post:/users/auth/keys
delete:/users/auth/keys
delete:/users/auth/keys/_all
delete:/users/auth/keys/{api_key_id}
delete:/users/{user_id}/auth/keys
delete:/users/{user_id}/auth/keys/{api_key_id}
delete:/users/{user_name}
patch:/users/{user_name} |
| Versions of the package cloudinary before 2.7.0 are vulnerable to Arbitrary Argument Injection due to improper parsing of parameter values containing an ampersand. An attacker can inject additional, unintended parameters. This could lead to a variety of malicious outcomes, such as bypassing security checks, altering data, or manipulating the application's behavior.
**Note:**
Following our established security policy, we attempted to contact the maintainer regarding this vulnerability, but haven't received a response. |
| In the Linux kernel, the following vulnerability has been resolved:
riscv: uprobes: Add missing fence.i after building the XOL buffer
The XOL (execute out-of-line) buffer is used to single-step the
replaced instruction(s) for uprobes. The RISC-V port was missing a
proper fence.i (i$ flushing) after constructing the XOL buffer, which
can result in incorrect execution of stale/broken instructions.
This was found running the BPF selftests "test_progs:
uprobe_autoattach, attach_probe" on the Spacemit K1/X60, where the
uprobes tests randomly blew up. |
| In the Linux kernel, the following vulnerability has been resolved:
net_sched: hfsc: Fix a potential UAF in hfsc_dequeue() too
Similarly to the previous patch, we need to safe guard hfsc_dequeue()
too. But for this one, we don't have a reliable reproducer. |
| In the Linux kernel, the following vulnerability has been resolved:
tipc: fix NULL pointer dereference in tipc_mon_reinit_self()
syzbot reported:
tipc: Node number set to 1055423674
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
Workqueue: events tipc_net_finalize_work
RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719
...
RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba
RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010
RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007
R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010
FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140
process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238
process_scheduled_works kernel/workqueue.c:3319 [inline]
worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400
kthread+0x3c2/0x780 kernel/kthread.c:464
ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
...
RIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719
...
RSP: 0018:ffffc9000356fb68 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba
RDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010
RBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007
R13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010
FS: 0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
There is a racing condition between workqueue created when enabling
bearer and another thread created when disabling bearer right after
that as follow:
enabling_bearer | disabling_bearer
--------------- | ----------------
tipc_disc_timeout() |
{ | bearer_disable()
... | {
schedule_work(&tn->work); | tipc_mon_delete()
... | {
} | ...
| write_lock_bh(&mon->lock);
| mon->self = NULL;
| write_unlock_bh(&mon->lock);
| ...
| }
tipc_net_finalize_work() | }
{ |
... |
tipc_net_finalize() |
{ |
... |
tipc_mon_reinit_self() |
{ |
... |
write_lock_bh(&mon->lock); |
mon->self->addr = tipc_own_addr(net); |
write_unlock_bh(&mon->lock); |
...
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
nvmet: fix out-of-bounds access in nvmet_enable_port
When trying to enable a port that has no transport configured yet,
nvmet_enable_port() uses NVMF_TRTYPE_MAX (255) to query the transports
array, causing an out-of-bounds access:
[ 106.058694] BUG: KASAN: global-out-of-bounds in nvmet_enable_port+0x42/0x1da
[ 106.058719] Read of size 8 at addr ffffffff89dafa58 by task ln/632
[...]
[ 106.076026] nvmet: transport type 255 not supported
Since commit 200adac75888, NVMF_TRTYPE_MAX is the default state as configured by
nvmet_ports_make().
Avoid this by checking for NVMF_TRTYPE_MAX before proceeding. |