| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| mudler/localai version 2.17.1 is vulnerable to a Timing Attack. This type of side-channel attack allows an attacker to compromise the cryptosystem by analyzing the time taken to execute cryptographic algorithms. Specifically, in the context of password handling, an attacker can determine valid login credentials based on the server's response time, potentially leading to unauthorized access. |
| In mintplex-labs/anything-llm versions up to and including 1.5.3, an issue was discovered where the password hash of a user is returned in the response after login (`POST /api/request-token`) and after account creations (`POST /api/admin/users/new`). This exposure occurs because the entire User object, including the bcrypt password hash, is included in the response sent to the frontend. This practice could potentially lead to sensitive information exposure despite the use of bcrypt, a strong hashing algorithm. It is recommended not to expose any clues about passwords to the frontend. |
| In lunary-ai/lunary versions up to and including 1.2.5, an information disclosure vulnerability exists where account recovery hashes of users are inadvertently exposed to unauthorized actors. This issue occurs when authenticated users inspect responses from `GET /v1/users/me` and `GET /v1/users/me/org` endpoints. The exposed account recovery hashes, while not directly related to user passwords, represent sensitive information that should not be accessible to unauthorized parties. Exposing these hashes could potentially facilitate account recovery attacks or other malicious activities. The vulnerability was addressed in version 1.2.6. |
| In lunary-ai/lunary version 1.2.4, an account takeover vulnerability exists due to the exposure of password recovery tokens in API responses. Specifically, when a user initiates the password reset process, the recovery token is included in the response of the `GET /v1/users/me/org` endpoint, which lists all users in a team. This allows any authenticated user to capture the recovery token of another user and subsequently change that user's password without consent, effectively taking over the account. The issue lies in the inclusion of the `recovery_token` attribute in the users object returned by the API. |
| .NET and Visual Studio Denial of Service Vulnerability |
| Windows Layer-2 Bridge Network Driver Denial of Service Vulnerability |
| Kernel Streaming WOW Thunk Service Driver Elevation of Privilege Vulnerability |
| PowerShell Elevation of Privilege Vulnerability |
| PowerShell Elevation of Privilege Vulnerability |
| Windows Themes Spoofing Vulnerability |
| Microsoft Outlook Remote Code Execution Vulnerability |
| Microsoft Outlook Spoofing Vulnerability |
| Microsoft Message Queuing Information Disclosure Vulnerability |
| Microsoft Windows Codecs Library Information Disclosure Vulnerability |
| PowerShell Elevation of Privilege Vulnerability |
| Windows Kernel Information Disclosure Vulnerability |
| Windows NTLM Spoofing Vulnerability |
| In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3: Fix GICR_CTLR.RWP polling
It turns out that our polling of RWP is totally wrong when checking
for it in the redistributors, as we test the *distributor* bit index,
whereas it is a different bit number in the RDs... Oopsie boo.
This is embarassing. Not only because it is wrong, but also because
it took *8 years* to notice the blunder...
Just fix the damn thing. |
| In the Linux kernel, the following vulnerability has been resolved:
highmem: fix checks in __kmap_local_sched_{in,out}
When CONFIG_DEBUG_KMAP_LOCAL is enabled __kmap_local_sched_{in,out} check
that even slots in the tsk->kmap_ctrl.pteval are unmapped. The slots are
initialized with 0 value, but the check is done with pte_none. 0 pte
however does not necessarily mean that pte_none will return true. e.g.
on xtensa it returns false, resulting in the following runtime warnings:
WARNING: CPU: 0 PID: 101 at mm/highmem.c:627 __kmap_local_sched_out+0x51/0x108
CPU: 0 PID: 101 Comm: touch Not tainted 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13
Call Trace:
dump_stack+0xc/0x40
__warn+0x8f/0x174
warn_slowpath_fmt+0x48/0xac
__kmap_local_sched_out+0x51/0x108
__schedule+0x71a/0x9c4
preempt_schedule_irq+0xa0/0xe0
common_exception_return+0x5c/0x93
do_wp_page+0x30e/0x330
handle_mm_fault+0xa70/0xc3c
do_page_fault+0x1d8/0x3c4
common_exception+0x7f/0x7f
WARNING: CPU: 0 PID: 101 at mm/highmem.c:664 __kmap_local_sched_in+0x50/0xe0
CPU: 0 PID: 101 Comm: touch Tainted: G W 5.17.0-rc7-00010-gd3a1cdde80d2-dirty #13
Call Trace:
dump_stack+0xc/0x40
__warn+0x8f/0x174
warn_slowpath_fmt+0x48/0xac
__kmap_local_sched_in+0x50/0xe0
finish_task_switch$isra$0+0x1ce/0x2f8
__schedule+0x86e/0x9c4
preempt_schedule_irq+0xa0/0xe0
common_exception_return+0x5c/0x93
do_wp_page+0x30e/0x330
handle_mm_fault+0xa70/0xc3c
do_page_fault+0x1d8/0x3c4
common_exception+0x7f/0x7f
Fix it by replacing !pte_none(pteval) with pte_val(pteval) != 0. |
| IBM Aspera 5.0.0 through 5.0.13.1
could disclose sensitive user information from the system to an authenticated user due to an observable discrepancy of returned data. |
