rainbutterfly/cve_corpus huggingface dataset:
CVE-2023-53714 drm/stm: ltdc: fix late dereference check
In the Linux kernel, the following vulnerability has been resolved:

drm/stm: ltdc: fix late dereference check

In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a
container_of() before the pointer check. This could cause a kernel panic.

Fix this smatch warning:
drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable dereferenced before check 'crtc' (see line 1119)
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:48.341Z
CVE-2023-53715 wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex
In the Linux kernel, the following vulnerability has been resolved:

wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex

Apparently the hex passphrase mechanism does not work on newer
chips/firmware (e.g. BCM4387). It seems there was a simple way of
passing it in binary all along, so use that and avoid the hexification.

OpenBSD has been doing it like this from the beginning, so this should
work on all chips.

Also clear the structure before setting the PMK. This was leaking
uninitialized stack contents to the device.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:48.905Z
CVE-2023-53716 net: fix skb leak in __skb_tstamp_tx()
In the Linux kernel, the following vulnerability has been resolved:

net: fix skb leak in __skb_tstamp_tx()

Commit 50749f2dd685 ("tcp/udp: Fix memleaks of sk and zerocopy skbs with
TX timestamp.") added a call to skb_orphan_frags_rx() to fix leaks with
zerocopy skbs. But it ended up adding a leak of its own. When
skb_orphan_frags_rx() fails, the function just returns, leaking the skb
it just cloned. Free it before returning.

This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: unaffected
Published: 2025-10-22T13:23:49.536Z
CVE-2023-53717 wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath9k: Fix potential stack-out-of-bounds write in ath9k_wmi_rsp_callback()

Fix a stack-out-of-bounds write that occurs in a WMI response callback
function that is called after a timeout occurs in ath9k_wmi_cmd().
The callback writes to wmi->cmd_rsp_buf, a stack-allocated buffer that
could no longer be valid when a timeout occurs. Set wmi->last_seq_id to
0 when a timeout occurred.

Found by a modified version of syzkaller.

BUG: KASAN: stack-out-of-bounds in ath9k_wmi_ctrl_rx
Write of size 4
Call Trace:
 memcpy
 ath9k_wmi_ctrl_rx
 ath9k_htc_rx_msg
 ath9k_hif_usb_reg_in_cb
 __usb_hcd_giveback_urb
 usb_hcd_giveback_urb
 dummy_timer
 call_timer_fn
 run_timer_softirq
 __do_softirq
 irq_exit_rcu
 sysvec_apic_timer_interrupt
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:50.161Z
CVE-2023-53719 serial: arc_uart: fix of_iomap leak in `arc_serial_probe`
In the Linux kernel, the following vulnerability has been resolved:

serial: arc_uart: fix of_iomap leak in `arc_serial_probe`

Smatch reports:

drivers/tty/serial/arc_uart.c:631 arc_serial_probe() warn:
'port->membase' from of_iomap() not released on lines: 631.

In arc_serial_probe(), if uart_add_one_port() fails,
port->membase is not released, which would cause a resource leak.

To fix this, I replace of_iomap with devm_platform_ioremap_resource.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:51.441Z
CVE-2023-53720 net/mlx5e: Release the label when replacing existing ct entry
In the Linux kernel, the following vulnerability has been resolved:

net/mlx5e: Release the label when replacing existing ct entry

Cited commit doesn't release the label mapping when replacing existing ct
entry which leads to following memleak report:

unreferenced object 0xffff8881854cf280 (size 96):
  comm "kworker/u48:74", pid 23093, jiffies 4296664564 (age 175.944s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<000000002722d368>] __kmalloc+0x4b/0x1c0
    [<00000000cc44e18f>] mapping_add+0x6e8/0xc90 [mlx5_core]
    [<000000003ad942a7>] mlx5_get_label_mapping+0x66/0xe0 [mlx5_core]
    [<00000000266308ac>] mlx5_tc_ct_entry_create_mod_hdr+0x1c4/0xf50 [mlx5_core]
    [<000000009a768b4f>] mlx5_tc_ct_entry_add_rule+0x16f/0xaf0 [mlx5_core]
    [<00000000a178f3e5>] mlx5_tc_ct_block_flow_offload_add+0x10cb/0x1f90 [mlx5_core]
    [<000000007b46c496>] mlx5_tc_ct_block_flow_offload+0x14a/0x630 [mlx5_core]
    [<00000000a9a18ac5>] nf_flow_offload_tuple+0x1a3/0x390 [nf_flow_table]
    [<00000000d0881951>] flow_offload_work_handler+0x257/0xd30 [nf_flow_table]
    [<000000009e4935a4>] process_one_work+0x7c2/0x13e0
    [<00000000f5cd36a7>] worker_thread+0x59d/0xec0
    [<00000000baed1daf>] kthread+0x28f/0x330
    [<0000000063d282a4>] ret_from_fork+0x1f/0x30

Fix the issue by correctly releasing the label mapping.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:52.123Z
CVE-2023-53721 wifi: ath12k: Fix a NULL pointer dereference in ath12k_mac_op_hw_scan()
In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Fix a NULL pointer dereference in ath12k_mac_op_hw_scan()

In ath12k_mac_op_hw_scan(), the return value of kzalloc() is directly
used in memcpy(), which may lead to a NULL pointer dereference on
failure of kzalloc().

Fix this bug by adding a check of arg.extraie.ptr.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0-03427-QCAHMTSWPL_V1.0_V2.0_SILICONZ-1.15378.4
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:52.699Z
CVE-2023-53722 md: raid1: fix potential OOB in raid1_remove_disk()
In the Linux kernel, the following vulnerability has been resolved:

md: raid1: fix potential OOB in raid1_remove_disk()

If rddev->raid_disk is greater than mddev->raid_disks, there will be
an out-of-bounds in raid1_remove_disk(). We have already found
similar reports as follows:

1) commit d17f744e883b ("md-raid10: fix KASAN warning")
2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")

