LiveActive security incident?Get immediate response
CVE archive

August 2024

Browse CVE records published in August 2024, with severity, affected products, CWE, KEV, and source-backed vulnerability context.

Search all CVEsKnown exploited

Showing 50 of 2782 matching CVEs · Page 1 of 56.

Critical · CVSS 9.1

CVE-2024-38891: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform a Sniffing Network Traffic attack due to the cleartext transmission of sensitive information.

Published Aug 2, 2024 · Updated Jul 5, 2026

Critical · CVSS 9.6

CVE-2024-38889: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform SQL Injection due to improper neutralization of special elements used in an SQL command.

Published Aug 2, 2024 · Updated Jul 5, 2026

Medium · CVSS 6.8

CVE-2024-38888: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a local attacker to perform a Password Brute Forcing attack due to improper restriction of excessive authentication attempts.

Published Aug 2, 2024 · Updated Jul 5, 2026

Critical · CVSS 9.8

CVE-2024-38887: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to expand control over the operating system from the database due to the execution of commands with unnecessary privileges.

Published Aug 2, 2024 · Updated Jul 5, 2026

Critical · CVSS 9.8

CVE-2024-38886: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform a Traffic Injection attack due to improper verification of the source of a communication channel.

Published Aug 2, 2024 · Updated Jul 5, 2026

High · CVSS 7.5

CVE-2024-38885: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform unauthorized access using known operating system credentials due to hardcoded SQL user credentials in the client application.

Published Aug 2, 2024 · Updated Jul 5, 2026

High · CVSS 7.8

CVE-2024-38884: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a local attacker to perform an Authentication Bypass attack due to improperly implemented security checks for standard authentication mechanisms

Published Aug 2, 2024 · Updated Jul 5, 2026

Critical · CVSS 9.1

CVE-2024-38883: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform a Drop Encryption Level attack due to the selection of a less-secure algorithm during negotiation.

Published Aug 2, 2024 · Updated Jul 5, 2026

Critical · CVSS 9.8

CVE-2024-38882: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform command line execution through SQL Injection due to improper neutralization of special elements used in an OS command.

Published Aug 2, 2024 · Updated Jul 5, 2026

High · CVSS 7.5

CVE-2024-38881: An issue in Horizon Business Services Inc.

An issue in Horizon Business Services Inc. Caterease 16.0.1.1663 through 24.0.1.2405 and possibly later versions, allows a remote attacker to perform a Rainbow Table Password cracking attack due to the use of one-way hashes without salts when storing user passwords.

Published Aug 2, 2024 · Updated Jul 5, 2026

Critical · CVSS 9.8

CVE-2024-42531: Ezviz Internet PT Camera CS-CV246 D15655150 allows an unauthenticated host to access its live video stream...

Ezviz Internet PT Camera CS-CV246 D15655150 allows an unauthenticated host to access its live video stream by crafting a set of RTSP packets with a specific set of URLs that can be used to redirect the camera feed. NOTE: the vendor's perspective is that the Anonymous120386 sample code can establish RTSP protocol communictaion, but cannot obtain video or audio data; thus, there is no risk.

Published Aug 23, 2024 · Updated Jul 5, 2026

Medium · CVSS 6.4

CVE-2024-8105: Insecure Platform Key (PK) used in UEFI system firmware signature

A vulnerability exists in UEFI implementations that use a hard-coded software-based Platform Key (PK). An attacker in possession of the corresponding PK private key can sign arbitrary UEFI executables or firmware components, causing them to be trusted by affected systems and potentially bypassing UEFI Secure Boot trust validation.

Published Aug 26, 2024 · Updated Jun 28, 2026

High · CVSS 8.6

CVE-2024-54678: A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versi...

