Vulnerabilidades

*** Pendiente de traducción *** An incomplete fix for CVE-2026-50645 means that it is still possible to perform a denial of service attack on Apache CXF by sending a message with many attachment headers. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

*** Pendiente de traducción *** Apache CXF reads a top-level WSDL through its hardened StaxUtils path, which disables XML DTDs and external entities. However, any  or  referenced from that top-level WSDL is handed off to WSDL4J, which does not disable DOCTYPE declarations or external entities. As a result, the protections applied to the top-level document do not extend to imported documents, leaving imported WSDL/XSD content vulnerable to XML External Entity (XXE) attacks. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

*** Pendiente de traducción *** Apache CXF's JMS transport deserializes the body of any inbound JMS ObjectMessage using native Java deserialization, with no type restrictions in place. Any attacker able to place a message on the service's JMS destination can submit a malicious serialized object, leading to denial of service or, if a suitable gadget class is on the classpath, remote code execution. The fix disables ObjectMessage deserialization by default, with a configuration switch to re-enable it if needed. Users are recommended to upgrade to versions 4.2.3 or 4.1.8 or 3.6.12, which fix this issue.

*** Pendiente de traducción *** A vulnerability was determined in Shibby Tomato 1.28.0000. Affected by this vulnerability is the function new_qoslimit_stop of the file /tmp/qoslimittc_stop.sh. Executing a manipulation of the argument wan_iface can lead to os command injection. The attack can be launched remotely. The exploit has been publicly disclosed and may be utilized. This project is superseded by FreshTomato.

*** Pendiente de traducción *** An improper access control check in CatchPulse's named pipe communication interface could allow an attacker to invoke CatchPulse functions. This is limited to operations that enforce more restrictive security policies.

*** Pendiente de traducción *** A denial-of-service vulnerability in CatchPulse could allow an attacker to conduct a stack buffer overrun attack, leading to a denial-of-service condition.

*** Pendiente de traducción *** An improper access control vulnerability in CatchPulse could allow a non-administrative local attacker to connect to an unrestricted kernel filter communication port and bypass CatchPulse's security policy enforcement.

*** Pendiente de traducción *** A vulnerability was determined in OpenHands up to 0.62.0. The affected element is the function initialize_repo of the file OpenHands/resolver/send_pull_request.py. This manipulation causes command injection. Remote exploitation of the attack is possible. The vendor deleted the original GitHub issue report. It appears that the affected path/file got removed in version 1.7.0.

