In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix use-after-free in mlx5e_tx_reporter_timeout_recover mlx5e_tx_reporter_timeout_recover() accesses sq->netdev after mlx5e_safe_reopen_channels() has torn down and freed the channel (and its embedded SQs). Replace the three sq->netdev references with priv->netdev which is safe because priv outlives channel teardown. The netdev_err() call already used priv->netdev for this reason; make the trylock/unlock and health_channel_eq_recover calls consistent. This fixes the following KASAN splat: BUG: KASAN: use-after-free in mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] Read of size 8 at addr ffff889860ed0b28 by task kworker/u113:2/5277 Call Trace: mlx5e_tx_reporter_timeout_recover+0x1dd/0x360 [mlx5_core] devlink_health_reporter_recover+0xa2/0x150 devlink_health_report+0x254/0x7c0 mlx5e_reporter_tx_timeout+0x297/0x380 [mlx5_core] mlx5e_tx_timeout_work+0x109/0x170 [mlx5_core] process_one_work+0x677/0xf20 worker_thread+0x51f/0xd90 kthread+0x3a5/0x810 ret_from_fork+0x208/0x400 ret_from_fork_asm+0x1a/0x30

Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. In versions 8.2.6.4 and prior, the HAProxy section-save endpoints (POST /api/service/haproxy/<server_id>/section/<section_type> and the PUT / global / defaults variants) accept a JSON option field that is not validated, not escaped, and is rendered verbatim into the generated HAProxy configuration via the section.j2, global.j2, and defaults.j2 Ansible templates. Because Roxy-WI then pushes the generated config to the load balancer and runs systemctl reload haproxy, an authenticated user with role ≤ 3 (user) can inject arbitrary HAProxy directives into the config that runs on every load balancer their group manages — including option external-check + external-check command /bin/bash -c '…', which gives remote code execution on the load balancer as the haproxy user on every health-check tick. At time of publication, there are no publicly available patches.

OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0.1, a stored cross-site scripting vulnerability in the prescription CSS/HTML multi-print feature allows a patient portal user to execute arbitrary JavaScript in a clinician's browser session. Patient demographic fields (name, address) are rendered without output encoding in multiprintcss_header(), and portal patients can write attacker-controlled HTML directly into patient_data by calling the PUT api/patient/:num endpoint, which bypasses the intended audit review workflow. Because the XSS fires in the clinician's authenticated session on the main OpenEMR interface, the attacker can access CSRF tokens, session data, and perform actions as the clinician — crossing the patient-to-clinician trust boundary. This issue has been patched in version 8.0.0.1.

open-emr

MongoDB server may log authentication parameters, including credentials, to the server log during SASL authentication. When connection health metric logging is enabled, the full authentication parameters are written to the log without redaction.

mongodb

Improper input validation in Microsoft Azure Attestation service and Device Health Attestation Service allows an authorized attacker to perform spoofing with a physical attack.

microsoft

The Frontier X2 device allows unauthenticated BLE read/write access to critical GATT characteristics without enforcing pairing authentication or authorization. This allows attackers within BLE range to perform unauthorized control of device functions, including starting/stopping activities, triggering vibrations, causing denial-of-service conditions, and fuzzing characteristic values to induce unexpected behavior. Additionally, the Frontier X mobile application lacks proper BLE device authentication, allowing attackers to impersonate a legitimate Frontier X2 device and connect to the application. By cloning BLE advertisements and exposing expected GATT characteristics, attackers can manipulate activity states and inject fabricated health telemetry such as breathing rate, heart rate, strain, and other health-related data into the mobile application.

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix deadlocks between devlink and netdev instance locks In the mentioned "Fixes" commit, various work tasks triggering devlink health reporter recovery were switched to use netdev_trylock to protect against concurrent tear down of the channels being recovered. But this had the side effect of introducing potential deadlocks because of incorrect lock ordering. The correct lock order is described by the init flow: probe_one -> mlx5_init_one (acquires devlink lock) -> mlx5_init_one_devl_locked -> mlx5_register_device -> mlx5_rescan_drivers_locked -...-> mlx5e_probe -> _mlx5e_probe -> register_netdev (acquires rtnl lock) -> register_netdevice (acquires netdev lock) => devlink lock -> rtnl lock -> netdev lock. But in the current recovery flow, the order is wrong: mlx5e_tx_err_cqe_work (acquires netdev lock) -> mlx5e_reporter_tx_err_cqe -> mlx5e_health_report -> devlink_health_report (acquires devlink lock => boom!) -> devlink_health_reporter_recover -> mlx5e_tx_reporter_recover -> mlx5e_tx_reporter_recover_from_ctx -> mlx5e_tx_reporter_err_cqe_recover The same pattern exists in: mlx5e_reporter_rx_timeout mlx5e_reporter_tx_ptpsq_unhealthy mlx5e_reporter_tx_timeout Fix these by moving the netdev_trylock calls from the work handlers lower in the call stack, in the respective recovery functions, where they are actually necessary.