A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SIMATIC PCS neo V6.0 (All versions < V6.0 SP1 Update 1), SIMATIC S7-PLCSIM V17 (All versions), SIMATIC STEP 7 V17 (All versions < V17 Update 9), SIMATIC STEP 7 V18 (All versions), SIMATIC STEP 7 V19 (All versions < V19 Update 4), SIMATIC STEP 7 V20 (All versions < V20 Update 4), SIMATIC WinCC V17 (All versions < V17 Update 9), SIMATIC WinCC V18 (All versions), SIMATIC WinCC V19 (All versions < V19 Update 4), SIMATIC WinCC V20 (All versions < V20 Update 4), SIMOCODE ES V17 (All versions), SIMOCODE ES V18 (All versions), SIMOCODE ES V19 (All versions), SIMOCODE ES V20 (All versions), SIMOTION SCOUT TIA V5.4 (All versions), SIMOTION SCOUT TIA V5.5 (All versions), SIMOTION SCOUT TIA V5.6 (All versions < V5.6 SP1 HF7), SIMOTION SCOUT TIA V5.7 (All versions), SINAMICS Startdrive V17 (All versions), SINAMICS Startdrive V18 (All versions), SINAMICS Startdrive V19 (All versions), SINAMICS Startdrive V20 (All versions), SIRIUS Safety ES V17 (TIA Portal) (All versions), SIRIUS Safety ES V18 (TIA Portal) (All versions), SIRIUS Safety ES V19 (TIA Portal) (All versions), SIRIUS Safety ES V20 (TIA Portal) (All versions), SIRIUS Soft Starter ES V17 (TIA Portal) (All versions), SIRIUS Soft Starter ES V18 (TIA Portal) (All versions), SIRIUS Soft Starter ES V19 (TIA Portal) (All versions), SIRIUS Soft Starter ES V20 (TIA Portal) (All versions), TIA Portal Cloud V17 (All versions), TIA Portal Cloud V18 (All versions), TIA Portal Cloud V19 (All versions < V5.2.1.1), TIA Portal Cloud V20 (All versions < V5.2.2.2), TIA Portal Test Suite V20 (All versions < V20 Update 4). Affected products do not properly sanitize Interprocess Communication input received through a Windows Named Pipe accessible to all local users. This could allow an authenticated local attacker to cause a type confusion and execute arbitrary code within the affected application.

Published Aug 12, 2025 · Updated Jun 9, 2026

Medium · CVSS 6.9

CVE-2024-4428: Sensetive Data Exposure in Menulux Managment Portal

Missing Authentication for Critical Function, Missing Authorization vulnerability in Menulux Information Technologies Managment Portal allows Collect Data as Provided by Users. This issue affects Managment Portal: through 21.05.2024.

Published Aug 29, 2024 · Updated Jun 3, 2026

Critical · CVSS 9.9

CVE-2024-6684: Authentication Bypass in GST Electronics' inohom Nova Panel N7

Authentication Bypass Using an Alternate Path or Channel vulnerability in GST Electronics inohom Nova Panel N7 allows Authentication Bypass. This issue affects inohom Nova Panel N7: through 1.9.9.6. NOTE: The vendor was contacted and it was learned that the product is not supported.

Published Aug 12, 2024 · Updated Jun 3, 2026

Critical · CVSS 10

CVE-2024-6917: RCE in Veribilim Software's Veribase Order Management

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') vulnerability in Veribilim Software Veribase Order Management allows OS Command Injection. This issue affects Veribase Order Management: before v4.010.2.

Published Aug 12, 2024 · Updated Jun 3, 2026

Medium · CVSS 6.7

CVE-2024-7143: Pulpcore: rbac permissions incorrectly assigned in tasks that create objects

A flaw was found in the Pulp package. When a role-based access control (RBAC) object in Pulp is set to assign permissions on its creation, it uses the `AutoAddObjPermsMixin` (typically the add_roles_for_object_creator method). This method finds the object creator by checking the current authenticated user. For objects that are created within a task, this current user is set by the first user with any permissions on the task object. This means the oldest user with model/domain-level task permissions will always be set as the current user of a task, even if they didn't dispatch the task. Therefore, all objects created in tasks will have their permissions assigned to this oldest user, and the creating user will receive nothing.

Published Aug 7, 2024 · Updated Jun 2, 2026

Unknown · CVSS Not scored

CVE-2024-43902: drm/amd/display: Add null checker before passing variables

In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null checker before passing variables Checks null pointer before passing variables to functions. This fixes 3 NULL_RETURNS issues reported by Coverity.

Published Aug 26, 2024 · Updated Jun 1, 2026

Unknown · CVSS Not scored

CVE-2024-44944: netfilter: ctnetlink: use helper function to calculate expect ID

In the Linux kernel, the following vulnerability has been resolved: netfilter: ctnetlink: use helper function to calculate expect ID Delete expectation path is missing a call to the nf_expect_get_id() helper function to calculate the expectation ID, otherwise LSB of the expectation object address is leaked to userspace.

Published Aug 30, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43892: memcg: protect concurrent access to mem_cgroup_idr