*** Pendiente de traducción *** Apache Polaris did not consistently validate storage locations supplied during table and view registration.<br /> <br /> An authenticated principal with permission to register a table or view could, depending on the affected release and registration path, cause Polaris to use the catalog&amp;#39;s storage credentials to read a caller-selected Iceberg metadata file before verifying that the file was within the catalog&amp;#39;s allowed storage locations.<br /> <br /> If the catalog&amp;#39;s underlying credentials could read an object outside that boundary, this could disclose limited information from the object.<br /> <br /> <br /> Polaris could also accept registration metadata located within an allowed location that contained references to storage locations outside the allowed boundary.<br /> <br /> This second condition did not itself cause Polaris to read the referenced external locations during registration.<br /> <br /> <br /> The demonstrated impact is limited to confidentiality.<br /> <br /> No unauthorized data modification or availability impact has been demonstrated.<br /> <br /> <br /> The server-side read requires a deployment using S3 credential vending and an object outside the allowed locations that the catalog&amp;#39;s underlying storage credentials can read.<br /> <br /> Exploitation requires an authenticated principal with table- or view-registration privileges.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86: intel-hid: Protect ACPI notify handler against recursion<br /> <br /> Since commit e2ffcda16290 ("ACPI: OSL: Allow Notify () handlers to run on<br /> all CPUs") ACPI notify handlers like the intel-hid notify_handler() may<br /> run on multiple CPU cores racing with themselves.<br /> <br /> On convertibles and detachables (matched by DMI chassis-type 31 and 32 in<br /> dmi_auto_add_switch[]) the SW_TABLET_MODE input device is registered<br /> lazily from notify_handler() on the first tablet-mode event, via<br /> intel_hid_switches_setup(). When two such events race on different CPUs<br /> both can pass the !priv-&gt;switches check and register the priv-&gt;switches<br /> input device twice, resulting in a duplicate sysfs entry and a subsequent<br /> NULL pointer dereference.<br /> <br /> This is the same class of bug fixed by commit e075c3b13a0a ("platform/x86:<br /> intel-vbtn: Protect ACPI notify handler against recursion") for the<br /> sibling intel-vbtn driver.<br /> <br /> Protect intel-hid notify_handler() from racing with itself with a mutex<br /> to fix this.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode<br /> <br /> When updating CR8 intercepts, get vmcs12 if and only if the vCPU is in<br /> guest mode so that a future change can have update CR8 intercepts during<br /> vCPU creation, without running afoul of get_vmcs12()&amp;#39;s lockdep assertion.<br /> <br /> ------------[ cut here ]------------<br /> debug_locks &amp;&amp; !(lock_is_held(&amp;(&amp;vcpu-&gt;mutex)-&gt;dep_map) || !refcount_read(&amp;vcpu-&gt;kvm-&gt;users_count))<br /> WARNING: arch/x86/kvm/vmx/nested.h:61 at get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline], CPU#0: syz.2.19/5879<br /> WARNING: arch/x86/kvm/vmx/nested.h:61 at vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879, CPU#0: syz.2.19/5879<br /> Modules linked in:<br /> CPU: 0 UID: 0 PID: 5879 Comm: syz.2.19 Not tainted syzkaller #0 PREEMPT(full)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014<br /> RIP: 0010:get_vmcs12 arch/x86/kvm/vmx/nested.h:60 [inline]<br /> RIP: 0010:vmx_update_cr8_intercept+0x3de/0x4e0 arch/x86/kvm/vmx/vmx.c:6879<br /> Call Trace:<br /> <br /> apic_update_ppr arch/x86/kvm/lapic.c:984 [inline]<br /> kvm_lapic_reset+0x1c24/0x2980 arch/x86/kvm/lapic.c:3023<br /> kvm_vcpu_reset+0x44c/0x1bf0 arch/x86/kvm/x86.c:12986<br /> kvm_arch_vcpu_create+0x746/0x8b0 arch/x86/kvm/x86.c:12847<br /> kvm_vm_ioctl_create_vcpu+0x428/0x930 virt/kvm/kvm_main.c:4201<br /> kvm_vm_ioctl+0x893/0xd50 virt/kvm/kvm_main.c:5159<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:597 [inline]<br /> __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> No functional change intended.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: hid-lenovo-go: cancel cfg_setup work in hid_go_cfg_remove()<br /> <br /> hid_go_cfg_probe() initialises drvdata.go_cfg_setup and schedules it<br /> to run 2 ms later:<br /> <br /> INIT_DELAYED_WORK(&amp;drvdata.go_cfg_setup, &amp;cfg_setup);<br /> schedule_delayed_work(&amp;drvdata.go_cfg_setup, msecs_to_jiffies(2));<br /> <br /> cfg_setup() dereferences drvdata.hdev to issue MCU command requests.<br /> hid_go_cfg_remove() tears down sysfs and stops the HID device, but<br /> never drains the delayed work. If the device is unbound within the<br /> 2 ms scheduling delay (a probe failure rolling back via remove, or a<br /> fast rmmod after probe), the work fires after hid_destroy_device()<br /> has dropped its reference and released the underlying hdev struct,<br /> leaving cfg_setup() with a stale drvdata.hdev pointer.<br /> <br /> Mirror the sibling driver hid-lenovo-go-s.c, whose hid_gos_cfg_remove()<br /> already calls cancel_delayed_work_sync() on its analogous work, and<br /> drain go_cfg_setup at the top of hid_go_cfg_remove(). The cancel<br /> must come before guard(mutex)(&amp;drvdata.cfg_mutex) because cfg_setup()<br /> acquires that mutex; reversing the order would deadlock.