Vulnerabilities

The CloudStack integration API service allows running its unauthenticated API server (usually on port 8096 when configured and enabled via integration.api.port global setting) for internal portal integrations and for testing purposes. By default, the integration API service port is disabled and is considered disabled when integration.api.port is set to 0 or negative. Due to an improper initialisation logic, the integration API service would listen on a random port when its port value is set to 0 (default value). An attacker that can access the CloudStack management network could scan and find the randomised integration API service port and exploit it to perform unauthorised administrative actions and perform remote code execution on CloudStack managed hosts and result in complete compromise of the confidentiality, integrity, and availability of CloudStack managed infrastructure.<br /> <br /> Users are recommended to restrict the network access on the CloudStack management server hosts to only essential ports. Users are recommended to upgrade to version 4.18.2.1, 4.19.0.2 or later, which addresses this issue.

HCL Nomad server on Domino fails to properly handle users configured with limited Domino access resulting in a possible denial of service vulnerability.

SeaCMS v12.9 has an unauthorized SQL injection vulnerability. The vulnerability is caused by the SQL injection through the cid parameter at /js/player/dmplayer/dmku/index.php?ac=edit, which can cause sensitive database information to be leaked.

The CloudStack cluster service runs on unauthenticated port (default 9090) that can be misused to run arbitrary commands on targeted hypervisors and CloudStack management server hosts. Some of these commands were found to have command injection vulnerabilities that can result in arbitrary code execution via agents on the hosts that may run as a privileged user. An attacker that can reach the cluster service on the unauthenticated port (default 9090), can exploit this to perform remote code execution on CloudStack managed hosts and result in complete compromise of the confidentiality, integrity, and availability of CloudStack managed infrastructure.<br /> <br /> Users are recommended to restrict the network access to the cluster service port (default 9090) on a CloudStack management server host to only its peer CloudStack management server hosts. Users are recommended to upgrade to version 4.18.2.1, 4.19.0.2 or later, which addresses this issue.

** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in D-Link DAR-7000 up to 20230922. It has been rated as problematic. Affected by this issue is some unknown functionality of the file /log/decodmail.php. The manipulation of the argument file leads to deserialization. The attack may be launched remotely. The exploit has been disclosed to the public and may be used. The identifier of this vulnerability is VDB-270368. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.

A vulnerability was found in ShopXO up to 6.1.0. It has been declared as critical. Affected by this vulnerability is an unknown functionality of the file extend/base/Uploader.php. The manipulation of the argument source leads to server-side request forgery. The attack can be launched remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-270367. NOTE: The original disclosure confuses CSRF with SSRF.

Unauthorized file access in WEB Server in ABB ASPECT - Enterprise v3.08.01; NEXUS Series<br /> <br /> v3.08.01<br /> <br /> ; MATRIX Series <br /> <br /> v3.08.01 allows Attacker to access files unauthorized

Unauthorized file access in WEB Server in ABB ASPECT - Enterprise v3.08.01; NEXUS Series<br /> <br /> v3.08.01<br /> <br /> ; MATRIX Series <br /> <br /> v3.08.01 allows Attacker to execute arbitrary code remotely

A vulnerability was found in ZKTeco BioTime up to 9.5.2. It has been classified as problematic. Affected is an unknown function of the component system-group-add Handler. The manipulation of the argument user with the input alert(&amp;#39;XSS&amp;#39;) leads to cross site scripting. It is possible to launch the attack remotely. The exploit has been disclosed to the public and may be used. VDB-270366 is the identifier assigned to this vulnerability. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: SOF: ipc4-topology: Fix input format query of process modules without base extension<br /> <br /> If a process module does not have base config extension then the same<br /> format applies to all of it&amp;#39;s inputs and the process-&gt;base_config_ext is<br /> NULL, causing NULL dereference when specifically crafted topology and<br /> sequences used.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: savage: Handle err return when savagefb_check_var failed<br /> <br /> The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero")<br /> checks the value of pixclock to avoid divide-by-zero error. However<br /> the function savagefb_probe doesn&amp;#39;t handle the error return of<br /> savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDING<br /> <br /> Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with<br /> small possibility, the root cause is exactly the same as commit<br /> bed9e27baf52 ("Revert "md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d"")<br /> <br /> However, Dan reported another hang after that, and junxiao investigated<br /> the problem and found out that this is caused by plugged bio can&amp;#39;t issue<br /> from raid5d().<br /> <br /> Current implementation in raid5d() has a weird dependence:<br /> <br /> 1) md_check_recovery() from raid5d() must hold &amp;#39;reconfig_mutex&amp;#39; to clear<br /> MD_SB_CHANGE_PENDING;<br /> 2) raid5d() handles IO in a deadloop, until all IO are issued;<br /> 3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;<br /> <br /> This behaviour is introduce before v2.6, and for consequence, if other<br /> context hold &amp;#39;reconfig_mutex&amp;#39;, and md_check_recovery() can&amp;#39;t update<br /> super_block, then raid5d() will waste one cpu 100% by the deadloop, until<br /> &amp;#39;reconfig_mutex&amp;#39; is released.<br /> <br /> Refer to the implementation from raid1 and raid10, fix this problem by<br /> skipping issue IO if MD_SB_CHANGE_PENDING is still set after<br /> md_check_recovery(), daemon thread will be woken up when &amp;#39;reconfig_mutex&amp;#39;<br /> is released. Meanwhile, the hang problem will be fixed as well.