IBM Aspera Faspex 5.0.0 through 5.0.6 is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 260139.

In the Linux kernel, the following vulnerability has been resolved: misc: alcor_pci: fix null-ptr-deref when there is no PCI bridge There is an issue with the ASPM(optional) capability checking function. A device might be attached to root complex directly, in this case, bus->self(bridge) will be NULL, thus priv->parent_pdev is NULL. Since alcor_pci_init_check_aspm(priv->parent_pdev) checks the PCI link's ASPM capability and populate parent_cap_off, which will be used later by alcor_pci_aspm_ctrl() to dynamically turn on/off device, what we can do here is to avoid checking the capability if we are on the root complex. This will make pdev_cap_off 0 and alcor_pci_aspm_ctrl() will simply return when bring called, effectively disable ASPM for the device. [ 1.246492] BUG: kernel NULL pointer dereference, address: 00000000000000c0 [ 1.248731] RIP: 0010:pci_read_config_byte+0x5/0x40 [ 1.253998] Call Trace: [ 1.254131] ? alcor_pci_find_cap_offset.isra.0+0x3a/0x100 [alcor_pci] [ 1.254476] alcor_pci_probe+0x169/0x2d5 [alcor_pci]

Umbraco CMS is an ASP.NET CMS used by more than 730.000 websites. Stored Cross-site scripting (XSS) enable attackers that have access to backoffice to bring malicious content into a website or application. This vulnerability has been patched in version(s) 8.18.13, 10.8.4, 12.3.7, 13.1.1 by implementing IHtmlSanitizer.

Umbraco is an ASP.NET CMS used by more than 730.000 websites. Umbraco has an endpoint that is vulnerable to open redirects. The endpoint is protected so it requires the user to be signed into backoffice before the vulnerable is exposed. This vulnerability has been patched in version(s) 8.18.14, 10.8.6, 12.3.10 and 13.3.1.

Local Root Exploit via Configuration Dictionary in dnf5daemon-server before 5.1.17 allows a malicious user to impact Confidentiality and Integrity via Configuration Dictionary. There are issues with the D-Bus interface long before Polkit is invoked. The `org.rpm.dnf.v0.SessionManager.open_session` method takes a key/value map of configuration entries. A sub-entry in this map, placed under the "config" key, is another key/value map. The configuration values found in it will be forwarded as configuration overrides to the `libdnf5::Base` configuration.  Practically all libdnf5 configuration aspects can be influenced here. Already when opening the session via D-Bus, the libdnf5 will be initialized using these override configuration values. There is no sanity checking of the content of this "config" map, which is untrusted data. It is possible to make the library loading a plug-in shared library under control of an unprivileged user, hence achieving root access. 

IBM Aspera Orchestrator 4.0.1 could allow a remote attacker to enumerate usernames due to observable response discrepancies. IBM X-Force ID: 248545.

IBM Aspera Orchestrator 4.0.1 could allow a remote authenticated attacker to execute arbitrary commands on the system by sending a specially crafted request. IBM X-Force ID: 260116.

IBM Aspera Faspex 5.0.0 through 5.0.7 could allow a local user to obtain or modify sensitive information due to improper encryption of certain data. IBM X-Force ID: 259672.

IBM Aspera Faspex 5.0.0 through 5.0.7 could allow a user to cause a denial of service due to missing API rate limiting. IBM X-Force ID: 248533.

IBM Aspera Faspex 5.0.0 through 5.0.7 could allow a local user to obtain sensitive information due to weaker than expected security. IBM X-Force ID: 236452.

IBM Aspera Faspex 5.0.0 through 5.0.7 could allow a local user to obtain sensitive information due to improper encryption of certain data. IBM X-Force ID: 259671.

IBM Aspera Faspex 5.0.0 through 5.0.7 stores potentially sensitive information in log files that could be read by a local user. IBM X-Force ID: 244119.

IBM Aspera Faspex 5.0.0 through 5.0.7 could allow a local user to escalate their privileges due to insecure credential storage. IBM X-Force ID: 259677.

Umbraco is an ASP.NET CMS. Failing webhooks logs are available when solution is not in debug mode. Those logs can contain information that is critical. This vulnerability is fixed in 13.1.1.

Reflected Cross Site Scripting (XSS) vulnerability in RageFrame2 v2.6.43, allows remote attackers to execute arbitrary web scripts or HTML and obtain sensitive information via a crafted payload injected into the aspectRatio parameter in the image cropping function.

Umbraco is an ASP.NET content management system. Umbraco 10 prior to 10.8.4 with access to the native login screen is vulnerable to a possible user enumeration attack. This issue was fixed in version 10.8.5. As a workaround, one may disable the native login screen by exclusively using external logins.

IBM Aspera Faspex 5.0.0 and 5.0.1 is vulnerable to HTTP header injection, caused by improper validation of input by the HOST headers. This could allow an attacker to conduct various attacks against the vulnerable system, including cross-site scripting, cache poisoning or session hijacking. IBM X-Force ID: 222562.

IBM QRadar Suite Products 1.10.12.0 through 1.10.18.0 and IBM Cloud Pak for Security 1.10.0.0 through 1.10.11.0 could disclose sensitive information using man in the middle techniques due to not correctly enforcing all aspects of certificate validation in some circumstances. IBM X-Force ID: 272533.

In the Linux kernel, the following vulnerability has been resolved: media: aspeed: fix clock handling logic Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below. Enable eclk De-assert Video Engine reset 10ms delay Enable vclk It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it's extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot. To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clk_unprepare call for a case when probe fails. clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as 'Video Engine' reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting.

In the Linux kernel, the following vulnerability has been resolved: PCI/ASPM: Fix deadlock when enabling ASPM A last minute revert in 6.7-final introduced a potential deadlock when enabling ASPM during probe of Qualcomm PCIe controllers as reported by lockdep: ============================================ WARNING: possible recursive locking detected 6.7.0 #40 Not tainted -------------------------------------------- kworker/u16:5/90 is trying to acquire lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc but task is already holding lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(pci_bus_sem); lock(pci_bus_sem); *** DEADLOCK *** Call trace: print_deadlock_bug+0x25c/0x348 __lock_acquire+0x10a4/0x2064 lock_acquire+0x1e8/0x318 down_read+0x60/0x184 pcie_aspm_pm_state_change+0x58/0xdc pci_set_full_power_state+0xa8/0x114 pci_set_power_state+0xc4/0x120 qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom] pci_walk_bus+0x64/0xbc qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom] The deadlock can easily be reproduced on machines like the Lenovo ThinkPad X13s by adding a delay to increase the race window during asynchronous probe where another thread can take a write lock. Add a new pci_set_power_state_locked() and associated helper functions that can be called with the PCI bus semaphore held to avoid taking the read lock twice.