xamxte/cve-to-cwe huggingface dataset:
CVE-2022-48795: In the Linux kernel, the following vulnerability has been resolved:  parisc: Fix data TLB miss in sba_unmap_sg  Rolf Eike Beer reported the following bug:  [1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018 [1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4 [1274934.746891] Hardware name: 9000/785/C8000 [1274934.746891] [1274934.746891]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI [1274934.746891] PSW: 00001000000001001111111000001110 Not tainted [1274934.746891] r00-03  000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000 [1274934.746891] r04-07  0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001 [1274934.746891] r08-11  0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001 [1274934.746891] r12-15  0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0 [1274934.746891] r16-19  0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007 [1274934.746891] r20-23  0000000000000006 000000004a368950 0000000000000000 0000000000000001 [1274934.746891] r24-27  0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0 [1274934.746891] r28-31  0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118 [1274934.746891] sr00-03  00000000066e5800 0000000000000000 0000000000000000 00000000066e5800 [1274934.746891] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000 [1274934.746891] [1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec [1274934.746891]  IIR: 48780030    ISR: 0000000000000000  IOR: 0000004140000018 [1274934.746891]  CPU:        3   CR30: 00000040e3a9c000 CR31: ffffffffffffffff [1274934.746891]  ORIG_R28: 0000000040acdd58 [1274934.746891]  IAOQ[0]: sba_unmap_sg+0xb0/0x118 [1274934.746891]  IAOQ[1]: sba_unmap_sg+0xb4/0x118 [1274934.746891]  RP(r2): sba_unmap_sg+0xac/0x118 [1274934.746891] Backtrace: [1274934.746891]  [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70 [1274934.746891]  [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60 [1274934.746891]  [<00000000407a3488>] mptscsih_io_done+0x150/0xd70 [1274934.746891]  [<0000000040798600>] mpt_interrupt+0x168/0xa68 [1274934.746891]  [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278 [1274934.746891]  [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8 [1274934.746891]  [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0 [1274934.746891]  [<00000000402548e0>] generic_handle_irq+0x50/0x70 [1274934.746891]  [<000000004019a254>] call_on_stack+0x18/0x24 [1274934.746891] [1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)  The bug is caused by overrunning the sglist and incorrectly testing sg_dma_len(sglist) before nents. Normally this doesn't cause a crash, but in this case sglist crossed a page boundary. This occurs in the following code:   while (sg_dma_len(sglist) && nents--) {  The fix is simply to test nents first and move the decrement of nents into the loop.
CVE-2022-48798: In the Linux kernel, the following vulnerability has been resolved:  s390/cio: verify the driver availability for path_event call  If no driver is attached to a device or the driver does not provide the path_event function, an FCES path-event on this device could end up in a kernel-panic. Verify the driver availability before the path_event function call.
CVE-2022-48802: In the Linux kernel, the following vulnerability has been resolved:  fs/proc: task_mmu.c: don't read mapcount for migration entry  The syzbot reported the below BUG:    kernel BUG at include/linux/page-flags.h:785!   invalid opcode: 0000 [#1] PREEMPT SMP KASAN   CPU: 1 PID: 4392 Comm: syz-executor560 Not tainted 5.16.0-rc6-syzkaller #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011   RIP: 0010:PageDoubleMap include/linux/page-flags.h:785 [inline]   RIP: 0010:__page_mapcount+0x2d2/0x350 mm/util.c:744   Call Trace:     page_mapcount include/linux/mm.h:837 [inline]     smaps_account+0x470/0xb10 fs/proc/task_mmu.c:466     smaps_pte_entry fs/proc/task_mmu.c:538 [inline]     smaps_pte_range+0x611/0x1250 fs/proc/task_mmu.c:601     walk_pmd_range mm/pagewalk.c:128 [inline]     walk_pud_range mm/pagewalk.c:205 [inline]     walk_p4d_range mm/pagewalk.c:240 [inline]     walk_pgd_range mm/pagewalk.c:277 [inline]     __walk_page_range+0xe23/0x1ea0 mm/pagewalk.c:379     walk_page_vma+0x277/0x350 mm/pagewalk.c:530     smap_gather_stats.part.0+0x148/0x260 fs/proc/task_mmu.c:768     smap_gather_stats fs/proc/task_mmu.c:741 [inline]     show_smap+0xc6/0x440 fs/proc/task_mmu.c:822     seq_read_iter+0xbb0/0x1240 fs/seq_file.c:272     seq_read+0x3e0/0x5b0 fs/seq_file.c:162     vfs_read+0x1b5/0x600 fs/read_write.c:479     ksys_read+0x12d/0x250 fs/read_write.c:619     do_syscall_x64 arch/x86/entry/common.c:50 [inline]     do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80     entry_SYSCALL_64_after_hwframe+0x44/0xae  The reproducer was trying to read /proc/$PID/smaps when calling MADV_FREE at the mean time.  MADV_FREE may split THPs if it is called for partial THP.  It may trigger the below race:             CPU A                         CPU B            -----                         -----   smaps walk:                      MADV_FREE:   page_mapcount()     PageCompound()                                    split_huge_page()     page = compound_head(page)     PageDoubleMap(page)  When calling PageDoubleMap() this page is not a tail page of THP anymore so the BUG is triggered.  This could be fixed by elevated refcount of the page before calling mapcount, but that would prevent it from counting migration entries, and it seems overkilling because the race just could happen when PMD is split so all PTE entries of tail pages are actually migration entries, and smaps_account() does treat migration entries as mapcount == 1 as Kirill pointed out.  Add a new parameter for smaps_account() to tell this entry is migration entry then skip calling page_mapcount().  Don't skip getting mapcount for device private entries since they do track references with mapcount.  Pagemap also has the similar issue although it was not reported.  Fixed it as well.  [shy828301@gmail.com: v4] [nathan@kernel.org: avoid unused variable warning in pagemap_pmd_range()]
CVE-2022-48808: In the Linux kernel, the following vulnerability has been resolved:  net: dsa: fix panic when DSA master device unbinds on shutdown  Rafael reports that on a system with LX2160A and Marvell DSA switches, if a reboot occurs while the DSA master (dpaa2-eth) is up, the following panic can be seen:  systemd-shutdown[1]: Rebooting. Unable to handle kernel paging request at virtual address 00a0000800000041 [00a0000800000041] address between user and kernel address ranges Internal error: Oops: 96000004 [#1] PREEMPT SMP CPU: 6 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00042-g8f5585009b24 #32 pc : dsa_slave_netdevice_event+0x130/0x3e4 lr : raw_notifier_call_chain+0x50/0x6c Call trace:  dsa_slave_netdevice_event+0x130/0x3e4  raw_notifier_call_chain+0x50/0x6c  call_netdevice_notifiers_info+0x54/0xa0  __dev_close_many+0x50/0x130  dev_close_many+0x84/0x120  unregister_netdevice_many+0x130/0x710  unregister_netdevice_queue+0x8c/0xd0  unregister_netdev+0x20/0x30  dpaa2_eth_remove+0x68/0x190  fsl_mc_driver_remove+0x20/0x5c  __device_release_driver+0x21c/0x220  device_release_driver_internal+0xac/0xb0  device_links_unbind_consumers+0xd4/0x100  __device_release_driver+0x94/0x220  device_release_driver+0x28/0x40  bus_remove_device+0x118/0x124  device_del+0x174/0x420  fsl_mc_device_remove+0x24/0x40  __fsl_mc_device_remove+0xc/0x20  device_for_each_child+0x58/0xa0  dprc_remove+0x90/0xb0  fsl_mc_driver_remove+0x20/0x5c  __device_release_driver+0x21c/0x220  device_release_driver+0x28/0x40  bus_remove_device+0x118/0x124  device_del+0x174/0x420  fsl_mc_bus_remove+0x80/0x100  fsl_mc_bus_shutdown+0xc/0x1c  platform_shutdown+0x20/0x30  device_shutdown+0x154/0x330  __do_sys_reboot+0x1cc/0x250  __arm64_sys_reboot+0x20/0x30  invoke_syscall.constprop.0+0x4c/0xe0  do_el0_svc+0x4c/0x150  el0_svc+0x24/0xb0  el0t_64_sync_handler+0xa8/0xb0  el0t_64_sync+0x178/0x17c  It can be seen from the stack trace that the problem is that the deregistration of the master causes a dev_close(), which gets notified as NETDEV_GOING_DOWN to dsa_slave_netdevice_event(). But dsa_switch_shutdown() has already run, and this has unregistered the DSA slave interfaces, and yet, the NETDEV_GOING_DOWN handler attempts to call dev_close_many() on those slave interfaces, leading to the problem.  The previous attempt to avoid the NETDEV_GOING_DOWN on the master after dsa_switch_shutdown() was called seems improper. Unregistering the slave interfaces is unnecessary and unhelpful. Instead, after the slaves have stopped being uppers of the DSA master, we can now reset to NULL the master->dsa_ptr pointer, which will make DSA start ignoring all future notifier events on the master.
CVE-2022-48813: In the Linux kernel, the following vulnerability has been resolved:  net: dsa: felix: don't use devres for mdiobus  As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")  mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered.  The Felix VSC9959 switch is a PCI device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here.  If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the felix switch driver on shutdown.  So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all.  The felix driver has the code structure in place for orderly mdiobus removal, so just replace devm_mdiobus_alloc_size() with the non-devres variant, and add manual free where necessary, to ensure that we don't let devres free a still-registered bus.
CVE-2022-48818: In the Linux kernel, the following vulnerability has been resolved:  net: dsa: mv88e6xxx: don't use devres for mdiobus  As explained in commits: 74b6d7d13307 ("net: dsa: realtek: register the MDIO bus under devres") 5135e96a3dd2 ("net: dsa: don't allocate the slave_mii_bus using devres")  mdiobus_free() will panic when called from devm_mdiobus_free() <- devres_release_all() <- __device_release_driver(), and that mdiobus was not previously unregistered.  The mv88e6xxx is an MDIO device, so the initial set of constraints that I thought would cause this (I2C or SPI buses which call ->remove on ->shutdown) do not apply. But there is one more which applies here.  If the DSA master itself is on a bus that calls ->remove from ->shutdown (like dpaa2-eth, which is on the fsl-mc bus), there is a device link between the switch and the DSA master, and device_links_unbind_consumers() will unbind the Marvell switch driver on shutdown.  systemd-shutdown[1]: Powering off. mv88e6085 0x0000000008b96000:00 sw_gl0: Link is Down fsl-mc dpbp.9: Removing from iommu group 7 fsl-mc dpbp.8: Removing from iommu group 7 ------------[ cut here ]------------ kernel BUG at drivers/net/phy/mdio_bus.c:677! Internal error: Oops - BUG: 0 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 1 Comm: systemd-shutdow Not tainted 5.16.5-00040-gdc05f73788e5 #15 pc : mdiobus_free+0x44/0x50 lr : devm_mdiobus_free+0x10/0x20 Call trace:  mdiobus_free+0x44/0x50  devm_mdiobus_free+0x10/0x20  devres_release_all+0xa0/0x100  __device_release_driver+0x190/0x220  device_release_driver_internal+0xac/0xb0  device_links_unbind_consumers+0xd4/0x100  __device_release_driver+0x4c/0x220  device_release_driver_internal+0xac/0xb0  device_links_unbind_consumers+0xd4/0x100  __device_release_driver+0x94/0x220  device_release_driver+0x28/0x40  bus_remove_device+0x118/0x124  device_del+0x174/0x420  fsl_mc_device_remove+0x24/0x40  __fsl_mc_device_remove+0xc/0x20  device_for_each_child+0x58/0xa0  dprc_remove+0x90/0xb0  fsl_mc_driver_remove+0x20/0x5c  __device_release_driver+0x21c/0x220  device_release_driver+0x28/0x40  bus_remove_device+0x118/0x124  device_del+0x174/0x420  fsl_mc_bus_remove+0x80/0x100  fsl_mc_bus_shutdown+0xc/0x1c  platform_shutdown+0x20/0x30  device_shutdown+0x154/0x330  kernel_power_off+0x34/0x6c  __do_sys_reboot+0x15c/0x250  __arm64_sys_reboot+0x20/0x30  invoke_syscall.constprop.0+0x4c/0xe0  do_el0_svc+0x4c/0x150  el0_svc+0x24/0xb0  el0t_64_sync_handler+0xa8/0xb0  el0t_64_sync+0x178/0x17c  So the same treatment must be applied to all DSA switch drivers, which is: either use devres for both the mdiobus allocation and registration, or don't use devres at all.  The Marvell driver already has a good structure for mdiobus removal, so just plug in mdiobus_free and get rid of devres.
CVE-2022-48831: In the Linux kernel, the following vulnerability has been resolved:  ima: fix reference leak in asymmetric_verify()  Don't leak a reference to the key if its algorithm is unknown.
CVE-2022-48832: In the Linux kernel, the following vulnerability has been resolved:  audit: don't deref the syscall args when checking the openat2 open_how::flags  As reported by Jeff, dereferencing the openat2 syscall argument in audit_match_perm() to obtain the open_how::flags can result in an oops/page-fault.  This patch fixes this by using the open_how struct that we store in the audit_context with audit_openat2_how().  Independent of this patch, Richard Guy Briggs posted a similar patch to the audit mailing list roughly 40 minutes after this patch was posted.
CVE-2022-48836: In the Linux kernel, the following vulnerability has been resolved:  Input: aiptek - properly check endpoint type  Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. There was a check for the number of endpoints, but not for the type of endpoint.  Fix it by replacing old desc.bNumEndpoints check with usb_find_common_endpoints() helper for finding endpoints  Fail log:  usb 5-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 2 PID: 48 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 2 PID: 48 Comm: kworker/2:2 Not tainted 5.17.0-rc6-syzkaller-00226-g07ebd38a0da2 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 Workqueue: usb_hub_wq hub_event ... Call Trace:  <TASK>  aiptek_open+0xd5/0x130 drivers/input/tablet/aiptek.c:830  input_open_device+0x1bb/0x320 drivers/input/input.c:629  kbd_connect+0xfe/0x160 drivers/tty/vt/keyboard.c:1593
CVE-2022-48848: In the Linux kernel, the following vulnerability has been resolved:  tracing/osnoise: Do not unregister events twice  Nicolas reported that using:   # trace-cmd record -e all -M 10 -p osnoise --poll  Resulted in the following kernel warning:   ------------[ cut here ]------------  WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370  [...]  CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19  RIP: 0010:tracepoint_probe_unregister+0x280/0x370  [...]  CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0  Call Trace:   <TASK>   osnoise_workload_stop+0x36/0x90   tracing_set_tracer+0x108/0x260   tracing_set_trace_write+0x94/0xd0   ? __check_object_size.part.0+0x10a/0x150   ? selinux_file_permission+0x104/0x150   vfs_write+0xb5/0x290   ksys_write+0x5f/0xe0   do_syscall_64+0x3b/0x90   entry_SYSCALL_64_after_hwframe+0x44/0xae  RIP: 0033:0x7ff919a18127  [...]  ---[ end trace 0000000000000000 ]---  The warning complains about an attempt to unregister an unregistered tracepoint.  This happens on trace-cmd because it first stops tracing, and then switches the tracer to nop. Which is equivalent to:    # cd /sys/kernel/tracing/   # echo osnoise > current_tracer   # echo 0 > tracing_on   # echo nop > current_tracer  The osnoise tracer stops the workload when no trace instance is actually collecting data. This can be caused both by disabling tracing or disabling the tracer itself.  To avoid unregistering events twice, use the existing trace_osnoise_callback_enabled variable to check if the events (and the workload) are actually active before trying to deactivate them.
CVE-2022-48852: In the Linux kernel, the following vulnerability has been resolved:  drm/vc4: hdmi: Unregister codec device on unbind  On bind we will register the HDMI codec device but we don't unregister it on unbind, leading to a device leakage. Unregister our device at unbind.
CVE-2022-48853: In the Linux kernel, the following vulnerability has been resolved:  swiotlb: fix info leak with DMA_FROM_DEVICE  The problem I'm addressing was discovered by the LTP test covering cve-2018-1000204.  A short description of what happens follows: 1) The test case issues a command code 00 (TEST UNIT READY) via the SG_IO    interface with: dxfer_len == 524288, dxdfer_dir == SG_DXFER_FROM_DEV    and a corresponding dxferp. The peculiar thing about this is that TUR    is not reading from the device. 2) In sg_start_req() the invocation of blk_rq_map_user() effectively    bounces the user-space buffer. As if the device was to transfer into    it. Since commit a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in    sg_build_indirect()") we make sure this first bounce buffer is    allocated with GFP_ZERO. 3) For the rest of the story we keep ignoring that we have a TUR, so the    device won't touch the buffer we prepare as if the we had a    DMA_FROM_DEVICE type of situation. My setup uses a virtio-scsi device    and the  buffer allocated by SG is mapped by the function    virtqueue_add_split() which uses DMA_FROM_DEVICE for the "in" sgs (here    scatter-gather and not scsi generics). This mapping involves bouncing    via the swiotlb (we need swiotlb to do virtio in protected guest like    s390 Secure Execution, or AMD SEV). 4) When the SCSI TUR is done, we first copy back the content of the second    (that is swiotlb) bounce buffer (which most likely contains some    previous IO data), to the first bounce buffer, which contains all    zeros.  Then we copy back the content of the first bounce buffer to    the user-space buffer. 5) The test case detects that the buffer, which it zero-initialized,   ain't all zeros and fails.  One can argue that this is an swiotlb problem, because without swiotlb we leak all zeros, and the swiotlb should be transparent in a sense that it does not affect the outcome (if all other participants are well behaved).  Copying the content of the original buffer into the swiotlb buffer is the only way I can think of to make swiotlb transparent in such scenarios. So let's do just that if in doubt, but allow the driver to tell us that the whole mapped buffer is going to be overwritten, in which case we can preserve the old behavior and avoid the performance impact of the extra bounce.
CVE-2024-21128: Vulnerability in the Oracle Application Object Library product of Oracle E-Business Suite (component: APIs).  Supported versions that are affected are 12.2.6-12.2.13. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Application Object Library.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Application Object Library, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Application Object Library accessible data as well as  unauthorized read access to a subset of Oracle Application Object Library accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).
CVE-2024-21139: Vulnerability in the Oracle Business Intelligence Enterprise Edition product of Oracle Analytics (component: Analytics Web Answers).  Supported versions that are affected are 7.0.0.0.0, 7.6.0.0.0 and  12.2.1.4.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Business Intelligence Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Business Intelligence Enterprise Edition, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Business Intelligence Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Business Intelligence Enterprise Edition accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).
CVE-2024-21148: Vulnerability in the Oracle Applications Framework product of Oracle E-Business Suite (component: Personalization).  Supported versions that are affected are 12.2.3-12.2.13. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Applications Framework.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Applications Framework, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Applications Framework accessible data as well as  unauthorized read access to a subset of Oracle Applications Framework accessible data. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N).
CVE-2024-21181: Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Core).  Supported versions that are affected are 12.2.1.4.0 and  14.1.1.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via T3, IIOP to compromise Oracle WebLogic Server.  Successful attacks of this vulnerability can result in takeover of Oracle WebLogic Server. CVSS 3.1 Base Score 9.8 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).
CVE-2024-6833: A vulnerability in Zowe CLI allows local, privileged actors to store previously entered secure credentials in a plaintext file as part of an auto-init operation.
CVE-2024-5726: The Timeline Event History plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.1 via deserialization of untrusted input 'timelines-data' parameter. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject a PHP Object. No known POP chain is present in the vulnerable software. If a POP chain is present via an additional plugin or theme installed on the target system, it could allow the attacker to delete arbitrary files, retrieve sensitive data, or execute code.
CVE-2024-5964: The Zenon Lite theme for WordPress is vulnerable to Stored Cross-Site Scripting via the ‘url’ parameter within the theme's Button shortcode in all versions up to, and including, 1.9 due to insufficient input sanitization and output escaping. This makes it possible for authenticated attackers, with Contributor-level access and above, to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page.
CVE-2024-6175: The Booking Ultra Pro Appointments Booking Calendar Plugin plugin for WordPress is vulnerable to unauthorized modification of data due to a missing capability check on the multiple functions in all versions up to, and including, 1.1.13. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify and delete. multiple plugin options and data such as payments, pricing, booking information, business hours, calendars, profile information, and email templates.