epa4all-client is the Java Client for epa4all / ePA 3.0 in the Telematik Infrastruktur. In 1.2.4 and earlier, any network-reachable caller can write arbitrary documents to any patient's electronic health record accessible by the institution's SMC-B card. In a misconfigured deployment (e.g., following the production Docker example in the README), this is exploitable from the local network without credentials.

phpMyFAQ before 4.1.2 contains an insufficient authorization vulnerability in admin-api routes that allows authenticated ordinary users to access administrative endpoints by only checking login status instead of verifying backend privileges. Attackers with valid frontend user accounts can access sensitive backend operational information including dashboard versions, LDAP configuration, Elasticsearch statistics, and health-check data.

Exposed Keycloak management service in the Arqit Symmetric Key Agreement Platform enables unauthorized access to sensitive debug information such as metrics and health data. This issue affects Symmetric Key Agreement Platform: before 26.03.

A vulnerability has been found in PicoTronica e-Clinic Healthcare System ECHS 5.7. This affects an unknown function of the file /cdemos/echs/api/v2/ of the component Response Header Handler. Such manipulation leads to information disclosure. The attack may be performed from remote. The exploit has been disclosed to the public and may be used. Upgrading to version 5.7.1 mitigates this issue. It is suggested to upgrade the affected component. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

A flaw has been found in PicoTronica e-Clinic Healthcare System ECHS 5.7. The impacted element is an unknown function of the file /cdemos/echs/priv/echs.js. This manipulation of the argument ADMIN_KEY causes hard-coded credentials. The attack is possible to be carried out remotely. The exploit has been published and may be used. Upgrading to version 5.7.1 is sufficient to resolve this issue. The affected component should be upgraded. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

A vulnerability was detected in PicoTronica e-Clinic Healthcare System ECHS 5.7. The affected element is an unknown function of the file /cdemos/echs/api/v2/patient-records of the component API Endpoint. The manipulation results in missing authentication. The attack can be executed remotely. The exploit is now public and may be used. Upgrading to version 5.7.1 is sufficient to fix this issue. You should upgrade the affected component. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

A vulnerability was detected in PrefectHQ prefect up to 3.6.21. This impacts the function endswith of the file /api/health of the component Health Check API. Performing a manipulation results in improper authentication. The attack is possible to be carried out remotely. The exploit is now public and may be used. Upgrading to version 3.6.22 will fix this issue. The patch is named e21617125335025b4b27e7d6f0ca028e8e8f3b79. Upgrading the affected component is recommended. The vendor was contacted early, responded in a very professional manner and quickly released a fixed version of the affected product.

In certain circumstances, Spring Boot's default web security is ineffective allowing unauthorized access to all endpoints. For an application to be vulnerable, it must: be a servlet-based web application; have no Spring Security configuration of its own and rely on the default web security filter chain; depend on spring-boot-actuator-autoconfigure; not depend on spring-boot-health. If any of the above does not apply, the application is not vulnerable. Affected: Spring Boot 4.0.0–4.0.5; upgrade to 4.0.6 or later per vendor advisory.

vmware