Fix this bug by checking whether the "number" variable is
valid.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:53.329Z
CVE-2023-53723 drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend
In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: disable sdma ecc irq only when sdma RAS is enabled in suspend

sdma_v4_0_ip is shared on a few asics, but in sdma_v4_0_hw_fini,
driver unconditionally disables ecc_irq which is only enabled on
those asics enabling sdma ecc. This will introduce a warning in
suspend cycle on those chips with sdma ip v4.0, while without
sdma ecc. So this patch correct this.

[ 7283.166354] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]
[ 7283.167001] RSP: 0018:ffff9a5fc3967d08 EFLAGS: 00010246
[ 7283.167019] RAX: ffff98d88afd3770 RBX: 0000000000000001 RCX: 0000000000000000
[ 7283.167023] RDX: 0000000000000000 RSI: ffff98d89da30390 RDI: ffff98d89da20000
[ 7283.167025] RBP: ffff98d89da20000 R08: 0000000000036838 R09: 0000000000000006
[ 7283.167028] R10: ffffd5764243c008 R11: 0000000000000000 R12: ffff98d89da30390
[ 7283.167030] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105
[ 7283.167032] FS:  0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000
[ 7283.167036] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 7283.167039] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0
[ 7283.167041] Call Trace:
[ 7283.167046]  <TASK>
[ 7283.167048]  sdma_v4_0_hw_fini+0x38/0xa0 [amdgpu]
[ 7283.167704]  amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]
[ 7283.168296]  amdgpu_device_suspend+0x103/0x180 [amdgpu]
[ 7283.168875]  amdgpu_pmops_freeze+0x21/0x60 [amdgpu]
[ 7283.169464]  pci_pm_freeze+0x54/0xc0
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:53.900Z
CVE-2023-53724 mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read()
In the Linux kernel, the following vulnerability has been resolved:

mfd: pcf50633-adc: Fix potential memleak in pcf50633_adc_async_read()

