deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-57838
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/entry: Mark IRQ entries to fix stack depot warnings

The stack depot filters out everything outside of the top interrupt
context as an uninteresting or irrelevant part of the stack traces. This
helps with stack trace de-duplication, avoiding an explosion of saved
stack traces that share the same IRQ context code path but originate
from different randomly interrupted points, eventually exhausting the
stack depot.

Filtering uses in_irqentry_text() to identify functions within the
.irqentry.text and .softirqentry.text sections, which then become the
last stack trace entries being saved.

While __do_softirq() is placed into the .softirqentry.text section by
common code, populating .irqentry.text is architecture-specific.

Currently, the .irqentry.text section on s390 is empty, which prevents
stack depot filtering and de-duplication and could result in warnings
like:

Stack depot reached limit capacity
WARNING: CPU: 0 PID: 286113 at lib/stackdepot.c:252 depot_alloc_stack+0x39a/0x3c8

with PREEMPT and KASAN enabled.

Fix this by moving the IO/EXT interrupt handlers from .kprobes.text into
the .irqentry.text section and updating the kprobes blacklist to include
the .irqentry.text section.

This is done only for asynchronous interrupts and explicitly not for
program checks, which are synchronous and where the context beyond the
program check is important to preserve. Despite machine checks being
somewhat in between, they are extremely rare, and preserving context
when possible is also of value.

SVCs and Restart Interrupts are not relevant, one being always at the
boundary to user space and the other being a one-time thing.

IRQ entries filtering is also optionally used in ftrace function graph,
where the same logic applies.
CVSS Score: 7.1 (HIGH)
CWE: CWE-668
References: https://git.kernel.org/stable/c/1af22528fee8072b7adc007b8ca49cc4ea62689e; https://git.kernel.org/stable/c/45c9f2b856a075a34873d00788d2e8a250c1effd; https://git.kernel.org/stable/c/473ffae3030188f1c6b80e1b3631a26b4adf7b32
CVE: CVE-2024-57839
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

Revert "readahead: properly shorten readahead when falling back to do_page_cache_ra()"

This reverts commit 7c877586da3178974a8a94577b6045a48377ff25.

