| CVE-2024-53979 | ibm.ibm_zhmc is an Ansible collection for the IBM Z HMC. The Ansible collection "ibm.ibm_zhmc" writes password-like properties in clear text into its log file and into the output returned by some of its Ansible module in the following cases: 1. The 'boot_ftp_password' and 'ssc_master_pw' properties are passed as input to the zhmc_partition Ansible module. 2. The 'ssc_master_pw' and 'zaware_master_pw' properties are passed as input to the zhmc_lpar Ansible module. 3. The 'password' property is passed as input to the zhmc_user Ansible module (just in log file, not in module output). 4. The 'bind_password' property is passed as input to the zhmc_ldap_server_definition Ansible module. These properties appear in the module output only when they were specified in the module input and when creating or updating the corresponding resources. They do not appear in the output when retrieving facts for the corresponding resources. These properties appear in the log file only when the "log_file" module input parameter is used. By default, no log file is created. This issue has been fixed in ibm.ibm_zhmc version 1.9.3. Users are advised to upgrade. There are no known workarounds for this vulnerability. | high |
| CVE-2024-53915 | An issue was discovered in the server in Veritas Enterprise Vault before 15.2, ZDI-CAN-24405. It allows remote attackers to execute arbitrary code because untrusted data, received on a .NET Remoting TCP port, is deserialized. | critical |
| CVE-2024-53914 | An issue was discovered in the server in Veritas Enterprise Vault before 15.2, ZDI-CAN-24344. It allows remote attackers to execute arbitrary code because untrusted data, received on a .NET Remoting TCP port, is deserialized. | critical |
| CVE-2024-53913 | An issue was discovered in the server in Veritas Enterprise Vault before 15.2, ZDI-CAN-24343. It allows remote attackers to execute arbitrary code because untrusted data, received on a .NET Remoting TCP port, is deserialized. | critical |
| CVE-2024-53912 | An issue was discovered in the server in Veritas Enterprise Vault before 15.2, ZDI-CAN-24341. It allows remote attackers to execute arbitrary code because untrusted data, received on a .NET Remoting TCP port, is deserialized. | critical |
| CVE-2024-53911 | An issue was discovered in the server in Veritas Enterprise Vault before 15.2, ZDI-CAN-24339. It allows remote attackers to execute arbitrary code because untrusted data, received on a .NET Remoting TCP port, is deserialized. | critical |
| CVE-2024-53910 | An issue was discovered in the server in Veritas Enterprise Vault before 15.2, ZDI-CAN-24336. It allows remote attackers to execute arbitrary code because untrusted data, received on a .NET Remoting TCP port, is deserialized. | critical |
| CVE-2024-53909 | An issue was discovered in the server in Veritas Enterprise Vault before 15.2, ZDI-CAN-24334. It allows remote attackers to execute arbitrary code because untrusted data, received on a .NET Remoting TCP port, is deserialized. | critical |
| CVE-2024-53865 | zhmcclient is a pure Python client library for the IBM Z HMC Web Services API. In affected versions the Python package "zhmcclient" writes password-like properties in clear text into its HMC and API logs in the following cases: 1. The 'boot-ftp-password' and 'ssc-master-pw' properties when creating or updating a partition in DPM mode, in the zhmcclient API and HMC logs. 2. The 'ssc-master-pw' and 'zaware-master-pw' properties when updating an LPAR in classic mode, in the zhmcclient API and HMC logs. 3. The 'ssc-master-pw' and 'zaware-master-pw' properties when creating or updating an image activation profile in classic mode, in the zhmcclient API and HMC logs. 4. The 'password' property when creating or updating an HMC user, in the zhmcclient API log. 5. The 'bind-password' property when creating or updating an LDAP server definition, in the zhmcclient API and HMC logs. This issue affects only users of the zhmcclient package that have enabled the Python loggers named "zhmcclient.api" (for the API log) or "zhmcclient.hmc" (for the HMC log) and that use the functions listed above. This issue has been fixed in zhmcclient version 1.18.1. Users are advised to upgrade. There are no known workarounds for this vulnerability. | high |
| CVE-2024-53864 | Ibexa Admin UI Bundle is all the necessary parts to run the Ibexa DXP Back Office interface. The Content name pattern is used to build Content names from one or more fields. An XSS vulnerability has been found in this mechanism. Content edit permission is required to exploit it. After the fix, any existing injected XSS will not run. This issue has been patched in version 4.6.14. All users are advised to upgrade. There are no known workarounds for this vulnerability. | medium |
| CVE-2024-53848 | check-jsonschema is a CLI and set of pre-commit hooks for jsonschema validation. The default cache strategy uses the basename of a remote schema as the name of the file in the cache, e.g. `https://example.org/schema.json` will be stored as `schema.json`. This naming allows for conflicts. If an attacker can get a user to run `check-jsonschema` against a malicious schema URL, e.g., `https://example.evil.org/schema.json`, they can insert their own schema into the cache and it will be picked up and used instead of the appropriate schema. Such a cache confusion attack could be used to allow data to pass validation which should have been rejected. This issue has been patched in version 0.30.0. All users are advised to upgrade. A few workarounds exist: 1. Users can use `--no-cache` to disable caching. 2. Users can use `--cache-filename` to select filenames for use in the cache, or to ensure that other usages do not overwrite the cached schema. (Note: this flag is being deprecated as part of the remediation effort.) 3. Users can explicitly download the schema before use as a local file, as in `curl -LOs https://example.org/schema.json; check-jsonschema --schemafile ./schema.json` | high |
| CVE-2024-53701 | Multiple FCNT Android devices provide the original security features such as "privacy mode" where arbitrary applications can be set not to be displayed, etc. Under certain conditions, and when an attacker can directly operate the device which its screen is unlocked by a user, the provided security features' setting pages may be exposed and/or the settings may be altered, without authentication. For example, specific applications in the device configured to be hidden may be displayed and/or activated. | low |
| CVE-2024-53604 | A SQL Injection vulnerability was found in /covid-tms/check_availability.php in PHPGurukul COVID 19 Testing Management System v1.0, which allows remote attackers to execute arbitrary code via the mobnumber POST request parameter. | critical |
| CVE-2024-52810 | @intlify/shared is a shared library for the intlify project. The latest version of @intlify/shared (10.0.4) is vulnerable to Prototype Pollution through the entry function(s) lib.deepCopy. An attacker can supply a payload with Object.prototype setter to introduce or modify properties within the global prototype chain, causing denial of service (DoS) as the minimum consequence. Moreover, the consequences of this vulnerability can escalate to other injection-based attacks, depending on how the library integrates within the application. For instance, if the polluted property propagates to sensitive Node.js APIs (e.g., exec, eval), it could enable an attacker to execute arbitrary commands within the application's context. This issue has been addressed in versions 9.14.2, and 10.0.5. Users are advised to upgrade. There are no known workarounds for this vulnerability. | medium |
| CVE-2024-52809 | vue-i18n is an internationalization plugin for Vue.js. In affected versions vue-i18n can be passed locale messages to `createI18n` or `useI18n`. When locale message ASTs are generated in development mode there is a possibility of Cross-site Scripting attack. This issue has been addressed in versions 9.14.2, and 10.0.5. Users are advised to upgrade. There are no known workarounds for this vulnerability. | medium |
| CVE-2024-52801 | sftpgo is a full-featured and highly configurable event-driven file transfer solution. Server protocols: SFTP, HTTP/S, FTP/S, WebDAV. The OpenID Connect implementation allows authenticated users to brute force session cookies and thereby gain access to other users' data, since the cookies are generated predictably using the xid library and are therefore unique but not cryptographically secure. This issue was fixed in version v2.6.4, where cookies are opaque and cryptographically secure strings. All users are advised to upgrade. There are no known workarounds for this vulnerability. | medium |
| CVE-2024-52800 | veraPDF is an open source PDF/A validation library. Executing policy checks using custom schematron files via the CLI invokes an XSL transformation that may theoretically lead to a remote code execution (RCE) vulnerability. This doesn't affect the standard validation and policy checks functionality, veraPDF's common use cases. Most veraPDF users don't insert any custom XSLT code into policy profiles, which are based on Schematron syntax rather than direct XSL transforms. For users who do, only load custom policy files from sources you trust. This issue has not yet been patched. Users are advised to be cautious of XSLT code until a patch is available. | low |
| CVE-2024-52782 | DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/audit/newstatistics/mon_stat_hist_new.php. | critical |
| CVE-2024-52781 | DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/system/tool/traceroute.php. | critical |
| CVE-2024-52780 | DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/system/basic/mgmt_edit.php. | critical |
| CVE-2024-52779 | DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/audit/newstatistics/mon_stat_top10.php. | critical |
| CVE-2024-52778 | DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/audit/newstatistics/mon_stat_hist.php. | critical |
| CVE-2024-52777 | DCME-320 <=7.4.12.90, DCME-520 <=9.25.5.11, DCME-320-L, <=9.3.5.26, and DCME-720 <=9.1.5.11 are vulnerable to Remote Code Execution via /function/system/basic/license_update.php. | critical |
| CVE-2024-52769 | An arbitrary file upload vulnerability in the component /admin/friendlink_edit of DedeBIZ v6.3.0 allows attackers to execute arbitrary code via uploading a crafted file. | high |
| CVE-2024-52763 | A cross-site scripting (XSS) vulnerability in the component /graph_all_periods.php of Ganglia-web v3.73 to v3.75 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the "g" parameter. | medium |
| CVE-2024-52762 | A cross-site scripting (XSS) vulnerability in the component /master/header.php of Ganglia-web v3.73 to v3.76 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the "tz" parameter. | medium |
| CVE-2024-52338 | Deserialization of untrusted data in IPC and Parquet readers in the Apache Arrow R package versions 4.0.0 through 16.1.0 allows arbitrary code execution. An application is vulnerable if it reads Arrow IPC, Feather or Parquet data from untrusted sources (for example, user-supplied input files). This vulnerability only affects the arrow R package, not other Apache Arrow implementations or bindings unless those bindings are specifically used via the R package (for example, an R application that embeds a Python interpreter and uses PyArrow to read files from untrusted sources is still vulnerable if the arrow R package is an affected version). It is recommended that users of the arrow R package upgrade to 17.0.0 or later. Similarly, it is recommended that downstream libraries upgrade their dependency requirements to arrow 17.0.0 or later. If using an affected version of the package, untrusted data can read into a Table and its internal to_data_frame() method can be used as a workaround (e.g., read_parquet(..., as_data_frame = FALSE)$to_data_frame()). This issue affects the Apache Arrow R package: from 4.0.0 through 16.1.0. Users are recommended to upgrade to version 17.0.0, which fixes the issue. | critical |
| CVE-2024-52003 | Traefik (pronounced traffic) is an HTTP reverse proxy and load balancer. There is a vulnerability in Traefik that allows the client to provide the X-Forwarded-Prefix header from an untrusted source. This issue has been addressed in versions 2.11.14 and 3.2.1. Users are advised to upgrade. There are no known workarounds for this vulnerability. | medium |
| CVE-2024-51228 | An issue in TOTOLINK-CX-A3002RU V1.0.4-B20171106.1512 and TOTOLINK-CX-N150RT V2.1.6-B20171121.1002 and TOTOLINK-CX-N300RT V2.1.6-B20170724.1420 and TOTOLINK-CX-N300RT V2.1.8-B20171113.1408 and TOTOLINK-CX-N300RT V2.1.8-B20191010.1107 and TOTOLINK-CX-N302RE V2.0.2-B20170511.1523 allows a remote attacker to execute arbitrary code via the /boafrm/formSysCmd component. | medium |
| CVE-2024-50986 | An issue in Clementine v.1.3.1 allows a local attacker to execute arbitrary code via a crafted DLL file. | high |
| CVE-2024-50357 | FutureNet NXR series routers provided by Century Systems Co., Ltd. have REST-APIs, which are configured as disabled in the initial (factory default) configuration. But, REST-APIs are unexpectedly enabled when the affected product is powered up, provided either http-server (GUI) or Web authentication is enabled. The factory default configuration makes http-server (GUI) enabled, which means REST-APIs are also enabled. The username and the password for REST-APIs are configured in the factory default configuration. As a result, an attacker may obtain and/or alter the affected product's settings via REST-APIs. | critical |
| CVE-2024-50198 | In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again. | medium |
| CVE-2024-50197 | In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned. | medium |
| CVE-2024-50196 | In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ``` | medium |
| CVE-2024-50195 | In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself. | medium |
| CVE-2024-50194 | In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include <stdio.h> | #include <stdbool.h> | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | " adrp %x0, adrp_self\n" | " add %x0, %x0, :lo12:adrp_self\n" | : "=r" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf("adrp_self => %p\n" | "adrp_self() => %p\n" | "%s\n", | adrp_self, ptr, equal ? "EQUAL" : "NOT EQUAL"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 <adrp_self>: | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | medium |
| CVE-2024-50193 | In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI. | high |
| CVE-2024-50192 | In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor. | medium |
| CVE-2024-50182 | In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/[email protected]/ [2]: https://lore.kernel.org/lkml/[email protected]/#t [3]: https://lore.kernel.org/lkml/[email protected]/ | medium |
| CVE-2024-50181 | In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang. | medium |
| CVE-2024-50180 | In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, "%ux%ux8", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE. | high |
| CVE-2024-50179 | In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference. | medium |
| CVE-2024-49806 | IBM Security Verify Access Appliance 10.0.0 through 10.0.8 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. | critical |
| CVE-2024-49805 | IBM Security Verify Access Appliance 10.0.0 through 10.0.8 contains hard-coded credentials, such as a password or cryptographic key, which it uses for its own inbound authentication, outbound communication to external components, or encryption of internal data. | critical |
| CVE-2024-49804 | IBM Security Verify Access Appliance 10.0.0 through 10.0.8 could allow a locally authenticated non-administrative user to escalate their privileges due to unnecessary permissions used to perform certain tasks. | high |
| CVE-2024-49803 | IBM Security Verify Access Appliance 10.0.0 through 10.0.8 could allow a remote authenticated attacker to execute arbitrary commands on the system by sending a specially crafted request. | critical |
| CVE-2024-49360 | Sandboxie is a sandbox-based isolation software for 32-bit and 64-bit Windows NT-based operating systems. An authenticated user (**UserA**) with no privileges is authorized to read all files created in sandbox belonging to other users in the sandbox folders `C:\Sandbox\UserB\xxx`. An authenticated attacker who can use `explorer.exe` or `cmd.exe` outside any sandbox can read other users' files in `C:\Sandbox\xxx`. By default in Windows 7+, the `C:\Users\UserA` folder is not readable by **UserB**. All files edited or created during the sandbox processing are affected by the vulnerability. All files in C:\Users are safe. If `UserB` runs a cmd in a sandbox, he will be able to access `C:\Sandox\UserA`. In addition, if **UserB** create a folder `C:\Sandbox\UserA` with malicious ACLs, when **UserA** will user the sandbox, Sandboxie doesn't reset ACLs ! This issue has not yet been fixed. Users are advised to limit access to their systems using Sandboxie. | critical |
| CVE-2024-48651 | In ProFTPD through 1.3.8b before cec01cc, supplemental group inheritance grants unintended access to GID 0 because of the lack of supplemental groups from mod_sql. | high |
| CVE-2024-48406 | Buffer Overflow vulnerability in SunBK201 umicat through v.0.3.2 and fixed in v.0.3.3 allows an attacker to execute arbitrary code via the power(uct_int_t x, uct_int_t n) in src/uct_upstream.c. | critical |
| CVE-2024-47257 | Florent Thiéry has found that selected Axis devices were vulnerable to handling certain ethernet frames which could lead to the Axis device becoming unavailable in the network. Axis has released patched AXIS OS versions for the highlighted flaw for products that are still under AXIS OS software support. Please refer to the Axis security advisory for more information and solution. | high |