In the Linux kernel, the following vulnerability has been resolved: btrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create We have recently observed a number of subvolumes with broken dentries. ls-ing the parent dir looks like: drwxrwxrwt 1 root root 16 Jan 23 16:49 . drwxr-xr-x 1 root root 24 Jan 23 16:48 .. d????????? ? ? ? ? ? broken_subvol and similarly stat-ing the file fails. In this state, deleting the subvol fails with ENOENT, but attempting to create a new file or subvol over it errors out with EEXIST and even aborts the fs. Which leaves us a bit stuck. dmesg contains a single notable error message reading: "could not do orphan cleanup -2" 2 is ENOENT and the error comes from the failure handling path of btrfs_orphan_cleanup(), with the stack leading back up to btrfs_lookup(). btrfs_lookup btrfs_lookup_dentry btrfs_orphan_cleanup // prints that message and returns -ENOENT After some detailed inspection of the internal state, it became clear that: - there are no orphan items for the subvol - the subvol is otherwise healthy looking, it is not half-deleted or anything, there is no drop progress, etc. - the subvol was created a while ago and does the meaningful first btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much later. - after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT, which results in a negative dentry for the subvolume via d_splice_alias(NULL, dentry), leading to the observed behavior. The bug can be mitigated by dropping the dentry cache, at which point we can successfully delete the subvolume if we want. i.e., btrfs_lookup() btrfs_lookup_dentry() if (!sb_rdonly(inode->vfs_inode)->vfs_inode) btrfs_orphan_cleanup(sub_root) test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) btrfs_search_slot() // finds orphan item for inode N ... prints "could not do orphan cleanup -2" if (inode == ERR_PTR(-ENOENT)) inode = NULL; return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolume btrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP) on the root when it runs, so it cannot run more than once on a given root, so something else must run concurrently. However, the obvious routes to deleting an orphan when nlinks goes to 0 should not be able to run without first doing a lookup into the subvolume, which should run btrfs_orphan_cleanup() and set the bit. The final important observation is that create_subvol() calls d_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so if the dentry cache gets dropped, the next lookup into the subvolume will make a real call into btrfs_orphan_cleanup() for the first time. This opens up the possibility of concurrently deleting the inode/orphan items but most typical evict() paths will be holding a reference on the parent dentry (child dentry holds parent->d_lockref.count via dget in d_alloc(), released in __dentry_kill()) and prevent the parent from being removed from the dentry cache. The one exception is delayed iputs. Ordered extent creation calls igrab() on the inode. If the file is unlinked and closed while those refs are held, iput() in __dentry_kill() decrements i_count but does not trigger eviction (i_count > 0). The child dentry is freed and the subvol dentry's d_lockref.count drops to 0, making it evictable while the inode is still alive. Since there are two races (the race between writeback and unlink and the race between lookup and delayed iputs), and there are too many moving parts, the following three diagrams show the complete picture. (Only the second and third are races) Phase 1: Create Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP set btrfs_mksubvol() lookup_one_len() __lookup_slow() d_alloc_parallel() __d_alloc() // d_lockref.count = 1 create_subvol(dentry) // doesn't touch the bit.. d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.c ---truncated---

linux

A vulnerability was detected in arnobt78 Hotel Booking Management System up to f8922d0e0f6ac1cc761974c7616f44c2bbc04bea. The impacted element is an unknown function of the file /api/health/detailed of the component Health Check Endpoint. Performing a manipulation results in information disclosure. Remote exploitation of the attack is possible. The exploit is now public and may be used. This product follows a rolling release approach for continuous delivery, so version details for affected or updated releases are not provided. The patch is named d47ae0e27c700b64dc417f7f01b84a6b1b0b6bd3. To fix this issue, it is recommended to deploy a patch.

OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Versions prior to 7.15.2 contain a configuration-dependent authentication bypass in deployments where OAuth2 Proxy is used with an auth_request-style integration (such as nginx auth_request) and either --ping-user-agent is set or --gcp-healthchecks is enabled. In affected configurations, OAuth2 Proxy treats any request with the configured health check User-Agent value as a successful health check regardless of the requested path, allowing an unauthenticated remote attacker to bypass authentication and access protected upstream resources. Deployments that do not use auth_request-style subrequests or that do not enable --ping-user-agent/--gcp-healthchecks are not affected. This issue is fixed in 7.15.2.

oauth2_proxy_project

An Exposure of Sensitive Information to an Unauthorized Actor vulnerability exists in Apache DolphinScheduler. This vulnerability may allow unauthorized actors to access sensitive information, including database credentials. This issue affects Apache DolphinScheduler versions 3.1.*. Users are recommended to upgrade to: * version ≥ 3.2.0 if using 3.1.x As a temporary workaround, users who cannot upgrade immediately may restrict the exposed management endpoints by setting the following environment variable: ``` MANAGEMENT_ENDPOINTS_WEB_EXPOSURE_INCLUDE=health,metrics,prometheus ``` Alternatively, add the following configuration to the application.yaml file: ``` management:    endpoints:      web:         exposure:           include: health,metrics,prometheus ``` This issue has been reported as CVE-2023-48796: https://cveprocess.apache.org/cve5/CVE-2023-48796

apache

PraisonAI is a multi-agent teams system. Prior to 4.5.115, the A2U (Agent-to-User) event stream server in PraisonAI exposes all agent activity without authentication. The create_a2u_routes() function registers the following endpoints with NO authentication checks: /a2u/info, /a2u/subscribe, /a2u/events/{stream_name}, /a2u/events/sub/{id}, and /a2u/health. This vulnerability is fixed in 4.5.115.

praison

Netgate AMITI Antivirus build 23.0.305 contains an unquoted service path vulnerability in the AmitiAvSrv and AmitiAntivirusHealth services that allows local attackers to escalate privileges. Attackers can place a malicious executable in the unquoted service path and trigger service restart or system reboot to execute code with LocalSystem privileges.

netgate

Spy Emergency build 23.0.205 contains an unquoted service path vulnerability in the SpyEmrgHealth and SpyEmrgSrv services that allows local attackers to escalate privileges by inserting malicious executables. Attackers can place executable files in the unquoted service path and trigger service restart or system reboot to execute code with LocalSystem privileges.