🚨 CVE-2023-40057
The SolarWinds Access Rights Manager was found to be susceptible to a Remote Code Execution Vulnerability. If exploited, this vulnerability allows an authenticated user to abuse a SolarWinds service resulting in remote code execution.
🎖@cveNotify
The SolarWinds Access Rights Manager was found to be susceptible to a Remote Code Execution Vulnerability. If exploited, this vulnerability allows an authenticated user to abuse a SolarWinds service resulting in remote code execution.
🎖@cveNotify
Solarwinds
SolarWinds Trust Center Security Advisories | CVE-2023-40057
SolarWinds Trust Center Security Advisories CVE-2023-40057
🚨 CVE-2024-23476
The SolarWinds Access Rights Manager (ARM) was found to be susceptible to a Directory Traversal Remote Code Execution Vulnerability. If exploited, this vulnerability allows an unauthenticated user to achieve the Remote Code Execution.
🎖@cveNotify
The SolarWinds Access Rights Manager (ARM) was found to be susceptible to a Directory Traversal Remote Code Execution Vulnerability. If exploited, this vulnerability allows an unauthenticated user to achieve the Remote Code Execution.
🎖@cveNotify
Solarwinds
SolarWinds Trust Center Security Advisories | CVE-2024-23476
SolarWinds Trust Center Security Advisories CVE-2024-23476
🚨 CVE-2024-23477
The SolarWinds Access Rights Manager (ARM) was found to be susceptible to a Directory Traversal Remote Code Execution Vulnerability. If exploited, this vulnerability allows an unauthenticated user to achieve a Remote Code Execution.
🎖@cveNotify
The SolarWinds Access Rights Manager (ARM) was found to be susceptible to a Directory Traversal Remote Code Execution Vulnerability. If exploited, this vulnerability allows an unauthenticated user to achieve a Remote Code Execution.
🎖@cveNotify
Solarwinds
SolarWinds Trust Center Security Advisories | CVE-2024-23477
SolarWinds Trust Center Security Advisories CVE-2024-23477
👍1
🚨 CVE-2024-23478
SolarWinds Access Rights Manager (ARM) was found to be susceptible to a Remote Code Execution Vulnerability. If exploited, this vulnerability allows an authenticated user to abuse a SolarWinds service, resulting in remote code execution.
🎖@cveNotify
SolarWinds Access Rights Manager (ARM) was found to be susceptible to a Remote Code Execution Vulnerability. If exploited, this vulnerability allows an authenticated user to abuse a SolarWinds service, resulting in remote code execution.
🎖@cveNotify
Solarwinds
SolarWinds Trust Center Security Advisories | CVE-2024-23478
SolarWinds Trust Center Security Advisories CVE-2024-23478
🚨 CVE-2023-45572
Buffer Overflow vulnerability in D-Link device DI-7003GV2.D1 v.23.08.25D1 and before, DI-7100G+V2.D1 v.23.08.23D1 and before, DI-7100GV2.D1 v.23.08.23D1, DI-7200G+V2.D1 v.23.08.23D1 and before, DI-7200GV2.E1 v.23.08.23E1 and before, DI-7300G+V2.D1 v.23.08.23D1, and DI-7400G+V2.D1 v.23.08.23D1 and before allows a remote attacker to execute arbitrary code via the fn parameter of the tgfile.htm function.
🎖@cveNotify
Buffer Overflow vulnerability in D-Link device DI-7003GV2.D1 v.23.08.25D1 and before, DI-7100G+V2.D1 v.23.08.23D1 and before, DI-7100GV2.D1 v.23.08.23D1, DI-7200G+V2.D1 v.23.08.23D1 and before, DI-7200GV2.E1 v.23.08.23E1 and before, DI-7300G+V2.D1 v.23.08.23D1, and DI-7400G+V2.D1 v.23.08.23D1 and before allows a remote attacker to execute arbitrary code via the fn parameter of the tgfile.htm function.
🎖@cveNotify
🚨 CVE-2023-46967
Cross Site Scripting vulnerability in the sanitize function in Enhancesoft osTicket 1.18.0 allows a remote attacker to escalate privileges via a crafted support ticket.
🎖@cveNotify
Cross Site Scripting vulnerability in the sanitize function in Enhancesoft osTicket 1.18.0 allows a remote attacker to escalate privileges via a crafted support ticket.
🎖@cveNotify
Sonarsource
Pitfalls of Desanitization: Leaking Customer Data from osTicket
The dangerous Desanitization pattern led to an XSS vulnerability in the open-source helpdesk software osTicket, which can be used to leak customer data.
🚨 CVE-2023-49034
Cross Site Scripting (XSS) vulnerability in ProjeQtOr 11.0.2 allows a remote attacker to execute arbitrary code via a crafted script to thecheckvalidHtmlText function in the ack.php and security.php files.
🎖@cveNotify
Cross Site Scripting (XSS) vulnerability in ProjeQtOr 11.0.2 allows a remote attacker to execute arbitrary code via a crafted script to thecheckvalidHtmlText function in the ack.php and security.php files.
🎖@cveNotify
Gist
Public reference for CVE-2023-49034
Public reference for CVE-2023-49034. GitHub Gist: instantly share code, notes, and snippets.
🚨 CVE-2023-52436
In the Linux kernel, the following vulnerability has been resolved:
f2fs: explicitly null-terminate the xattr list
When setting an xattr, explicitly null-terminate the xattr list. This
eliminates the fragile assumption that the unused xattr space is always
zeroed.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
f2fs: explicitly null-terminate the xattr list
When setting an xattr, explicitly null-terminate the xattr list. This
eliminates the fragile assumption that the unused xattr space is always
zeroed.
🎖@cveNotify
🚨 CVE-2023-52437
In the Linux kernel, the following vulnerability has been resolved:
Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"
This reverts commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74.
That commit introduced the following race and can cause system hung.
md_write_start: raid5d:
// mddev->in_sync == 1
set "MD_SB_CHANGE_PENDING"
// running before md_write_start wakeup it
waiting "MD_SB_CHANGE_PENDING" cleared
>>>>>>>>> hung
wakeup mddev->thread
...
waiting "MD_SB_CHANGE_PENDING" cleared
>>>> hung, raid5d should clear this flag
but get hung by same flag.
The issue reverted commit fixing is fixed by last patch in a new way.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"
This reverts commit 5e2cf333b7bd5d3e62595a44d598a254c697cd74.
That commit introduced the following race and can cause system hung.
md_write_start: raid5d:
// mddev->in_sync == 1
set "MD_SB_CHANGE_PENDING"
// running before md_write_start wakeup it
waiting "MD_SB_CHANGE_PENDING" cleared
>>>>>>>>> hung
wakeup mddev->thread
...
waiting "MD_SB_CHANGE_PENDING" cleared
>>>> hung, raid5d should clear this flag
but get hung by same flag.
The issue reverted commit fixing is fixed by last patch in a new way.
🎖@cveNotify
🚨 CVE-2023-52438
In the Linux kernel, the following vulnerability has been resolved:
binder: fix use-after-free in shinker's callback
The mmap read lock is used during the shrinker's callback, which means
that using alloc->vma pointer isn't safe as it can race with munmap().
As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
munmap") the mmap lock is downgraded after the vma has been isolated.
I was able to reproduce this issue by manually adding some delays and
triggering page reclaiming through the shrinker's debug sysfs. The
following KASAN report confirms the UAF:
==================================================================
BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
Read of size 8 at addr ffff356ed50e50f0 by task bash/478
CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
Hardware name: linux,dummy-virt (DT)
Call trace:
zap_page_range_single+0x470/0x4b8
binder_alloc_free_page+0x608/0xadc
__list_lru_walk_one+0x130/0x3b0
list_lru_walk_node+0xc4/0x22c
binder_shrink_scan+0x108/0x1dc
shrinker_debugfs_scan_write+0x2b4/0x500
full_proxy_write+0xd4/0x140
vfs_write+0x1ac/0x758
ksys_write+0xf0/0x1dc
__arm64_sys_write+0x6c/0x9c
Allocated by task 492:
kmem_cache_alloc+0x130/0x368
vm_area_alloc+0x2c/0x190
mmap_region+0x258/0x18bc
do_mmap+0x694/0xa60
vm_mmap_pgoff+0x170/0x29c
ksys_mmap_pgoff+0x290/0x3a0
__arm64_sys_mmap+0xcc/0x144
Freed by task 491:
kmem_cache_free+0x17c/0x3c8
vm_area_free_rcu_cb+0x74/0x98
rcu_core+0xa38/0x26d4
rcu_core_si+0x10/0x1c
__do_softirq+0x2fc/0xd24
Last potentially related work creation:
__call_rcu_common.constprop.0+0x6c/0xba0
call_rcu+0x10/0x1c
vm_area_free+0x18/0x24
remove_vma+0xe4/0x118
do_vmi_align_munmap.isra.0+0x718/0xb5c
do_vmi_munmap+0xdc/0x1fc
__vm_munmap+0x10c/0x278
__arm64_sys_munmap+0x58/0x7c
Fix this issue by performing instead a vma_lookup() which will fail to
find the vma that was isolated before the mmap lock downgrade. Note that
this option has better performance than upgrading to a mmap write lock
which would increase contention. Plus, mmap_write_trylock() has been
recently removed anyway.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
binder: fix use-after-free in shinker's callback
The mmap read lock is used during the shrinker's callback, which means
that using alloc->vma pointer isn't safe as it can race with munmap().
As of commit dd2283f2605e ("mm: mmap: zap pages with read mmap_sem in
munmap") the mmap lock is downgraded after the vma has been isolated.
I was able to reproduce this issue by manually adding some delays and
triggering page reclaiming through the shrinker's debug sysfs. The
following KASAN report confirms the UAF:
==================================================================
BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
Read of size 8 at addr ffff356ed50e50f0 by task bash/478
CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
Hardware name: linux,dummy-virt (DT)
Call trace:
zap_page_range_single+0x470/0x4b8
binder_alloc_free_page+0x608/0xadc
__list_lru_walk_one+0x130/0x3b0
list_lru_walk_node+0xc4/0x22c
binder_shrink_scan+0x108/0x1dc
shrinker_debugfs_scan_write+0x2b4/0x500
full_proxy_write+0xd4/0x140
vfs_write+0x1ac/0x758
ksys_write+0xf0/0x1dc
__arm64_sys_write+0x6c/0x9c
Allocated by task 492:
kmem_cache_alloc+0x130/0x368
vm_area_alloc+0x2c/0x190
mmap_region+0x258/0x18bc
do_mmap+0x694/0xa60
vm_mmap_pgoff+0x170/0x29c
ksys_mmap_pgoff+0x290/0x3a0
__arm64_sys_mmap+0xcc/0x144
Freed by task 491:
kmem_cache_free+0x17c/0x3c8
vm_area_free_rcu_cb+0x74/0x98
rcu_core+0xa38/0x26d4
rcu_core_si+0x10/0x1c
__do_softirq+0x2fc/0xd24
Last potentially related work creation:
__call_rcu_common.constprop.0+0x6c/0xba0
call_rcu+0x10/0x1c
vm_area_free+0x18/0x24
remove_vma+0xe4/0x118
do_vmi_align_munmap.isra.0+0x718/0xb5c
do_vmi_munmap+0xdc/0x1fc
__vm_munmap+0x10c/0x278
__arm64_sys_munmap+0x58/0x7c
Fix this issue by performing instead a vma_lookup() which will fail to
find the vma that was isolated before the mmap lock downgrade. Note that
this option has better performance than upgrading to a mmap write lock
which would increase contention. Plus, mmap_write_trylock() has been
recently removed anyway.
🎖@cveNotify
🚨 CVE-2023-52439
In the Linux kernel, the following vulnerability has been resolved:
uio: Fix use-after-free in uio_open
core-1 core-2
-------------------------------------------------------
uio_unregister_device uio_open
idev = idr_find()
device_unregister(&idev->dev)
put_device(&idev->dev)
uio_device_release
get_device(&idev->dev)
kfree(idev)
uio_free_minor(minor)
uio_release
put_device(&idev->dev)
kfree(idev)
-------------------------------------------------------
In the core-1 uio_unregister_device(), the device_unregister will kfree
idev when the idev->dev kobject ref is 1. But after core-1
device_unregister, put_device and before doing kfree, the core-2 may
get_device. Then:
1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
2. When core-2 do uio_release and put_device, the idev will be double
freed.
To address this issue, we can get idev atomic & inc idev reference with
minor_lock.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
uio: Fix use-after-free in uio_open
core-1 core-2
-------------------------------------------------------
uio_unregister_device uio_open
idev = idr_find()
device_unregister(&idev->dev)
put_device(&idev->dev)
uio_device_release
get_device(&idev->dev)
kfree(idev)
uio_free_minor(minor)
uio_release
put_device(&idev->dev)
kfree(idev)
-------------------------------------------------------
In the core-1 uio_unregister_device(), the device_unregister will kfree
idev when the idev->dev kobject ref is 1. But after core-1
device_unregister, put_device and before doing kfree, the core-2 may
get_device. Then:
1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
2. When core-2 do uio_release and put_device, the idev will be double
freed.
To address this issue, we can get idev atomic & inc idev reference with
minor_lock.
🎖@cveNotify
🚨 CVE-2024-25141
When ssl was enabled for Mongo Hook, default settings included "allow_insecure" which caused that certificates were not validated. This was unexpected and undocumented.
Users are recommended to upgrade to version 4.0.0, which fixes this issue.
🎖@cveNotify
When ssl was enabled for Mongo Hook, default settings included "allow_insecure" which caused that certificates were not validated. This was unexpected and undocumented.
Users are recommended to upgrade to version 4.0.0, which fixes this issue.
🎖@cveNotify
GitHub
Adding certificate validation for ssl in mongo hook by amoghrajesh · Pull Request #37214 · apache/airflow
Currently, we are skipping tls certificate validation in mongo hook even if ssl is set to true. This needs to be handled better
^ Add meaningful description above
Read the Pull Request Guidelines...
^ Add meaningful description above
Read the Pull Request Guidelines...
🚨 CVE-2024-23591
ThinkSystem SR670V2 servers manufactured from approximately June 2021 to July 2023 were left in Manufacturing Mode which could allow
an attacker with privileged logical access to the host or physical access to server internals to modify or disable Intel Boot Guard firmware integrity, SPS security, and other SPS configuration setting. The server’s NIST SP
800-193-compliant Platform Firmware Resiliency (PFR) security subsystem
significantly mitigates this issue.
🎖@cveNotify
ThinkSystem SR670V2 servers manufactured from approximately June 2021 to July 2023 were left in Manufacturing Mode which could allow
an attacker with privileged logical access to the host or physical access to server internals to modify or disable Intel Boot Guard firmware integrity, SPS security, and other SPS configuration setting. The server’s NIST SP
800-193-compliant Platform Firmware Resiliency (PFR) security subsystem
significantly mitigates this issue.
🎖@cveNotify
🚨 CVE-2024-25141
When ssl was enabled for Mongo Hook, default settings included "allow_insecure" which caused that certificates were not validated. This was unexpected and undocumented.
Users are recommended to upgrade to version 4.0.0, which fixes this issue.
🎖@cveNotify
When ssl was enabled for Mongo Hook, default settings included "allow_insecure" which caused that certificates were not validated. This was unexpected and undocumented.
Users are recommended to upgrade to version 4.0.0, which fixes this issue.
🎖@cveNotify
🚨 CVE-2021-29038
Liferay Portal 7.2.0 through 7.3.5, and older unsupported versions, and Liferay DXP 7.3 before fix pack 1, 7.2 before fix pack 17, and older unsupported versions does not obfuscate password reminder answers on the page, which allows attackers to use man-in-the-middle or shoulder surfing attacks to steal user's password reminder answers.
🎖@cveNotify
Liferay Portal 7.2.0 through 7.3.5, and older unsupported versions, and Liferay DXP 7.3 before fix pack 1, 7.2 before fix pack 17, and older unsupported versions does not obfuscate password reminder answers on the page, which allows attackers to use man-in-the-middle or shoulder surfing attacks to steal user's password reminder answers.
🎖@cveNotify
🚨 CVE-2021-29050
Cross-Site Request Forgery (CSRF) vulnerability in the terms of use page in Liferay Portal before 7.3.6, and Liferay DXP 7.3 before service pack 1, 7.2 before fix pack 11 allows remote attackers to accept the site's terms of use via social engineering and enticing the user to visit a malicious page.
🎖@cveNotify
Cross-Site Request Forgery (CSRF) vulnerability in the terms of use page in Liferay Portal before 7.3.6, and Liferay DXP 7.3 before service pack 1, 7.2 before fix pack 11 allows remote attackers to accept the site's terms of use via social engineering and enticing the user to visit a malicious page.
🎖@cveNotify
🚨 CVE-2023-47422
An access control issue in /usr/sbin/httpd in Tenda TX9 V1 V22.03.02.54, Tenda AX3 V3 V16.03.12.11, Tenda AX9 V1 V22.03.01.46, and Tenda AX12 V1 V22.03.01.46 allows attackers to bypass authentication on any endpoint via a crafted URL.
🎖@cveNotify
An access control issue in /usr/sbin/httpd in Tenda TX9 V1 V22.03.02.54, Tenda AX3 V3 V16.03.12.11, Tenda AX9 V1 V22.03.01.46, and Tenda AX12 V1 V22.03.01.46 allows attackers to bypass authentication on any endpoint via a crafted URL.
🎖@cveNotify
GitHub
My-CVE/Tenda/CVE-2023-47422 at main · xiaobye-ctf/My-CVE
Contribute to xiaobye-ctf/My-CVE development by creating an account on GitHub.
🚨 CVE-2023-6936
In wolfSSL prior to 5.6.6, if callback functions are enabled (via the WOLFSSL_CALLBACKS flag), then a malicious TLS client or network attacker can trigger a buffer over-read on the heap of 5 bytes (WOLFSSL_CALLBACKS is only intended for debugging).
🎖@cveNotify
In wolfSSL prior to 5.6.6, if callback functions are enabled (via the WOLFSSL_CALLBACKS flag), then a malicious TLS client or network attacker can trigger a buffer over-read on the heap of 5 bytes (WOLFSSL_CALLBACKS is only intended for debugging).
🎖@cveNotify
GitHub
fix WOLFSSL_CALLBACK memory error by bigbrett · Pull Request #6949 · wolfSSL/wolfssl
Fixes ZD16925. Reproduction steps in ticket.
Fixes bug that prevented make check from passing when used with WOLFSSL_CALLBACKS. When invoking the example server with WOLFSSL_CALLBACKS defined and u...
Fixes bug that prevented make check from passing when used with WOLFSSL_CALLBACKS. When invoking the example server with WOLFSSL_CALLBACKS defined and u...
🚨 CVE-2024-23758
An issue discovered in Unisys Stealth 5.3.062.0 allows attackers to view sensitive information via the Enterprise ManagementInstaller_msi.log file.
🎖@cveNotify
An issue discovered in Unisys Stealth 5.3.062.0 allows attackers to view sensitive information via the Enterprise ManagementInstaller_msi.log file.
🎖@cveNotify