🚨 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
🚨 CVE-2023-50923
In QUIC in RFC 9000, the Latency Spin Bit specification (section 17.4) does not strictly constrain the bit value when the feature is disabled, which might allow remote attackers to construct a covert channel with data represented as changes to the bit value. NOTE: The "Sheridan, S., Keane, A. (2015). In Proceedings of the 14th European Conference on Cyber Warfare and Security (ECCWS), University of Hertfordshire, Hatfield, UK." paper says "Modern Internet communication protocols provide an almost infinite number of ways in which data can be hidden or embed whithin seemingly normal network traffic."
🎖@cveNotify
In QUIC in RFC 9000, the Latency Spin Bit specification (section 17.4) does not strictly constrain the bit value when the feature is disabled, which might allow remote attackers to construct a covert channel with data represented as changes to the bit value. NOTE: The "Sheridan, S., Keane, A. (2015). In Proceedings of the 14th European Conference on Cyber Warfare and Security (ECCWS), University of Hertfordshire, Hatfield, UK." paper says "Modern Internet communication protocols provide an almost infinite number of ways in which data can be hidden or embed whithin seemingly normal network traffic."
🎖@cveNotify
ARROW@TU Dublin
Detection of DNS Based Covert Channels
Information theft or data exfiltration, whether personal or corporate, is now a lucrative mainstay of cybercrime activity. Recent security reports have suggested that while information, such as credit card data is still a prime target, other data such as…
👍2
🚨 CVE-2024-25147
Cross-site scripting (XSS) vulnerability in HtmlUtil.escapeJsLink in Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 15, and older unsupported versions allows remote attackers to inject arbitrary web script or HTML via crafted javascript: style links.
🎖@cveNotify
Cross-site scripting (XSS) vulnerability in HtmlUtil.escapeJsLink in Liferay Portal 7.2.0 through 7.4.1, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 15, and older unsupported versions allows remote attackers to inject arbitrary web script or HTML via crafted javascript: style links.
🎖@cveNotify
🚨 CVE-2024-25152
Stored cross-site scripting (XSS) vulnerability in Message Board widget in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via the filename of an attachment.
🎖@cveNotify
Stored cross-site scripting (XSS) vulnerability in Message Board widget in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via the filename of an attachment.
🎖@cveNotify
🚨 CVE-2024-25601
Stored cross-site scripting (XSS) vulnerability in Expando module's geolocation custom fields in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via a crafted payload injected into the name text field of a geolocation custom field.
🎖@cveNotify
Stored cross-site scripting (XSS) vulnerability in Expando module's geolocation custom fields in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via a crafted payload injected into the name text field of a geolocation custom field.
🎖@cveNotify
🚨 CVE-2024-25602
Stored cross-site scripting (XSS) vulnerability in Users Admin module's edit user page in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via a crafted payload injected into an organization’s “Name” text field
🎖@cveNotify
Stored cross-site scripting (XSS) vulnerability in Users Admin module's edit user page in Liferay Portal 7.2.0 through 7.4.2, and older unsupported versions, and Liferay DXP 7.3 before service pack 3, 7.2 before fix pack 17, and older unsupported versions allows remote authenticated users to inject arbitrary web script or HTML via a crafted payload injected into an organization’s “Name” text field
🎖@cveNotify
🚨 CVE-2023-49295
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
🎖@cveNotify
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
🎖@cveNotify
GitHub
limit the number of queued PATH_RESPONSE frames to 256 (#4199) · quic-go/quic-go@17fc98c
A QUIC implementation in pure go. Contribute to quic-go/quic-go development by creating an account on GitHub.