`req` is allocated in pcf50633_adc_async_read(), but
adc_enqueue_request() could fail to insert the `req` into queue.
We need to check the return value and free it in the case of failure.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:54.542Z
CVE-2023-53725 clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe
In the Linux kernel, the following vulnerability has been resolved:

clocksource/drivers/cadence-ttc: Fix memory leak in ttc_timer_probe

Smatch reports:
drivers/clocksource/timer-cadence-ttc.c:529 ttc_timer_probe()
warn: 'timer_baseaddr' from of_iomap() not released on lines: 498,508,516.

timer_baseaddr may have the problem of not being released after use,
I replaced it with the devm_of_iomap() function and added the clk_put()
function to cleanup the "clk_ce" and "clk_cs".
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:55.200Z
CVE-2023-53726 arm64: csum: Fix OoB access in IP checksum code for negative lengths
In the Linux kernel, the following vulnerability has been resolved:

arm64: csum: Fix OoB access in IP checksum code for negative lengths

Although commit c2c24edb1d9c ("arm64: csum: Fix pathological zero-length
calls") added an early return for zero-length input, syzkaller has
popped up with an example of a _negative_ length which causes an
undefined shift and an out-of-bounds read:

 | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39
 | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975
 |
 | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0
 | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023
 | Call trace:
 |  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
 |  show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
 |  __dump_stack lib/dump_stack.c:88 [inline]
 |  dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
 |  print_address_description mm/kasan/report.c:351 [inline]
 |  print_report+0x174/0x514 mm/kasan/report.c:462
 |  kasan_report+0xd4/0x130 mm/kasan/report.c:572
 |  kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187
 |  __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31
 |  do_csum+0x44/0x254 arch/arm64/lib/csum.c:39
 |  csum_partial+0x30/0x58 lib/checksum.c:128
 |  gso_make_checksum include/linux/skbuff.h:4928 [inline]
 |  __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332
 |  udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47
 |  ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119
 |  skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141
 |  __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401
 |  skb_gso_segment include/linux/netdevice.h:4859 [inline]
 |  validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659
 |  validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709
 |  sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327
 |  __dev_xmit_skb net/core/dev.c:3805 [inline]
 |  __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210
 |  dev_queue_xmit include/linux/netdevice.h:3085 [inline]
 |  packet_xmit+0x6c/0x318 net/packet/af_packet.c:276
 |  packet_snd net/packet/af_packet.c:3081 [inline]
 |  packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113
 |  sock_sendmsg_nosec net/socket.c:724 [inline]
 |  sock_sendmsg net/socket.c:747 [inline]
 |  __sys_sendto+0x3b4/0x538 net/socket.c:2144

Extend the early return to reject negative lengths as well, aligning our
implementation with the generic code in lib/checksum.c
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:55.896Z
CVE-2023-53727 net/sched: fq_pie: avoid stalls in fq_pie_timer()
In the Linux kernel, the following vulnerability has been resolved:

net/sched: fq_pie: avoid stalls in fq_pie_timer()

When setting a high number of flows (limit being 65536),
fq_pie_timer() is currently using too much time as syzbot reported.

Add logic to yield the cpu every 2048 flows (less than 150 usec
on debug kernels).
It should also help by not blocking qdisc fast paths for too long.
Worst case (65536 flows) would need 31 jiffies for a complete scan.

Relevant extract from syzbot report:

rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 0-.... } 2663 jiffies s: 873 root: 0x1/.
rcu: blocking rcu_node structures (internal RCU debug):
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 5177 Comm: syz-executor273 Not tainted 6.5.0-syzkaller-00453-g727dbda16b83 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
RIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]
RIP: 0010:write_comp_data+0x21/0x90 kernel/kcov.c:236
Code: 2e 0f 1f 84 00 00 00 00 00 65 8b 05 01 b2 7d 7e 49 89 f1 89 c6 49 89 d2 81 e6 00 01 00 00 49 89 f8 65 48 8b 14 25 80 b9 03 00 <a9> 00 01 ff 00 74 0e 85 f6 74 59 8b 82 04 16 00 00 85 c0 74 4f 8b
RSP: 0018:ffffc90000007bb8 EFLAGS: 00000206
RAX: 0000000000000101 RBX: ffffc9000dc0d140 RCX: ffffffff885893b0
RDX: ffff88807c075940 RSI: 0000000000000100 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffffc9000dc0d178
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000555555d54380(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6b442f6130 CR3: 000000006fe1c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 <NMI>
 </NMI>
 <IRQ>
 pie_calculate_probability+0x480/0x850 net/sched/sch_pie.c:415
 fq_pie_timer+0x1da/0x4f0 net/sched/sch_fq_pie.c:387
 call_timer_fn+0x1a0/0x580 kernel/time/timer.c:1700
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:56.528Z
CVE-2023-53728 posix-timers: Ensure timer ID search-loop limit is valid
In the Linux kernel, the following vulnerability has been resolved:

posix-timers: Ensure timer ID search-loop limit is valid

posix_timer_add() tries to allocate a posix timer ID by starting from the
cached ID which was stored by the last successful allocation.

This is done in a loop searching the ID space for a free slot one by
one. The loop has to terminate when the search wrapped around to the
starting point.

But that's racy vs. establishing the starting point. That is read out
lockless, which leads to the following problem:

CPU0	  	      	     	   CPU1
posix_timer_add()
  start = sig->posix_timer_id;
  lock(hash_lock);
  ...				   posix_timer_add()
  if (++sig->posix_timer_id < 0)
      			             start = sig->posix_timer_id;
     sig->posix_timer_id = 0;

So CPU1 can observe a negative start value, i.e. -1, and the loop break
never happens because the condition can never be true:

  if (sig->posix_timer_id == start)
     break;

While this is unlikely to ever turn into an endless loop as the ID space is
huge (INT_MAX), the racy read of the start value caught the attention of
KCSAN and Dmitry unearthed that incorrectness.

Rewrite it so that all id operations are under the hash lock.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:57.127Z
CVE-2023-53729 soc: qcom: qmi_encdec: Restrict string length in decode
In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: qmi_encdec: Restrict string length in decode

The QMI TLV value for strings in a lot of qmi element info structures
account for null terminated strings with MAX_LEN + 1. If a string is
actually MAX_LEN + 1 length, this will cause an out of bounds access
when the NULL character is appended in decoding.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:57.739Z
CVE-2023-53731 netlink: fix potential deadlock in netlink_set_err()
In the Linux kernel, the following vulnerability has been resolved:

netlink: fix potential deadlock in netlink_set_err()

syzbot reported a possible deadlock in netlink_set_err() [1]

A similar issue was fixed in commit 1d482e666b8e ("netlink: disable IRQs
for netlink_lock_table()") in netlink_lock_table()

This patch adds IRQ safety to netlink_set_err() and __netlink_diag_dump()
which were not covered by cited commit.

[1]

WARNING: possible irq lock inversion dependency detected
6.4.0-rc6-syzkaller-00240-g4e9f0ec38852 #0 Not tainted

syz-executor.2/23011 just changed the state of lock:
ffffffff8e1a7a58 (nl_table_lock){.+.?}-{2:2}, at: netlink_set_err+0x2e/0x3a0 net/netlink/af_netlink.c:1612
but this lock was taken by another, SOFTIRQ-safe lock in the past:
 (&local->queue_stop_reason_lock){..-.}-{2:2}

and interrupts could create inverse lock ordering between them.

other info that might help us debug this:
 Possible interrupt unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(nl_table_lock);
                               local_irq_disable();
                               lock(&local->queue_stop_reason_lock);
                               lock(nl_table_lock);
  <Interrupt>
    lock(&local->queue_stop_reason_lock);

 *** DEADLOCK ***
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:59.055Z
CVE-2023-53732 fs/ntfs3: Fix NULL dereference in ni_write_inode
In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: Fix NULL dereference in ni_write_inode

Syzbot reports a NULL dereference in ni_write_inode.
When creating a new inode, if allocation fails in mi_init function
(called in mi_format_new function), mi->mrec is set to NULL.
In the error path of this inode creation, mi->mrec is later
dereferenced in ni_write_inode.

Add a NULL check to prevent NULL dereference.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-22T13:23:59.630Z
CVE-2023-53733 net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knode
In the Linux kernel, the following vulnerability has been resolved:

net: sched: cls_u32: Undo tcf_bind_filter if u32_replace_hw_knode

When u32_replace_hw_knode fails, we need to undo the tcf_bind_filter
operation done at u32_set_parms.
Affected products: vendor: Linux
product: Linux
default_status: unaffected
vendor: Linux
product: Linux
default_status: affected
Published: 2025-10-24T11:44:28.115Z
CVE-2023-53734 dawa-pharma-1.0 - SQL Injection via Email Parameter
dawa-pharma-1.0 allows unauthenticated attackers to execute SQL queries on the server, allowing them to access sensitive information and potentially gain administrative access.
Problem types: cwe_id: CWE-89
description: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Affected products: vendor: mayurik
product: dawa-pharma
default_status: unaffected
Credits: lang: en
value: nu11secur1ty
Published: 2025-12-04T20:40:13.555Z
CVE-2023-53735 WEBIGniter 28.7.23 Cross-Site Scripting (XSS) in User Creation Process
WEBIGniter 28.7.23 contains a cross-site scripting vulnerability in the user creation process that allows unauthenticated attackers to execute malicious JavaScript code, enabling potential XSS attacks.
Problem types: cwe_id: CWE-79
description: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected products: vendor: WEBIGniter
product: WEBIGniter
default_status: unaffected
Credits: lang: en
value: RedTeamer IT Security, Mesut Cetin
Published: 2025-12-04T20:40:46.933Z
CVE-2023-53736 Kentico Xperience <= 13.0.120 Administration Interface Reflected XSS
A reflected cross-site scripting vulnerability in Kentico Xperience allows authenticated users to inject malicious scripts in the administration interface. Attackers can exploit this vulnerability to execute arbitrary scripts within the administrative context.
Problem types: cwe_id: CWE-79
description: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected products: vendor: Kentico
product: Xperience
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 5.4
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: LOW
privilegesRequired: LOW
scope: CHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
version: 3.1
Credits: lang: en
value: James Taylor | Cantarus
Published: 2025-12-18T19:53:30.487Z
CVE-2023-53737 Kentico Xperience <= 13.0.101 Localization Application Stored XSS
A stored cross-site scripting vulnerability in Kentico Xperience allows global administrators to inject malicious payloads via the Localization application. Attackers can execute scripts that could affect multiple parts of the administration interface.
Problem types: cwe_id: CWE-79
description: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected products: vendor: Kentico
product: Xperience
default_status: unaffected
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 4.8
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: LOW
privilegesRequired: HIGH
scope: CHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N
version: 3.1
Credits: lang: en
value: Kentico Security Team
Published: 2025-12-18T19:53:30.896Z
CVE-2023-53738 Kentico Xperience <= 13.0.109 Page Preview Reflected XSS
A reflected cross-site scripting vulnerability in Kentico Xperience allows authenticated users to inject malicious scripts via page preview URLs. Attackers can exploit this vulnerability to execute arbitrary scripts in users' browsers during page preview interactions.
Problem types: cwe_id: CWE-79
description: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Affected products: vendor: Kentico
product: Xperience
CVSS v3.1: attackComplexity: LOW
attackVector: NETWORK
availabilityImpact: NONE
baseScore: 5.4
baseSeverity: MEDIUM
confidentialityImpact: LOW
integrityImpact: LOW
privilegesRequired: LOW
scope: CHANGED
userInteraction: REQUIRED
vectorString: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
version: 3.1
Published: 2025-12-18T19:53:31.326Z