Vulnerabilidades

*** Pendiente de traducción *** An arbitrary file upload vulnerability in Umbraco CMS v16.3.3 allows attackers to execute arbitrary code by uploading a crafted PDF file. NOTE: this is disputed by the Supplier because the responsibility for file validation (as shown in the documentation) belongs to the system administrator who is implementing Umbraco CMS in their environment, not to Umbraco CMS itself, a related issue to CVE-2023-49279.

*** Pendiente de traducción *** A vulnerability in WooCommerce 8.1 to 10.4.2 can allow logged-in customers to access order data of guest customers on sites with a certain configuration. This has been fixed in WooCommerce 10.4.3, as well as all the previously affected versions through point releases, starting from 8.1, where it has been fixed in 8.1.3. It does not affect WooCommerce 8.0 or earlier.

*** Pendiente de traducción *** An error in the SignServer container startup logic was found in Keyfactor SignServer versions prior to 7.2. The Admin CLI command used to configure Certificate access to the initial startup of the container sets a property of "allowany" to allow any user with a valid and trusted client auth certificate to connect. Admins can then set more restricted access to specific certificates. A logic error caused this admin CLI command to be run on each restart of the container instead of only the first startup as intended resetting the configuration to "allowany".

*** Pendiente de traducción *** MyNET up to v26.08 was discovered to contain a Reflected cross-site scripting (XSS) vulnerability via the msgtipo parameter.

*** Pendiente de traducción *** MyNET up to v26.05 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the msg parameter.

*** Pendiente de traducción *** A Local File Inclusion (LFI) vulnerability exists in the Webmail Classic UI of Zimbra Collaboration (ZCS) 10.0 and 10.1 because of improper handling of user-supplied request parameters in the RestFilter servlet. An unauthenticated remote attacker can craft requests to the /h/rest endpoint to influence internal request dispatching, allowing inclusion of arbitrary files from the WebRoot directory.

*** Pendiente de traducción *** An arbitrary file upload vulnerability in the Attachments module of Frappe Framework v15.89.0 allows attackers to execute arbitrary code via uploading a crafted XML file.

*** Pendiente de traducción *** Reflected cross-site scripting (XSS) vulnerability in ClinCapture EDC 3.0 and 2.2.3, allowing an unauthenticated remote attacker to execute JavaScript code in the context of the victim's browser.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/pmc: Add support for Van Gogh SoC<br /> <br /> The ROG Xbox Ally (non-X) SoC features a similar architecture to the<br /> Steam Deck. While the Steam Deck supports S3 (s2idle causes a crash),<br /> this support was dropped by the Xbox Ally which only S0ix suspend.<br /> <br /> Since the handler is missing here, this causes the device to not suspend<br /> and the AMD GPU driver to crash while trying to resume afterwards due to<br /> a power hang.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> comedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()<br /> <br /> Syzbot identified an issue [1] in pcl818_ai_cancel(), which stems from<br /> the fact that in case of early device detach via pcl818_detach(),<br /> subdevice dev-&gt;read_subdev may not have initialized its pointer to<br /> &amp;struct comedi_async as intended. Thus, any such dereferencing of<br /> &amp;s-&gt;async-&gt;cmd will lead to general protection fault and kernel crash.<br /> <br /> Mitigate this problem by removing a call to pcl818_ai_cancel() from<br /> pcl818_detach() altogether. This way, if the subdevice setups its<br /> support for async commands, everything async-related will be<br /> handled via subdevice&amp;#39;s own -&gt;cancel() function in<br /> comedi_device_detach_locked() even before pcl818_detach(). If no<br /> support for asynchronous commands is provided, there is no need<br /> to cancel anything either.<br /> <br /> [1] Syzbot crash:<br /> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> CPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025<br /> RIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762<br /> ...<br /> Call Trace:<br /> <br /> pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115<br /> comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207<br /> do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline]<br /> comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> ...

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> locking/spinlock/debug: Fix data-race in do_raw_write_lock<br /> <br /> KCSAN reports:<br /> <br /> BUG: KCSAN: data-race in do_raw_write_lock / do_raw_write_lock<br /> <br /> write (marked) to 0xffff800009cf504c of 4 bytes by task 1102 on cpu 1:<br /> do_raw_write_lock+0x120/0x204<br /> _raw_write_lock_irq<br /> do_exit<br /> call_usermodehelper_exec_async<br /> ret_from_fork<br /> <br /> read to 0xffff800009cf504c of 4 bytes by task 1103 on cpu 0:<br /> do_raw_write_lock+0x88/0x204<br /> _raw_write_lock_irq<br /> do_exit<br /> call_usermodehelper_exec_async<br /> ret_from_fork<br /> <br /> value changed: 0xffffffff -&gt; 0x00000001<br /> <br /> Reported by Kernel Concurrency Sanitizer on:<br /> CPU: 0 PID: 1103 Comm: kworker/u4:1 6.1.111<br /> <br /> Commit 1a365e822372 ("locking/spinlock/debug: Fix various data races") has<br /> adressed most of these races, but seems to be not consistent/not complete.<br /> <br /> &gt;From do_raw_write_lock() only debug_write_lock_after() part has been<br /> converted to WRITE_ONCE(), but not debug_write_lock_before() part.<br /> Do it now.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted<br /> <br /> There&amp;#39;s issue when file system corrupted:<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/jbd2/transaction.c:1289!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next<br /> RIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0<br /> RSP: 0018:ffff888117aafa30 EFLAGS: 00010202<br /> RAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534<br /> RDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010<br /> RBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028<br /> R10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000<br /> R13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0<br /> Call Trace:<br /> <br /> __ext4_journal_get_create_access+0x42/0x170<br /> ext4_getblk+0x319/0x6f0<br /> ext4_bread+0x11/0x100<br /> ext4_append+0x1e6/0x4a0<br /> ext4_init_new_dir+0x145/0x1d0<br /> ext4_mkdir+0x326/0x920<br /> vfs_mkdir+0x45c/0x740<br /> do_mkdirat+0x234/0x2f0<br /> __x64_sys_mkdir+0xd6/0x120<br /> do_syscall_64+0x5f/0xfa0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The above issue occurs with us in errors=continue mode when accompanied by<br /> storage failures. There have been many inconsistencies in the file system<br /> data.<br /> In the case of file system data inconsistency, for example, if the block<br /> bitmap of a referenced block is not set, it can lead to the situation where<br /> a block being committed is allocated and used again. As a result, the<br /> following condition will not be satisfied then trigger BUG_ON. Of course,<br /> it is entirely possible to construct a problematic image that can trigger<br /> this BUG_ON through specific operations. In fact, I have constructed such<br /> an image and easily reproduced this issue.<br /> Therefore, J_ASSERT() holds true only under ideal conditions, but it may<br /> not necessarily be satisfied in exceptional scenarios. Using J_ASSERT()<br /> directly in abnormal situations would cause the system to crash, which is<br /> clearly not what we want. So here we directly trigger a JBD abort instead<br /> of immediately invoking BUG_ON.