🚨 CVE-2025-11472
A flaw has been found in SourceCodester Hotel and Lodge Management System 1.0. This impacts an unknown function of the file /edit_room.php. This manipulation of the argument ID causes sql injection. It is possible to initiate the attack remotely. The exploit has been published and may be used.
🎖@cveNotify
A flaw has been found in SourceCodester Hotel and Lodge Management System 1.0. This impacts an unknown function of the file /edit_room.php. This manipulation of the argument ID causes sql injection. It is possible to initiate the attack remotely. The exploit has been published and may be used.
🎖@cveNotify
GitHub
sourcecodester Hotel and Lodge Management System using PHP with Source Code V1.0 /edit_customer.php SQL injection · Issue #15 ·…
sourcecodester Hotel and Lodge Management System using PHP with Source Code V1.0 /edit_room.php SQL injection NAME OF AFFECTED PRODUCT(S) Hotel and Lodge Management System using PHP Vendor Homepage...
🚨 CVE-2025-11473
A vulnerability has been found in SourceCodester Hotel and Lodge Management System 1.0. Affected is an unknown function of the file /edit_curr.php. Such manipulation of the argument currsymbol leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.
🎖@cveNotify
A vulnerability has been found in SourceCodester Hotel and Lodge Management System 1.0. Affected is an unknown function of the file /edit_curr.php. Such manipulation of the argument currsymbol leads to sql injection. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used.
🎖@cveNotify
GitHub
sourcecodester Hotel and Lodge Management System using PHP with Source Code V1.0 /edit_curr.php SQL injection · Issue #16 · TThuyyy/cve1
sourcecodester Hotel and Lodge Management System using PHP with Source Code V1.0 /edit_curr.php SQL injection NAME OF AFFECTED PRODUCT(S) Hotel and Lodge Management System using PHP Vendor Homepage...
🚨 CVE-2025-51480
Path Traversal vulnerability in onnx.external_data_helper.save_external_data in ONNX 1.17.0 allows attackers to overwrite arbitrary files by supplying crafted external_data.location paths containing traversal sequences, bypassing intended directory restrictions.
🎖@cveNotify
Path Traversal vulnerability in onnx.external_data_helper.save_external_data in ONNX 1.17.0 allows attackers to overwrite arbitrary files by supplying crafted external_data.location paths containing traversal sequences, bypassing intended directory restrictions.
🎖@cveNotify
GitHub
CVE-2024-5187 - GitHub Advisory Database
onnx allows Arbitrary File Overwrite in download_model_with_test_data
🚨 CVE-2025-11474
A vulnerability was found in SourceCodester Hotel and Lodge Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /edit_booking.php. Performing manipulation of the argument Name results in sql injection. The attack can be initiated remotely. The exploit has been made public and could be used.
🎖@cveNotify
A vulnerability was found in SourceCodester Hotel and Lodge Management System 1.0. Affected by this vulnerability is an unknown functionality of the file /edit_booking.php. Performing manipulation of the argument Name results in sql injection. The attack can be initiated remotely. The exploit has been made public and could be used.
🎖@cveNotify
GitHub
sourcecodester Hotel and Lodge Management System using PHP with Source Code V1.0 /edit_booking.php SQL injection · Issue #17 ·…
sourcecodester Hotel and Lodge Management System using PHP with Source Code V1.0 /edit_booking.php SQL injection NAME OF AFFECTED PRODUCT(S) Hotel and Lodge Management System using PHP Vendor Homep...
🚨 CVE-2025-11475
A vulnerability was determined in projectworlds Advanced Library Management System 1.0. Affected by this issue is some unknown functionality of the file /view_member.php. Executing manipulation of the argument user_id can lead to sql injection. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized.
🎖@cveNotify
A vulnerability was determined in projectworlds Advanced Library Management System 1.0. Affected by this issue is some unknown functionality of the file /view_member.php. Executing manipulation of the argument user_id can lead to sql injection. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized.
🎖@cveNotify
GitHub
Projectworlds Advanced Library Management System 'view_member.php' SQL injection · Issue #4 · ChenGuangHuangHun/CVE
Vulnerability Report — SQL Injection in view_member.php?user_id= Product: Advanced Library Management System (V1.0) Vendor / Project: ProjectWorlds (projectworlds.com) Source / Download: https://pr...
🚨 CVE-2025-43821
Cross-site scripting (XSS) vulnerability in the Commerce Product Comparison Table widget in Liferay Portal 7.4.0 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, and 7.4 GA through update 92 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a Commerce Product's Name text field.
🎖@cveNotify
Cross-site scripting (XSS) vulnerability in the Commerce Product Comparison Table widget in Liferay Portal 7.4.0 through 7.4.3.111, and Liferay DXP 2023.Q4.0 through 2023.Q4.5, 2023.Q3.1 through 2023.Q3.8, and 7.4 GA through update 92 allows remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a Commerce Product's Name text field.
🎖@cveNotify
🚨 CVE-2025-60298
Novel-Plus up to 5.2.4 was discovered to contain a Stored Cross-Site Scripting (XSS) vulnerability via the /author/updateIndexName endpoint. This vulnerability allows authenticated attackers to inject malicious JavaScript code through the indexName parameter, which gets stored in the database and executed when other users view the affected book chapter.
🎖@cveNotify
Novel-Plus up to 5.2.4 was discovered to contain a Stored Cross-Site Scripting (XSS) vulnerability via the /author/updateIndexName endpoint. This vulnerability allows authenticated attackers to inject malicious JavaScript code through the indexName parameter, which gets stored in the database and executed when other users view the affected book chapter.
🎖@cveNotify
GitHub
GitHub - 201206030/novel-plus: novel-plus 是一个多端(PC、WAP)阅读 、功能完善的小说 CMS 系统。包括小说推荐、小说检索、小说排行、小说阅读、小说书架、小说评论、小说爬虫、会员中心、作家专区、充值订阅、新闻发布等功能。
novel-plus 是一个多端(PC、WAP)阅读 、功能完善的小说 CMS 系统。包括小说推荐、小说检索、小说排行、小说阅读、小说书架、小说评论、小说爬虫、会员中心、作家专区、充值订阅、新闻发布等功能。 - 201206030/novel-plus
🚨 CVE-2025-60299
Novel-Plus with 5.2.0 was discovered to contain a Stored Cross-Site Scripting (XSS) vulnerability via the /book/addCommentReply endpoint. An authenticated user can inject malicious JavaScript through the replyContent parameter when replying to a book comment. The payload is stored in the database and is executed in other users’ browsers when they view the affected comment thread.
🎖@cveNotify
Novel-Plus with 5.2.0 was discovered to contain a Stored Cross-Site Scripting (XSS) vulnerability via the /book/addCommentReply endpoint. An authenticated user can inject malicious JavaScript through the replyContent parameter when replying to a book comment. The payload is stored in the database and is executed in other users’ browsers when they view the affected comment thread.
🎖@cveNotify
GitHub
GitHub - 201206030/novel-plus: novel-plus 是一个多端(PC、WAP)阅读 、功能完善的小说 CMS 系统。包括小说推荐、小说检索、小说排行、小说阅读、小说书架、小说评论、小说爬虫、会员中心、作家专区、充值订阅、新闻发布等功能。
novel-plus 是一个多端(PC、WAP)阅读 、功能完善的小说 CMS 系统。包括小说推荐、小说检索、小说排行、小说阅读、小说书架、小说评论、小说爬虫、会员中心、作家专区、充值订阅、新闻发布等功能。 - 201206030/novel-plus
🔥1
🚨 CVE-2024-53240
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: fix crash when removing device
When removing a netfront device directly after a suspend/resume cycle
it might happen that the queues have not been setup again, causing a
crash during the attempt to stop the queues another time.
Fix that by checking the queues are existing before trying to stop
them.
This is XSA-465 / CVE-2024-53240.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
xen/netfront: fix crash when removing device
When removing a netfront device directly after a suspend/resume cycle
it might happen that the queues have not been setup again, causing a
crash during the attempt to stop the queues another time.
Fix that by checking the queues are existing before trying to stop
them.
This is XSA-465 / CVE-2024-53240.
🎖@cveNotify
🚨 CVE-2024-53241
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: don't do PV iret hypercall through hypercall page
Instead of jumping to the Xen hypercall page for doing the iret
hypercall, directly code the required sequence in xen-asm.S.
This is done in preparation of no longer using hypercall page at all,
as it has shown to cause problems with speculation mitigations.
This is part of XSA-466 / CVE-2024-53241.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
x86/xen: don't do PV iret hypercall through hypercall page
Instead of jumping to the Xen hypercall page for doing the iret
hypercall, directly code the required sequence in xen-asm.S.
This is done in preparation of no longer using hypercall page at all,
as it has shown to cause problems with speculation mitigations.
This is part of XSA-466 / CVE-2024-53241.
🎖@cveNotify
🚨 CVE-2024-53148
In the Linux kernel, the following vulnerability has been resolved:
comedi: Flush partial mappings in error case
If some remap_pfn_range() calls succeeded before one failed, we still have
buffer pages mapped into the userspace page tables when we drop the buffer
reference with comedi_buf_map_put(bm). The userspace mappings are only
cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in
error case").
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
comedi: Flush partial mappings in error case
If some remap_pfn_range() calls succeeded before one failed, we still have
buffer pages mapped into the userspace page tables when we drop the buffer
reference with comedi_buf_map_put(bm). The userspace mappings are only
cleaned up later in the mmap error path.
Fix it by explicitly flushing all mappings in our VMA on the error path.
See commit 79a61cc3fc04 ("mm: avoid leaving partial pfn mappings around in
error case").
🎖@cveNotify
🚨 CVE-2024-53152
In the Linux kernel, the following vulnerability has been resolved:
PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()
Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.
All of the tegra194 endpoint SoCs supported as of now depend on the refclk
from the host for keeping the controller operational. Due to this
limitation, any access to the hardware registers in the absence of refclk
will result in a whole endpoint crash. Unfortunately, most of the
controller cleanups require accessing the hardware registers (like eDMA
cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup
functions can cause the crash in the endpoint SoC once host asserts PERST#.
One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host.
Thus, fix this crash by moving the controller cleanups to the start of
the pex_ep_event_pex_rst_deassert() function. This function is called
whenever the host has deasserted PERST# and it is guaranteed that the
refclk would be active at this point. So at the start of this function
(after enabling resources) the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()
Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of pex_ep_event_pex_rst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.
All of the tegra194 endpoint SoCs supported as of now depend on the refclk
from the host for keeping the controller operational. Due to this
limitation, any access to the hardware registers in the absence of refclk
will result in a whole endpoint crash. Unfortunately, most of the
controller cleanups require accessing the hardware registers (like eDMA
cleanup performed in dw_pcie_ep_cleanup(), etc...). So these cleanup
functions can cause the crash in the endpoint SoC once host asserts PERST#.
One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host.
Thus, fix this crash by moving the controller cleanups to the start of
the pex_ep_event_pex_rst_deassert() function. This function is called
whenever the host has deasserted PERST# and it is guaranteed that the
refclk would be active at this point. So at the start of this function
(after enabling resources) the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
🎖@cveNotify
🚨 CVE-2024-53153
In the Linux kernel, the following vulnerability has been resolved:
PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()
Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of qcom_pcie_perst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.
All of the Qcom endpoint SoCs supported as of now depend on the refclk from
the host for keeping the controller operational. Due to this limitation,
any access to the hardware registers in the absence of refclk will result
in a whole endpoint crash. Unfortunately, most of the controller cleanups
require accessing the hardware registers (like eDMA cleanup performed in
dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup
functions are currently causing the crash in the endpoint SoC once host
asserts PERST#.
One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host (as I was told by the Qcom engineers).
Thus, fix this crash by moving the controller cleanups to the start of
the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is
called whenever the host has deasserted PERST# and it is guaranteed that
the refclk would be active at this point. So at the start of this function
(after enabling resources), the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()
Currently, the endpoint cleanup function dw_pcie_ep_cleanup() and EPF
deinit notify function pci_epc_deinit_notify() are called during the
execution of qcom_pcie_perst_assert() i.e., when the host has asserted
PERST#. But quickly after this step, refclk will also be disabled by the
host.
All of the Qcom endpoint SoCs supported as of now depend on the refclk from
the host for keeping the controller operational. Due to this limitation,
any access to the hardware registers in the absence of refclk will result
in a whole endpoint crash. Unfortunately, most of the controller cleanups
require accessing the hardware registers (like eDMA cleanup performed in
dw_pcie_ep_cleanup(), powering down MHI EPF etc...). So these cleanup
functions are currently causing the crash in the endpoint SoC once host
asserts PERST#.
One way to address this issue is by generating the refclk in the endpoint
itself and not depending on the host. But that is not always possible as
some of the endpoint designs do require the endpoint to consume refclk from
the host (as I was told by the Qcom engineers).
Thus, fix this crash by moving the controller cleanups to the start of
the qcom_pcie_perst_deassert() function. qcom_pcie_perst_deassert() is
called whenever the host has deasserted PERST# and it is guaranteed that
the refclk would be active at this point. So at the start of this function
(after enabling resources), the controller cleanup can be performed. Once
finished, rest of the code execution for PERST# deassert can continue as
usual.
🎖@cveNotify
🔥1
🚨 CVE-2024-50216
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix finding a last resort AG in xfs_filestream_pick_ag
When the main loop in xfs_filestream_pick_ag fails to find a suitable
AG it tries to just pick the online AG. But the loop for that uses
args->pag as loop iterator while the later code expects pag to be
set. Fix this by reusing the max_pag case for this last resort, and
also add a check for impossible case of no AG just to make sure that
the uninitialized pag doesn't even escape in theory.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
xfs: fix finding a last resort AG in xfs_filestream_pick_ag
When the main loop in xfs_filestream_pick_ag fails to find a suitable
AG it tries to just pick the online AG. But the loop for that uses
args->pag as loop iterator while the later code expects pag to be
set. Fix this by reusing the max_pag case for this last resort, and
also add a check for impossible case of no AG just to make sure that
the uninitialized pag doesn't even escape in theory.
🎖@cveNotify
🚨 CVE-2024-50218
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two
reasons for this: first, the parameter value passed is greater than
ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
ocfs2_truncate_inline are "unsigned int".
So, we need to add a sanity check for byte_start and byte_len right before
ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
than ocfs2_max_inline_data_with_xattr return -EINVAL.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow
Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two
reasons for this: first, the parameter value passed is greater than
ocfs2_max_inline_data_with_xattr, second, the start and end parameters of
ocfs2_truncate_inline are "unsigned int".
So, we need to add a sanity check for byte_start and byte_len right before
ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater
than ocfs2_max_inline_data_with_xattr return -EINVAL.
🎖@cveNotify
🚨 CVE-2024-50289
In the Linux kernel, the following vulnerability has been resolved:
media: av7110: fix a spectre vulnerability
As warned by smatch:
drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)
There is a spectre-related vulnerability at the code. Fix it.
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
media: av7110: fix a spectre vulnerability
As warned by smatch:
drivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap)
There is a spectre-related vulnerability at the code. Fix it.
🎖@cveNotify
🚨 CVE-2024-50295
In the Linux kernel, the following vulnerability has been resolved:
net: arc: fix the device for dma_map_single/dma_unmap_single
The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent
which has dma_mask, ndev->dev.parent is just pdev->dev.
Or it would cause the following issue:
[ 39.933526] ------------[ cut here ]------------
[ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8
🎖@cveNotify
In the Linux kernel, the following vulnerability has been resolved:
net: arc: fix the device for dma_map_single/dma_unmap_single
The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent
which has dma_mask, ndev->dev.parent is just pdev->dev.
Or it would cause the following issue:
[ 39.933526] ------------[ cut here ]------------
[ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8
🎖@cveNotify
🚨 CVE-2024-42330
The HttpRequest object allows to get the HTTP headers from the server's response after sending the request. The problem is that the returned strings are created directly from the data returned by the server and are not correctly encoded for JavaScript. This allows to create internal strings that can be used to access hidden properties of objects.
🎖@cveNotify
The HttpRequest object allows to get the HTTP headers from the server's response after sending the request. The problem is that the returned strings are created directly from the data returned by the server and are not correctly encoded for JavaScript. This allows to create internal strings that can be used to access hidden properties of objects.
🎖@cveNotify
🚨 CVE-2024-42331
In the src/libs/zbxembed/browser.c file, the es_browser_ctor method retrieves a heap pointer from the Duktape JavaScript engine. This heap pointer is subsequently utilized by the browser_push_error method in the src/libs/zbxembed/browser_error.c file. A use-after-free bug can occur at this stage if the wd->browser heap pointer is freed by garbage collection.
🎖@cveNotify
In the src/libs/zbxembed/browser.c file, the es_browser_ctor method retrieves a heap pointer from the Duktape JavaScript engine. This heap pointer is subsequently utilized by the browser_push_error method in the src/libs/zbxembed/browser_error.c file. A use-after-free bug can occur at this stage if the wd->browser heap pointer is freed by garbage collection.
🎖@cveNotify
🚨 CVE-2024-42332
The researcher is showing that due to the way the SNMP trap log is parsed, an attacker can craft an SNMP trap with additional lines of information and have forged data show in the Zabbix UI. This attack requires SNMP auth to be off and/or the attacker to know the community/auth details. The attack requires an SNMP item to be configured as text on the target host.
🎖@cveNotify
The researcher is showing that due to the way the SNMP trap log is parsed, an attacker can craft an SNMP trap with additional lines of information and have forged data show in the Zabbix UI. This attack requires SNMP auth to be off and/or the attacker to know the community/auth details. The attack requires an SNMP item to be configured as text on the target host.
🎖@cveNotify
🚨 CVE-2024-42333
The researcher is showing that it is possible to leak a small amount of Zabbix Server memory using an out of bounds read in src/libs/zbxmedia/email.c
🎖@cveNotify
The researcher is showing that it is possible to leak a small amount of Zabbix Server memory using an out of bounds read in src/libs/zbxmedia/email.c
🎖@cveNotify
🔥1