In the Linux kernel, the following vulnerability has been resolved: memcg: protect concurrent access to mem_cgroup_idr Commit 73f576c04b94 ("mm: memcontrol: fix cgroup creation failure after many small jobs") decoupled the memcg IDs from the CSS ID space to fix the cgroup creation failures. It introduced IDR to maintain the memcg ID space. The IDR depends on external synchronization mechanisms for modifications. For the mem_cgroup_idr, the idr_alloc() and idr_replace() happen within css callback and thus are protected through cgroup_mutex from concurrent modifications. However idr_remove() for mem_cgroup_idr was not protected against concurrency and can be run concurrently for different memcgs when they hit their refcnt to zero. Fix that. We have been seeing list_lru based kernel crashes at a low frequency in our fleet for a long time. These crashes were in different part of list_lru code including list_lru_add(), list_lru_del() and reparenting code. Upon further inspection, it looked like for a given object (dentry and inode), the super_block's list_lru didn't have list_lru_one for the memcg of that object. The initial suspicions were either the object is not allocated through kmem_cache_alloc_lru() or somehow memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but returned success. No evidence were found for these cases. Looking more deeply, we started seeing situations where valid memcg's id is not present in mem_cgroup_idr and in some cases multiple valid memcgs have same id and mem_cgroup_idr is pointing to one of them. So, the most reasonable explanation is that these situations can happen due to race between multiple idr_remove() calls or race between idr_alloc()/idr_replace() and idr_remove(). These races are causing multiple memcgs to acquire the same ID and then offlining of one of them would cleanup list_lrus on the system for all of them. Later access from other memcgs to the list_lru cause crashes due to missing list_lru_one.

Published Aug 26, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43891: tracing: Have format file honor EVENT_FILE_FL_FREED

In the Linux kernel, the following vulnerability has been resolved: tracing: Have format file honor EVENT_FILE_FL_FREED When eventfs was introduced, special care had to be done to coordinate the freeing of the file meta data with the files that are exposed to user space. The file meta data would have a ref count that is set when the file is created and would be decremented and freed after the last user that opened the file closed it. When the file meta data was to be freed, it would set a flag (EVENT_FILE_FL_FREED) to denote that the file is freed, and any new references made (like new opens or reads) would fail as it is marked freed. This allowed other meta data to be freed after this flag was set (under the event_mutex). All the files that were dynamically created in the events directory had a pointer to the file meta data and would call event_release() when the last reference to the user space file was closed. This would be the time that it is safe to free the file meta data. A shortcut was made for the "format" file. It's i_private would point to the "call" entry directly and not point to the file's meta data. This is because all format files are the same for the same "call", so it was thought there was no reason to differentiate them. The other files maintain state (like the "enable", "trigger", etc). But this meant if the file were to disappear, the "format" file would be unaware of it. This caused a race that could be trigger via the user_events test (that would create dynamic events and free them), and running a loop that would read the user_events format files: In one console run: # cd tools/testing/selftests/user_events # while true; do ./ftrace_test; done And in another console run: # cd /sys/kernel/tracing/ # while true; do cat events/user_events/__test_event/format; done 2>/dev/null With KASAN memory checking, it would trigger a use-after-free bug report (which was a real bug). This was because the format file was not checking the file's meta data flag "EVENT_FILE_FL_FREED", so it would access the event that the file meta data pointed to after the event was freed. After inspection, there are other locations that were found to not check the EVENT_FILE_FL_FREED flag when accessing the trace_event_file. Add a new helper function: event_file_file() that will make sure that the event_mutex is held, and will return NULL if the trace_event_file has the EVENT_FILE_FL_FREED flag set. Have the first reference of the struct file pointer use event_file_file() and check for NULL. Later uses can still use the event_file_data() helper function if the event_mutex is still held and was not released since the event_file_file() call.

Published Aug 26, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43883: usb: vhci-hcd: Do not drop references before new references are gained

In the Linux kernel, the following vulnerability has been resolved: usb: vhci-hcd: Do not drop references before new references are gained At a few places the driver carries stale pointers to references that can still be used. Make sure that does not happen. This strictly speaking closes ZDI-CAN-22273, though there may be similar races in the driver.

Published Aug 23, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43877: media: pci: ivtv: Add check for DMA map result

In the Linux kernel, the following vulnerability has been resolved: media: pci: ivtv: Add check for DMA map result In case DMA fails, 'dma->SG_length' is 0. This value is later used to access 'dma->SGarray[dma->SG_length - 1]', which will cause out of bounds access. Add check to return early on invalid value. Adjust warnings accordingly. Found by Linux Verification Center (linuxtesting.org) with SVACE.

Published Aug 21, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43875: PCI: endpoint: Clean up error handling in vpci_scan_bus()

In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Clean up error handling in vpci_scan_bus() Smatch complains about inconsistent NULL checking in vpci_scan_bus(): drivers/pci/endpoint/functions/pci-epf-vntb.c:1024 vpci_scan_bus() error: we previously assumed 'vpci_bus' could be null (see line 1021) Instead of printing an error message and then crashing we should return an error code and clean up. Also the NULL check is reversed so it prints an error for success instead of failure.

Published Aug 21, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43870: perf: Fix event leak upon exit