Anders and Philippe have reported that recent kernels occasionally hang
when used with NFS in readahead code.  The problem has been bisected to
7c877586da3 ("readahead: properly shorten readahead when falling back to
do_page_cache_ra()").  The cause of the problem is that ra->size can be
shrunk by read_pages() call and subsequently we end up calling
do_page_cache_ra() with negative (read huge positive) number of pages. 
Let's revert 7c877586da3 for now until we can find a proper way how the
logic in read_pages() and page_cache_ra_order() can coexist.  This can
lead to reduced readahead throughput due to readahead window confusion but
that's better than outright hangs.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-704
References: https://git.kernel.org/stable/c/85351e4941a253e4c50fb7048bfc19b60b4ec44b; https://git.kernel.org/stable/c/a220d6b95b1ae12c7626283d7609f0a1438e6437
CVE: CVE-2024-57843
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

virtio-net: fix overflow inside virtnet_rq_alloc

When the frag just got a page, then may lead to regression on VM.
Specially if the sysctl net.core.high_order_alloc_disable value is 1,
then the frag always get a page when do refill.

Which could see reliable crashes or scp failure (scp a file 100M in size
to VM).

The issue is that the virtnet_rq_dma takes up 16 bytes at the beginning
of a new frag. When the frag size is larger than PAGE_SIZE,
everything is fine. However, if the frag is only one page and the
total size of the buffer and virtnet_rq_dma is larger than one page, an
overflow may occur.

The commit f9dac92ba908 ("virtio_ring: enable premapped mode whatever
use_dma_api") introduced this problem. And we reverted some commits to
fix this in last linux version. Now we try to enable it and fix this
bug directly.

Here, when the frag size is not enough, we reduce the buffer len to fix
this problem.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-191
References: https://git.kernel.org/stable/c/67a11de8965c2ab19e215fb6651d44847e068614; https://git.kernel.org/stable/c/6aacd[PII_REDACTED]d1d04badfe75f264fa5314864; https://git.kernel.org/stable/c/a8f7d6963768b114ec9644ff0148dde4c104e84b
CVE: CVE-2024-57849
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/cpum_sf: Handle CPU hotplug remove during sampling

CPU hotplug remove handling triggers the following function
call sequence:

   CPUHP_AP_PERF_S390_SF_ONLINE  --> s390_pmu_sf_offline_cpu()
   ...
   CPUHP_AP_PERF_ONLINE          --> perf_event_exit_cpu()

The s390 CPUMF sampling CPU hotplug handler invokes:

 s390_pmu_sf_offline_cpu()
 +-->  cpusf_pmu_setup()
       +--> setup_pmc_cpu()
            +--> deallocate_buffers()

This function de-allocates all sampling data buffers (SDBs) allocated
for that CPU at event initialization. It also clears the
PMU_F_RESERVED bit. The CPU is gone and can not be sampled.

With the event still being active on the removed CPU, the CPU event
hotplug support in kernel performance subsystem triggers the
following function calls on the removed CPU:

  perf_event_exit_cpu()
  +--> perf_event_exit_cpu_context()
       +--> __perf_event_exit_context()
	    +--> __perf_remove_from_context()
	         +--> event_sched_out()
	              +--> cpumsf_pmu_del()
	                   +--> cpumsf_pmu_stop()
                                +--> hw_perf_event_update()

to stop and remove the event. During removal of the event, the
sampling device driver tries to read out the remaining samples from
the sample data buffers (SDBs). But they have already been freed
(and may have been re-assigned). This may lead to a use after free
situation in which case the samples are most likely invalid. In the
best case the memory has not been reassigned and still contains
valid data.

Remedy this situation and check if the CPU is still in reserved
state (bit PMU_F_RESERVED set). In this case the SDBs have not been
released an contain valid data. This is always the case when
the event is removed (and no CPU hotplug off occured).
If the PMU_F_RESERVED bit is not set, the SDB buffers are gone.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/06a92f810df8037ca36157282ddcbefdcaf049b8; https://git.kernel.org/stable/c/238e3af849dfdcb1faed544349f7025e533f9aab; https://git.kernel.org/stable/c/99192c735ed4bfdff0d215ec85c8a87a677cb898
CVE: CVE-2024-57850
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

jffs2: Prevent rtime decompress memory corruption

The rtime decompression routine does not fully check bounds during the
entirety of the decompression pass and can corrupt memory outside the
decompression buffer if the compressed data is corrupted. This adds the
required check to prevent this failure mode.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/421f9e9f0fae9f8e721ffa07f22d9765fa1214d5; https://git.kernel.org/stable/c/47c9a7f81027a78afea9d2e9a54bfd8fabb6b3d0; https://git.kernel.org/stable/c/6808a1812a[PII_REDACTED]e7fe9e2de577e99e45d1
CVE: CVE-2024-57872
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: ufs: pltfrm: Dellocate HBA during ufshcd_pltfrm_remove()

This will ensure that the scsi host is cleaned up properly using
scsi_host_dev_release(). Otherwise, it may lead to memory leaks.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401, CWE-401
References: https://git.kernel.org/stable/c/897df60c16d54ad515a3d0887edab5c63da06d1f; https://git.kernel.org/stable/c/cd188519d2467ab4c2141587b0551ba030abff0e
CVE: CVE-2024-57874
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL

Currently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'
variable, and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently tagged_addr_ctrl_set() will consume an
arbitrary value, potentially leaking up to 64 bits of memory from the
kernel stack. The read is limited to a specific slot on the stack, and
the issue does not provide a write mechanism.

As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and
rejects other values, a partial SETREGSET attempt will randomly succeed
or fail depending on the value of the uninitialized value, and the
exposure is significantly limited.

Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
value of the tagged address ctrl will be retained.

The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the
user_aarch64_view used by a native AArch64 task to manipulate another
native AArch64 task. As get_tagged_addr_ctrl() only returns an error
value when called for a compat task, tagged_addr_ctrl_get() and
tagged_addr_ctrl_set() should never observe an error value from
get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that
such an error would be unexpected, and error handlnig is not missing in
either case.
CVSS Score: 6.1 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/1152dd13845efde5554f80c7e1233bae1d26bd3e; https://git.kernel.org/stable/c/1370cf3eb5495d70e[PII_REDACTED]3a4cd45b40b99; https://git.kernel.org/stable/c/1c176f5155ee6161fee6f416b64aa50394d3f220
CVE: CVE-2024-57875
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

block: RCU protect disk->conv_zones_bitmap

Ensure that a disk revalidation changing the conventional zones bitmap
of a disk does not cause invalid memory references when using the
disk_zone_is_conv() helper by RCU protecting the disk->conv_zones_bitmap
pointer.

disk_zone_is_conv() is modified to operate under the RCU read lock and
the function disk_set_conv_zones_bitmap() is added to update a disk
conv_zones_bitmap pointer using rcu_replace_pointer() with the disk
zone_wplugs_lock spinlock held.

disk_free_zone_resources() is modified to call
disk_update_zone_resources() with a NULL bitmap pointer to free the disk
conv_zones_bitmap. disk_set_conv_zones_bitmap() is also used in
disk_update_zone_resources() to set the new (revalidated) bitmap and
free the old one.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/493326c4f10cc71a42c27fdc97ce112182ee4cbc; https://git.kernel.org/stable/c/d7cb6d7414ea1b33536fa6d11805cb8dceec1f97
CVE: CVE-2024-57876
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/dp_mst: Fix resetting msg rx state after topology removal

If the MST topology is removed during the reception of an MST down reply
or MST up request sideband message, the
drm_dp_mst_topology_mgr::up_req_recv/down_rep_recv states could be reset
from one thread via drm_dp_mst_topology_mgr_set_mst(false), racing with
the reading/parsing of the message from another thread via
drm_dp_mst_handle_down_rep() or drm_dp_mst_handle_up_req(). The race is
possible since the reader/parser doesn't hold any lock while accessing
the reception state. This in turn can lead to a memory corruption in the
reader/parser as described by commit bd2fccac61b4 ("drm/dp_mst: Fix MST
sideband message body length check").

Fix the above by resetting the message reception state if needed before
reading/parsing a message. Another solution would be to hold the
drm_dp_mst_topology_mgr::lock for the whole duration of the message
reception/parsing in drm_dp_mst_handle_down_rep() and
drm_dp_mst_handle_up_req(), however this would require a bigger change.
Since the fix is also needed for stable, opting for the simpler solution
in this patch.
CVSS Score: 7.0 (HIGH)
CWE: CWE-362, CWE-787
References: https://git.kernel.org/stable/c/94b33b2d7640e[PII_REDACTED]84eb88321dd0ffbd4; https://git.kernel.org/stable/c/a6fa67d26de385c3c7a23c1e109a0e23bfda4ec7; https://git.kernel.org/stable/c/be826b4451fd187a7c0b04be4f8243d5df6e0450
CVE: CVE-2024-57877
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: ptrace: fix partial SETREGSET for NT_ARM_POE

Currently poe_set() doesn't initialize the temporary 'ctrl' variable,
and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently an arbitrary value will be written back to
target->thread.por_el0, potentially leaking up to 64 bits of memory from
the kernel stack. The read is limited to a specific slot on the stack,
and the issue does not provide a write mechanism.

Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
contents of POR_EL1 will be retained.

Before this patch:

| # ./poe-test
| Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d
| SETREGSET(nt=0x40f, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
|
| Attempting to write NT_ARM_POE (zero length)
| SETREGSET(nt=0x40f, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0xffff8000839c3d50

After this patch:

| # ./poe-test
| Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d
| SETREGSET(nt=0x40f, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
|
| Attempting to write NT_ARM_POE (zero length)
| SETREGSET(nt=0x40f, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
CVSS Score: 6.1 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/4105dd76bc8ad6529d47157ef0565cb84ca6676c; https://git.kernel.org/stable/c/594bfc4947c4fcabba1318d8384c61a29a6b89fb
CVE: CVE-2024-57878
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR

Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable,
and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently an arbitrary value will be written back to
target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from
the kernel stack. The read is limited to a specific slot on the stack,
and the issue does not provide a write mechanism.

Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
contents of FPMR will be retained.

Before this patch:

| # ./fpmr-test
| Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d
| SETREGSET(nt=0x40e, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d
|
| Attempting to write NT_ARM_FPMR (zero length)
| SETREGSET(nt=0x40e, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0xffff800083963d50

After this patch:

| # ./fpmr-test
| Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d
| SETREGSET(nt=0x40e, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d
|
| Attempting to write NT_ARM_FPMR (zero length)
| SETREGSET(nt=0x40e, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d
CVSS Score: 6.1 (MEDIUM)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/8ab73c34e3c5b[PII_REDACTED]65eabd799346bc50b; https://git.kernel.org/stable/c/f5d71291841aecfe5d8435da2dfa7f58ccd18bc8
CVE: CVE-2024-57879
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: iso: Always release hdev at the end of iso_listen_bis

Since hci_get_route holds the device before returning, the hdev
should be released with hci_dev_put at the end of iso_listen_bis
even if the function returns with an error.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-404
References: https://git.kernel.org/stable/c/4ca50db1c567d658d173c5ef3ee6c52b0b03603c; https://git.kernel.org/stable/c/9c76fff747a73ba01d1d87ed53dd9c00cb40ba05
CVE: CVE-2024-57880
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: sof_sdw: Add space for a terminator into DAIs array

The code uses the initialised member of the asoc_sdw_dailink struct to
determine if a member of the array is in use. However in the case the
array is completely full this will lead to an access 1 past the end of
the array, expand the array by one entry to include a space for a
terminator.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/255cc582e6e16191a20d54bcdbca6c91d3e90c5e; https://git.kernel.org/stable/c/b21a849764a4111b0bc14a5ffe987a0582419de2
CVE: CVE-2025-23124
Published: 2025-01-11
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-23125
Published: 2025-01-11
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-23126
Published: 2025-01-11
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-23127
Published: 2025-01-11
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-23128
Published: 2025-01-11
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-57881
Published: 2025-01-11
Description: In the Linux kernel, the following vulnerability has been resolved:

mm/page_alloc: don't call pfn_to_page() on possibly non-existent PFN in split_large_buddy()

In split_large_buddy(), we might call pfn_to_page() on a PFN that might
not exist.  In corner cases, such as when freeing the highest pageblock in
the last memory section, this could result with CONFIG_SPARSEMEM &&
!CONFIG_SPARSEMEM_EXTREME in __pfn_to_section() returning NULL and and
__section_mem_map_addr() dereferencing that NULL pointer.

Let's fix it, and avoid doing a pfn_to_page() call for the first
iteration, where we already have the page.

So far this was found by code inspection, but let's just CC stable as the
fix is easy.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476, CWE-476
References: https://git.kernel.org/stable/c/4234ca9884bcae9e48ed38652d91696ad5cd591d; https://git.kernel.org/stable/c/faeec8e23c10bd30e8aa759a2eb3018dae00f924
CVE: CVE-2021-29669
Published: 2025-01-12
Description: IBM Jazz Foundation 6.0.6, 6.0.6.1, 7.0, 7.0.1, and 7.0.2 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.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79
References: https://www.ibm.com/support/pages/node/7180689
CVE: CVE-2024-49785
Published: 2025-01-12
Description: IBM watsonx.ai 1.1 through 2.0.3 and IBM watsonx.ai on Cloud Pak for Data 4.8 through 5.0.3 is vulnerable to cross-site scripting. This vulnerability allows an authenticated user to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session.
CVSS Score: 5.4 (MEDIUM)
CWE: CWE-79
References: https://www.ibm.com/support/pages/node/7180723
CVE: CVE-2025-0396
Published: 2025-01-12
Description: A vulnerability, which was classified as critical, has been found in exelban stats up to 2.11.21. This issue affects the function shouldAcceptNewConnection of the component XPC Service. The manipulation leads to command injection. It is possible to launch the attack on the local host. Upgrading to version 2.11.22 is able to address this issue. It is recommended to upgrade the affected component.
CVSS Score: 7.8 (HIGH)
CWE: CWE-74, CWE-77
References: https://github.com/exelban/stats/releases/tag/v2.11.22; https://vuldb.com/?ctiid.291269; https://vuldb.com/?id.291269
CVE: CVE-2025-0397
Published: 2025-01-12
Description: A vulnerability, which was classified as problematic, was found in reckcn SPPanAdmin 1.0. Affected is an unknown function of the file /;/admin/role/edit. The manipulation of the argument name 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. Other parameters might be affected as well. The vendor was contacted early about this disclosure but did not respond in any way.
CVSS Score: 3.5 (LOW)
CWE: CWE-79, CWE-94
References: https://github.com/LvZCh/SPPanAdmin/issues/3; https://github.com/LvZCh/SPPanAdmin/issues/3#issue[PII_REDACTED]; https://vuldb.com/?ctiid.291270
CVE: CVE-2024-51456
Published: 2025-01-12
Description: IBM Robotic Process Automation 21.0.0 through 21.0.7.19 and 23.0.0 through 23.0.19 could allow a remote attacker to obtain sensitive data that may be exposed through certain crypto-analytic attacks.
CVSS Score: 5.9 (MEDIUM)
CWE: CWE-780, CWE-327
References: https://www.ibm.com/support/pages/node/7180685
CVE: CVE-2025-0398
Published: 2025-01-12
Description: A vulnerability has been found in longpi1 warehouse 1.0 and classified as problematic. Affected by this vulnerability is an unknown functionality of the file /resources/..;/inport/updateInport of the component Backend. The manipulation of the argument remark leads to cross site scripting. The attack can be launched remotely. The exploit has been disclosed to the public and may be used.
CVSS Score: 2.4 (LOW)
CWE: CWE-79, CWE-94
References: https://github.com/longpi1/warehouse/issues/4; https://github.com/longpi1/warehouse/issues/4#issue[PII_REDACTED]; https://vuldb.com/?ctiid.291271
CVE: CVE-2024-42179
Published: 2025-01-12
Description: HCL MyXalytics is affected by sensitive information disclosure vulnerability.  The HTTP response header exposes the Microsoft-HTTP API∕2.0 as the server's name & version.
CVSS Score: 2.0 (LOW)
CWE: CWE-200
References: https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0118149
CVE: CVE-2024-42180
Published: 2025-01-12
Description: HCL MyXalytics is affected by a malicious file upload vulnerability.  The application accepts invalid file uploads, including incorrect content types, double extensions, null bytes, and special characters, allowing attackers to upload and execute malicious files.
CVSS Score: 1.6 (LOW)
CWE: CWE-434, CWE-434
References: https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0118149
CVE: CVE-2024-42181
Published: 2025-01-12
Description: HCL MyXalytics is affected by a cleartext transmission of sensitive information vulnerability.  The application transmits sensitive or security-critical data in cleartext in a communication channel that can be sniffed by unauthorized actors.
CVSS Score: 1.6 (LOW)
CWE: CWE-319, CWE-319
References: https://support.hcl-software.com/csm?id=kb_article&sysparm_article=KB0118149