| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| A high privileged remote attacker with admin privileges for the webUI can brute-force the "root" and "user" passwords of the underlying OS due to a weak password generation algorithm. |
| Sending an HTTP request/response body with greater than 2^31 bytes triggers an infinite loop in proxygen::coro::HTTPQuicCoroSession which blocks the backing event loop and unconditionally appends data to a std::vector per-loop iteration. This issue leads to unbounded memory growth and eventually causes the process to run out of memory. |
| In WODESYS WD-R608U router (also known as WDR122B V2.0 and WDR28) an unauthorised user can view configuration files by directly referencing the resource in question.
The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version WDR28081123OV1.01 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable. |
| WODESYS WD-R608U router (also known as WDR122B V2.0 and WDR28) is vulnerable to Broken Access Control in initial configuration wizard.cgi endpoint. Malicious attacker can change admin panel password without authorization. The vulnerability can also be exploited after the initial configuration has been set.
The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version WDR28081123OV1.01 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable. |
| In WODESYS WD-R608U router (also known as WDR122B V2.0 and WDR28) admin password is stored in configuration file as plaintext and can be obtained by unauthorized user by direct references to the resource in question.
The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version WDR28081123OV1.01 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable. |
| In WODESYS WD-R608U router (also known as WDR122B V2.0 and WDR28) due to lack of validation in the langGet parameter in the adm.cgi endpoint, the malicious attacker can execute system shell commands.
The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version WDR28081123OV1.01 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable. |
| In WODESYS WD-R608U router (also known as WDR122B V2.0 and WDR28) due to lack of authentication in the configuration change module in the adm.cgi endpoint, the unauthenticated attacker can execute commands including backup creation, device restart and resetting the device to factory settings.
The vendor was notified early about this vulnerability, but didn't respond with the details of vulnerability or vulnerable version range. Only version WDR28081123OV1.01 was tested and confirmed as vulnerable, other versions were not tested and might also be vulnerable. |
| Starting with Firefox 142, it was possible for a compromised child process to trigger a use-after-free in the GPU or browser process using WebGPU-related IPC calls. This may have been usable to escape the child process sandbox. This vulnerability affects Firefox < 144.0.2. |
| Control Panel provides an API for pre-registering into an enrollment and organization prior to a user's first login. The API for creating users checks that the account requesting a user creation has `edit` on the enrollment-level user directory, but is missing a separate check that the enrollment editor has access (or belongs to) the organization that they are adding a user to. |
| Due to a product misconfiguration in certain deployment types, it was possible from different pods in the same namespace to communicate with each other. This issue resulted in bypass of access control due to the presence of a vulnerable endpoint in Foundry Container Service that executed user-controlled commands locally. |
| An authentication bypass vulnerability in Google Cloud Dialogflow CX Messenger allowed unauthenticated users to interact with restricted chat agents, gaining access to the agents' knowledge and the ability to trigger their intents, by manipulating initialization parameters or crafting specific API requests.
All versions after August 20th, 2025 have been updated to protect from this vulnerability. No user action is required for this. |
| The vulnerability affects Ignition SCADA applications where Python
scripting is utilized for automation purposes. The vulnerability arises
from the absence of proper security controls that restrict which Python
libraries can be imported and executed within the scripting environment.
The core issue lies in the Ignition service account having system
permissions beyond what an Ignition privileged user requires. When an
authenticated administrator uploads a malicious project file containing
Python scripts with bind shell capabilities, the application executes
these scripts with the same privileges as the Ignition Gateway process,
which typically runs with SYSTEM-level permissions on Windows.
Alternative code execution patterns could lead to similar results. |
| due to insufficient sanitazation in Vega’s `convert()` function when `safeMode` is enabled and the spec variable is an array. An attacker can craft a malicious Vega diagram specification that will allow them to send requests to any URL, including local file system paths, leading to exposure of sensitive information. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: core: fbcvt: avoid division by 0 in fb_cvt_hperiod()
In fb_find_mode_cvt(), iff mode->refresh somehow happens to be 0x80000000,
cvt.f_refresh will become 0 when multiplying it by 2 due to overflow. It's
then passed to fb_cvt_hperiod(), where it's used as a divider -- division
by 0 will result in kernel oops. Add a sanity check for cvt.f_refresh to
avoid such overflow...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
seg6: Fix validation of nexthop addresses
The kernel currently validates that the length of the provided nexthop
address does not exceed the specified length. This can lead to the
kernel reading uninitialized memory if user space provided a shorter
length than the specified one.
Fix by validating that the provided length exactly matches the specified
one. |
| In the Linux kernel, the following vulnerability has been resolved:
ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()
There is no disagreement that we should check both ptp->is_virtual_clock
and ptp->n_vclocks to check if the ptp virtual clock is in use.
However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in
ptp_vclock_in_use(), we observe a recursive lock in the call trace
starting from n_vclocks_store().
============================================
WARNING: possible recursive locking detected
6.15.0-rc6 #1 Not tainted
--------------------------------------------
syz.0.1540/13807 is trying to acquire lock:
ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]
ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415
but task is already holding lock:
ffff888030704868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&ptp->n_vclocks_mux);
lock(&ptp->n_vclocks_mux);
*** DEADLOCK ***
....
============================================
The best way to solve this is to remove the logic that checks
ptp->n_vclocks in ptp_vclock_in_use().
The reason why this is appropriate is that any path that uses
ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater
than 0 before unregistering vclocks, and all functions are already
written this way. And in the function that uses ptp->n_vclocks, we
already get ptp->n_vclocks_mux before unregistering vclocks.
Therefore, we need to remove the redundant check for ptp->n_vclocks in
ptp_vclock_in_use() to prevent recursive locking. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix NULL pointer deference on eir_get_service_data
The len parameter is considered optional so it can be NULL so it cannot
be used for skipping to next entry of EIR_SERVICE_DATA. |
| In the Linux kernel, the following vulnerability has been resolved:
crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()
Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():
1] If dma_map_sg() fails for areq->dst, the device driver would try to free
DMA memory it has not allocated in the first place. To fix this, on the
"theend_sgs" error path, call dma unmap only if the corresponding dma
map was successful.
2] If the dma_map_single() call for the IV fails, the device driver would
try to free an invalid DMA memory address on the "theend_iv" path:
------------[ cut here ]------------
DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address
WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90
Modules linked in: skcipher_example(O+)
CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G O 6.15.0-rc3+ #24 PREEMPT
Tainted: [O]=OOT_MODULE
Hardware name: OrangePi Zero2 (DT)
pc : check_unmap+0x123c/0x1b90
lr : check_unmap+0x123c/0x1b90
...
Call trace:
check_unmap+0x123c/0x1b90 (P)
debug_dma_unmap_page+0xac/0xc0
dma_unmap_page_attrs+0x1f4/0x5fc
sun8i_ce_cipher_do_one+0x1bd4/0x1f40
crypto_pump_work+0x334/0x6e0
kthread_worker_fn+0x21c/0x438
kthread+0x374/0x664
ret_from_fork+0x10/0x20
---[ end trace 0000000000000000 ]---
To fix this, check for !dma_mapping_error() before calling
dma_unmap_single() on the "theend_iv" path. |
| In the Linux kernel, the following vulnerability has been resolved:
EDAC/skx_common: Fix general protection fault
After loading i10nm_edac (which automatically loads skx_edac_common), if
unload only i10nm_edac, then reload it and perform error injection testing,
a general protection fault may occur:
mce: [Hardware Error]: Machine check events logged
Oops: general protection fault ...
...
Workqueue: events mce_gen_pool_process
RIP: 0010:string+0x53/0xe0
...
Call Trace:
<TASK>
? die_addr+0x37/0x90
? exc_general_protection+0x1e7/0x3f0
? asm_exc_general_protection+0x26/0x30
? string+0x53/0xe0
vsnprintf+0x23e/0x4c0
snprintf+0x4d/0x70
skx_adxl_decode+0x16a/0x330 [skx_edac_common]
skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common]
skx_mce_check_error+0x17/0x20 [skx_edac_common]
...
The issue arose was because the variable 'adxl_component_count' (inside
skx_edac_common), which counts the ADXL components, was not reset. During
the reloading of i10nm_edac, the count was incremented by the actual number
of ADXL components again, resulting in a count that was double the real
number of ADXL components. This led to an out-of-bounds reference to the
ADXL component array, causing the general protection fault above.
Fix this issue by resetting the 'adxl_component_count' in adxl_put(),
which is called during the unloading of {skx,i10nm}_edac. |
| In the Linux kernel, the following vulnerability has been resolved:
ftrace: Add cond_resched() to ftrace_graph_set_hash()
When the kernel contains a large number of functions that can be traced,
the loop in ftrace_graph_set_hash() may take a lot of time to execute.
This may trigger the softlockup watchdog.
Add cond_resched() within the loop to allow the kernel to remain
responsive even when processing a large number of functions.
This matches the cond_resched() that is used in other locations of the
code that iterates over all functions that can be traced. |