In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exit When a task is scheduled out, pending sigtrap deliveries are deferred to the target task upon resume to userspace via task_work. However failures while adding an event's callback to the task_work engine are ignored. And since the last call for events exit happen after task work is eventually closed, there is a small window during which pending sigtrap can be queued though ignored, leaking the event refcount addition such as in the following scenario: TASK A ----- do_exit() exit_task_work(tsk); <IRQ> perf_event_overflow() event->pending_sigtrap = pending_id; irq_work_queue(&event->pending_irq); </IRQ> =========> PREEMPTION: TASK A -> TASK B event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) // FAILS: task work has exited task_work_add(&event->pending_task) [...] <IRQ WORK> perf_pending_irq() // early return: event->oncpu = -1 </IRQ WORK> [...] =========> TASK B -> TASK A perf_event_exit_task(tsk) perf_event_exit_event() free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // leak event due to unexpected refcount == 2 As a result the event is never released while the task exits. Fix this with appropriate task_work_add()'s error handling.

Published Aug 21, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43869: perf: Fix event leak upon exec and file release

In the Linux kernel, the following vulnerability has been resolved: perf: Fix event leak upon exec and file release The perf pending task work is never waited upon the matching event release. In the case of a child event, released via free_event() directly, this can potentially result in a leaked event, such as in the following scenario that doesn't even require a weak IRQ work implementation to trigger: schedule() prepare_task_switch() =======> <NMI> perf_event_overflow() event->pending_sigtrap = ... irq_work_queue(&event->pending_irq) <======= </NMI> perf_event_task_sched_out() event_sched_out() event->pending_sigtrap = 0; atomic_long_inc_not_zero(&event->refcount) task_work_add(&event->pending_task) finish_lock_switch() =======> <IRQ> perf_pending_irq() //do nothing, rely on pending task work <======= </IRQ> begin_new_exec() perf_event_exit_task() perf_event_exit_event() // If is child event free_event() WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1) // event is leaked Similar scenarios can also happen with perf_event_remove_on_exec() or simply against concurrent perf_event_release(). Fix this with synchonizing against the possibly remaining pending task work while freeing the event, just like is done with remaining pending IRQ work. This means that the pending task callback neither need nor should hold a reference to the event, preventing it from ever beeing freed.

Published Aug 21, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43866: net/mlx5: Always drain health in shutdown callback

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Always drain health in shutdown callback There is no point in recovery during device shutdown. if health work started need to wait for it to avoid races and NULL pointer access. Hence, drain health WQ on shutdown callback.

Published Aug 20, 2024 · Updated May 23, 2026

Unknown · CVSS Not scored

CVE-2024-43855: md: fix deadlock between mddev_suspend and flush bio

In the Linux kernel, the following vulnerability has been resolved: md: fix deadlock between mddev_suspend and flush bio Deadlock occurs when mddev is being suspended while some flush bio is in progress. It is a complex issue. T1. the first flush is at the ending stage, it clears 'mddev->flush_bio' and tries to submit data, but is blocked because mddev is suspended by T4. T2. the second flush sets 'mddev->flush_bio', and attempts to queue md_submit_flush_data(), which is already running (T1) and won't execute again if on the same CPU as T1. T3. the third flush inc active_io and tries to flush, but is blocked because 'mddev->flush_bio' is not NULL (set by T2). T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc by T3. T1 T2 T3 T4 (flush 1) (flush 2) (third 3) (suspend) md_submit_flush_data mddev->flush_bio = NULL; . . md_flush_request . mddev->flush_bio = bio . queue submit_flushes . . . . md_handle_request . . active_io + 1 . . md_flush_request . . wait !mddev->flush_bio . . . . mddev_suspend . . wait !active_io . . . submit_flushes . queue_work md_submit_flush_data . //md_submit_flush_data is already running (T1) . md_handle_request wait resume The root issue is non-atomic inc/dec of active_io during flush process. active_io is dec before md_submit_flush_data is queued, and inc soon after md_submit_flush_data() run. md_flush_request active_io + 1 submit_flushes active_io - 1 md_submit_flush_data md_handle_request active_io + 1 make_request active_io - 1 If active_io is dec after md_handle_request() instead of within submit_flushes(), make_request() can be called directly intead of md_handle_request() in md_submit_flush_data(), and active_io will only inc and dec once in the whole flush process. Deadlock will be fixed. Additionally, the only difference between fixing the issue and before is that there is no return error handling of make_request(). But after previous patch cleaned md_write_start(), make_requst() only return error in raid5_make_request() by dm-raid, see commit 41425f96d7aa ("dm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape)". Since dm always splits data and flush operation into two separate io, io size of flush submitted by dm always is 0, make_request() will not be called in md_submit_flush_data(). To prevent future modifications from introducing issues, add WARN_ON to ensure make_request() no error is returned in this context.

Published Aug 17, 2024 · Updated May 23, 2026