Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-75627 | 9.3 critical | 1.0% | no CPE yet | Bastillion fails to properly validate request URI paths in its controller dispatcher, allowing unauthenticated attackers to bypass authentication filters by prefixing requests with arbitrary path segments. Attackers can access administrative controllers to read user listings, create manager accounts, and register managed systems, gaining control over SSH access to the managed fleet. | Thu 22 Oct |
| CVE-2026-71471 | 9.0 critical | 1.0% | no CPE yet | A flaw was found in acm-search-v2-rhel9. An attacker with administrative privileges on the hub cluster, specifically with patch access to the Search Custom Resource (CR), could exploit a vulnerability in the `Collector.ImageOverride` field. This allows the attacker to deploy an arbitrary container image across all managed clusters. The consequence is remote code execution (RCE), enabling the attacker to execute commands and potentially access sensitive information across the entire fleet of managed clusters. | Sat 24 Oct |
| CVE-2026-74576 | 7.5 high | 1.0% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: mm/slab: prevent unbounded recursion in free path with new kmalloc type Commit 280ea9c3154b ("mm/slab: avoid allocating slabobj_ext array from its own slab") avoided recursive allocation of obj_exts from kmalloc caches of the same size, by bumping the obj_exts array's allocation size whenever the array size equals the size of the object being allocated. However, as reported by Danielle Costantino and Shakeel Butt, even slabs from kmalloc caches of different sizes can form a cycle by allocating obj_exts arrays from each other [1]: What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL cache, so the "slab holds another slab's obj_exts array" relation can form cycles. With sizeof(struct slabobj_ext) == 16 and the host's geometry: - kmalloc-512 has 64 objects/slab -> array is 64*16 == 1024 bytes, served from kmalloc-1k; - kmalloc-1k has 32 objects/slab -> array is 32*16 == 512 bytes, served from kmalloc-512. A kmalloc-512 slab and a kmalloc-1k slab therefore hold each other's obj_exts array. Discarding one frees the other's array, which empties and discards that slab, which frees the first's array, and so on: __free_slab() -> free_slab_obj_exts() -> kfree() -> discard_slab() -> __free_slab() recurses along the cycle until the stack is exhausted. With memory allocation profiling, this allows unbounded recursion in the free path and led to a stack overflow on a production host in the Meta fleet [1]: BUG: TASK stack guard page was hit Oops: stack guard page RIP: 0010:kfree+0x8/0x5d0 Call Trace: __free_slab+0x66/0xc0 kfree+0x3f0/0x5d0 ... ( ~125x __free_slab <-> kfree ) ... <kernel driver freeing a resource> do_syscall_64 It is proposed [1] to resolve this issue by always serving the obj_exts array allocation from kmalloc caches (or large kmalloc) of sizes larger than the object size. However, as pointed out by Vlastimil Babka [2], this can waste an excessive amount of memory as slabs from large kmalloc sizes (e.g. kmalloc-8k) generally need obj_exts arrays much smaller than the object size. Therefore, rather than bumping the size, let us take a different approach; disallow formation of cycles between kmalloc types when allocating obj_exts arrays. Currently, all obj_exts arrays are served from normal kmalloc caches. Cycles cannot be created if obj_exts arrays of normal kmalloc caches are served from a special kmalloc type that can never have obj_exts arrays. To achieve this, create a new kmalloc type called KMALLOC_NO_OBJ_EXT. KMALLOC_NO_OBJ_EXT caches are created with SLAB_NO_OBJ_EXT flag when either 1) memory allocation profiling is not permanently disabled, or 2) kmalloc types with a priority higher than KMALLOC_CGROUP are aliased with KMALLOC_NORMAL. Sheaf bootstrapping for KMALLOC_NO_OBJ_EXT caches now must be deferred because allocation of a barn can trigger obj_exts array allocation of normal kmalloc caches when the KMALLOC_NO_OBJ_EXT cache for that size is not ready yet. For simplicity, perform bootstrapping of sheaves for all kmalloc caches later. Introduce a new slab alloc flag, SLAB_ALLOC_NO_OBJ_EXT, to prevent allocation of obj_exts arrays, and let kmalloc_slab() override the type to KMALLOC_NO_OBJ_EXT when specified. Note that kmalloc_type() remains unchanged because kmalloc_flags() bypasses the kmalloc fastpath. Do not pass SLAB_ALLOC_NO_RECURSE to kmalloc_flags() in alloc_slab_obj_exts() and instead use SLAB_ALLOC_NO_OBJ_EXT only when the objects are allocated from normal kmalloc caches. While this prevents unbounded recursive allocation of obj_exts, it allows KMALLOC_NO_OBJ_EXT caches to have sheaves. Since sheaf allocations specify SLAB_ALLOC_NO_RECURSE that prevents allocation of both sheaves and obj_exts arrays, the recursion depth is bounded. obj_exts arrays for non- ---truncated--- | 16 Oct |
| CVE-2026-26191 | 6.0 medium | 1.0% | fleetdm, fleet | Fleet is open source device management software. Prior to version 4.81.0, a vulnerability in Fleet's software installer pipeline could allow a crafted software package to execute arbitrary commands as root (macOS/Linux) or SYSTEM (Windows) on managed endpoints when an uninstall is triggered. When a software package (.pkg, .deb, .rpm, .exe, or .msi) is uploaded to Fleet, metadata is extracted from the package binary and used to generate uninstall scripts. In affected versions, this metadata is not properly sanitized before being included in the generated scripts. A specially crafted package containing malicious values in its metadata fields could result in unintended command execution when the uninstall script runs on managed endpoints. Version 4.81.0 contains a patch. If an immediate upgrade is not possible, administrators should avoid uploading software packages obtained from untrusted or unverified sources. Additionally, administrators can manually inspect and edit auto-generated uninstall scripts before deployment. | Mon 26 Oct |
| CVE-2026-34387 | 5.7 medium | 1.0% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.1, a command injection vulnerability in Fleet's software installer pipeline allows an attacker to achieve arbitrary code execution as root (macOS/Linux) or SYSTEM (Windows) on managed hosts when an uninstall is triggered for a crafted software package. Version 4.81.1 patches the issue. | Mon 26 Oct |
| CVE-2026-41050 | 9.9 critical | 0.00% | suse, rancher_fleet | Fleet's Helm deployer did not fully apply ServiceAccount impersonation in two code paths, allowing a tenant with git push access to a Fleet-monitored repository to read secrets from any namespace on every downstream cluster targeted by their `GitRepo`. | Mon 26 Oct |
| CVE-2026-44935 | 9.9 critical | 0.00% | suse, rancher_fleet | Missing validation of "valuesFrom" references in Helm Deployer of SUSE Rancher Fleet 0.15 before 0.15.2, 0.14 before 0.14.6, 0.13 before 0.13.11 and 0.12 before 0.12.15 could be used by owners of one tenant to access fleet credentials of other tenants. | Sun 25 Oct |
| CVE-2026-103264 | 9.3 critical | 0.00% | fleetdm, fleet | Fleet versions before 4.87.0 contain an authentication bypass vulnerability in the device API that accepts hostnames and hardware serials as authentication tokens in addition to device UUIDs. Unauthenticated attackers who know or guess these non-secret identifiers can authenticate as iOS/iPadOS hosts to read device data and trigger device-scoped actions including software installation and MDM migration. | 8 Oct |
| CVE-2026-44938 | 8.8 high | 0.00% | suse, rancher_fleet | A vulnerability has been identified in Fleet's agent-side deployer, which did not filter security-sensitive keys from namespaceLabels in fleet.yaml (or BundleDeployment.spec.options.namespaceLabels) when applying them to the target namespace. An attacker with git push access to a Fleet-monitored repository could overwrite Pod Security Standards (PSS) enforcement labels on a target namespace. This allows the attacker to weaken admission controls and deploy workloads that PSS policies would otherwise block. | Sun 25 Oct |
| CVE-2026-102406 | 8.8 high | 0.00% | elastic, kibana | Authorization Bypass Through User-Controlled Key (CWE-639) in Kibana could lead to cross-tenant data interception. In this context, "tenant" refers to a user or team sharing the same Kibana deployment, not a separate Elastic Cloud organization or customer. Kibana's Fleet package installation process allowed a user holding delegated Fleet package-management privileges, without direct Elasticsearch administrative privileges, to claim a data stream identifier already in use by another tenant. Because ownership of that identifier was not verified before Fleet applied the uploaded package's generated index and ingest-pipeline settings to already-existing infrastructure, an attacker could redirect an existing tenant's data stream through infrastructure under their control. This exposed the affected tenant's subsequently ingested data to unauthorized disclosure and modification, and prevented that data from reaching its intended destination. Interception could continue even after the malicious package was removed, requiring separate remediation of the affected infrastructure. | 13 Oct |
| CVE-2026-107205 | 8.8 high | 0.00% | no CPE yet | LMCache through 0.5.5 contains a missing authentication vulnerability in the multiprocess coordinator that allows remote unauthenticated attackers to access its HTTP fleet control API listening on all interfaces by default. Attackers can register or deregister instances via /instances, overwrite quotas via /quota endpoints, inject events via /events, and enumerate /directory/keys to disrupt caching and disclose placement metadata. | 8 Oct |
| CVE-2026-26061 | 8.7 high | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.0, Fleet contained multiple unauthenticated HTTP endpoints that read request bodies without enforcing a size limit. An unauthenticated attacker could exploit this behavior by sending large or repeated HTTP payloads, causing excessive memory allocation and resulting in a denial-of-service (DoS) condition. Version 4.81.0 patches the issue. | Mon 26 Oct |
| CVE-2026-26062 | 8.7 high | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to version 4.81.0, Fleet contained a denial-of-service (DoS) issue in the gRPC Launcher `PublishLogs` endpoint. In affected versions, certain unexpected input values were not handled gracefully, which could cause the Fleet server process to terminate while processing an authenticated request from an enrolled Launcher host. An authenticated attacker with access to any enrolled Launcher node key could cause an immediate and complete denial of service by sending a single gRPC request to the `PublishLogs` endpoint. This vulnerability impacts availability only. There is no exposure of sensitive data, no authentication bypass, no privilege escalation, and no integrity impact. Version 4.81.0 contains a patch. If upgrading immediately is not possible, the following mitigations can reduce exposure. Restrict network access to the Fleet gRPC endpoint where feasible (for example, limiting inbound access to known host IP ranges); deploy Fleet behind infrastructure that terminates or filters gRPC traffic if Launcher log ingestion is not required; and/or monitor for repeated Fleet process crashes or unexpected restarts indicating potential exploitation. | Mon 26 Oct |
| CVE-2026-111924 | 8.7 high | 0.00% | no CPE yet | Fleet before 4.83.0 contains a denial of service vulnerability that allows unauthenticated attackers to exhaust server memory by sending gzip-compressed request bodies. Attackers can send small, highly compressed requests with Content-Encoding: gzip to unauthenticated endpoints that expand during decoding, crashing the entire Fleet instance. | 19 Oct |
| CVE-2026-111923 | 8.7 high | 0.00% | no CPE yet | Fleet before 4.89.0 contains an unbounded recursion vulnerability in Apple MDM enrollment property list parsing that allows unauthenticated attackers to crash the server. Attackers can send a crafted binary plist payload of about 150 bytes to the enrollment endpoints, triggering exponential allocation or infinite recursion that exhausts CPU and memory. | 19 Oct |
| CVE-2026-44937 | 8.3 high | 0.00% | suse, rancher_fleet | Potential forgery of webhook requests when using a unauthenticated webhook in SUSE Rancher Fleet 0.15 before 0.15.2, 0.14 before 0.14.6, 0.13 before 0.13.11 and 0.12 before 0.12.5 could be used by remote attackers to cause a denial of service or a downgrade attack on other repositories on the system. | Sun 25 Oct |
| CVE-2026-23998 | 8.2 high | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to version 4.81.0, a vulnerability in Fleet’s Windows MDM management endpoint could allow requests to be processed without proper client certificate validation. In certain circumstances, this could allow an attacker to impersonate an enrolled Windows device and retrieve sensitive configuration data. Fleet’s Windows MDM management endpoint relies on mutual TLS (mTLS) client certificates to authenticate enrolled devices. In affected versions, requests that did not present a client certificate could be incorrectly treated as trusted. As a result, an attacker with prior knowledge of a valid enrolled device identifier could potentially impersonate that device and receive configuration payloads intended for it. These payloads may contain sensitive information such as Wi-Fi or VPN configuration data, certificates, or other secrets delivered through MDM profiles. This issue does not allow enrollment of new devices, administrative access to Fleet, or compromise of the Fleet control plane. Impact is limited to the targeted Windows device. Version 4.81.0 contains a patch. If an immediate upgrade is not possible, affected Fleet users should temporarily disable Windows MDM. | Mon 26 Oct |
| CVE-2026-24899 | 8.2 high | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to version 4.82.0, a vulnerability in Fleet's Windows MDM enrollment flow allows authentication tokens from any Azure AD tenant to be accepted. Because Fleet validates JWT signatures using Microsoft's multi-tenant JWKS endpoint but does not enforce the `aud` (audience) or `iss` (issuer) claims, any Microsoft-signed Azure AD access token containing the expected scopes can be used to authenticate to Fleet's MDM endpoints. If Windows MDM is enabled, an attacker with access to any Azure AD tenant can obtain a valid Microsoft-signed token and use it to enroll unauthorized devices and interact with Fleet's MDM management APIs. During device management, Fleet may expose sensitive enrollment secrets embedded in MDM command payloads, enabling further unauthorized access. Version 4.82.0 contains a patch. If an immediate upgrade is not possible, affected Fleet users should temporarily disable Windows MDM. | Mon 26 Oct |
| CVE-2026-71308 | 8.1 high | 0.00% | no CPE yet | Lemur manages TLS certificate creation. From 0.5.0 until 1.9.3, certificate create, upload, and edit requests accepted replaces[] or replacements identifiers that AssociatedCertificateSchema resolved with fetch_objects without a CertificatePermission check. Assigning those objects to Certificate.replaces invoked an append listener that disabled the victim certificate notifications and marked it as replaced. The victim was then excluded from get_all_pending_reissue, and certificate_rotate could deploy the attacker certificate to endpoints serving the victim. An authenticated non-read-only user could target certificates for which the user had no ownership or role, suppress lifecycle automation, and cause fleet-wide TLS disruption or unauthorized substitution. The fix authorizes every referenced replacement certificate before mutation. This issue is fixed in version 1.9.3. | Thu 22 Oct |
| CVE-2026-31586 | 7.8 high | 0.00% | linux, linux_kernel | In the Linux kernel, the following vulnerability has been resolved: mm: blk-cgroup: fix use-after-free in cgwb_release_workfn() cgwb_release_workfn() calls css_put(wb->blkcg_css) and then later accesses wb->blkcg_css again via blkcg_unpin_online(). If css_put() drops the last reference, the blkcg can be freed asynchronously (css_free_rwork_fn -> blkcg_css_free -> kfree) before blkcg_unpin_online() dereferences the pointer to access blkcg->online_pin, resulting in a use-after-free: BUG: KASAN: slab-use-after-free in blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) Write of size 4 at addr ff11000117aa6160 by task kworker/71:1/531 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> blkcg_unpin_online (./include/linux/instrumented.h:112 ./include/linux/atomic/atomic-instrumented.h:400 ./include/linux/refcount.h:389 ./include/linux/refcount.h:432 ./include/linux/refcount.h:450 block/blk-cgroup.c:1367) cgwb_release_workfn (mm/backing-dev.c:629) process_scheduled_works (kernel/workqueue.c:3278 kernel/workqueue.c:3385) Freed by task 1016: kfree (./include/linux/kasan.h:235 mm/slub.c:2689 mm/slub.c:6246 mm/slub.c:6561) css_free_rwork_fn (kernel/cgroup/cgroup.c:5542) process_scheduled_works (kernel/workqueue.c:3302 kernel/workqueue.c:3385) ** Stack based on commit 66672af7a095 ("Add linux-next specific files for 20260410") I am seeing this crash sporadically in Meta fleet across multiple kernel versions. A full reproducer is available at: https://github.com/leitao/debug/blob/main/reproducers/repro_blkcg_uaf.sh (The race window is narrow. To make it easily reproducible, inject a msleep(100) between css_put() and blkcg_unpin_online() in cgwb_release_workfn(). With that delay and a KASAN-enabled kernel, the reproducer triggers the splat reliably in less than a second.) Fix this by moving blkcg_unpin_online() before css_put(), so the cgwb's CSS reference keeps the blkcg alive while blkcg_unpin_online() accesses it. | 19 Oct |
| CVE-2026-56150 | 7.5 high | 0.00% | elastic, fleet_server | Allocation of Resources Without Limits or Throttling (CWE-770) in Fleet Server can lead to a denial of service via Excessive Allocation (CAPEC-130). An attacker can submit a specially crafted request to an upload endpoint that causes excessive memory consumption, which may render Fleet Server unavailable. | Sun 25 Oct |
| CVE-2026-67180 | 7.5 high | 0.00% | no CPE yet | Google Turbinia allows arbitrary command execution via worker tasks. An attacker with privileges to submit a processing request or influence an evidence path/name obtains code execution on the worker fleet. Fixed on 2026-07-10. | Sat 24 Oct |
| CVE-2026-71417 | 7.3 high | 0.00% | no CPE yet | Lemur manages TLS certificate creation. Prior to 1.9.3, POST /api/1/certificates/upload allowed a non-read-only user to create a duplicate row using another certificate body, authority_id, serial, or external_id without requiring permission on the underlying authority. PUT /api/1/certificates//revoke authorized the caller against only the selected Lemur row, so the creator of the duplicate bypassed CertificatePermission. The duplicate had no cert.endpoints, which also bypassed the safeguard that prevents revocation of deployed certificates. Issuer plugins then revoked the real CA-side certificate using certificate.body or external_id under the stored authority credentials. An attacker could therefore revoke arbitrary managed certificates and cause fleet-wide TLS denial of service. The fix rejects duplicate authority_id and serial identities, requires authority access on upload, and checks every matching row during revocation. This issue is fixed in version 1.9.3. | Thu 22 Oct |
| CVE-2026-74045 | 7.1 high | 0.00% | no CPE yet | Wazuh from 3.12.0 before 4.14.8 contains a heap buffer overflow in fim_generate_alert() where full_log is sized from input but written bounded by OS_MAXSTR. An enrolled agent can send a crafted FIM syscheck event to corrupt manager heap memory and deterministically crash wazuh-analysisd, causing a fleet-wide detection outage. | Mon 26 Oct |
| CVE-2026-24000 | 6.9 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to version 4.80.1, Fleet trusted client-supplied IP address headers when determining the source IP for incoming requests. This allowed authenticated and unauthenticated clients to spoof their apparent IP address and bypass per-IP rate limiting controls. Fleet determines a client’s public IP address using HTTP headers such as X-Forwarded-For, X-Real-IP, and/or True-Client-IP. These headers were trusted without validation. An attacker could supply arbitrary values in these headers, causing Fleet to treat each request as originating from a different IP address. This could allow an attacker to bypass per-IP rate limits and increase the effectiveness of brute-force or password-spraying attempts against authentication endpoints. This issue does not allow authentication bypass, privilege escalation, data exposure, or remote code execution on its own. Version 4.80.1 contains a patch. As a workaround, run Fleet behind a trusted reverse proxy or load balancer that overwrites client IP headers. | Mon 26 Oct |
| CVE-2026-46356 | 6.9 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to version 4.80.1, a vulnerability in Fleet's IP extraction logic allows unauthenticated attackers to bypass API rate limiting by spoofing client IP headers. This may allow brute-force login attempts or other abuse against Fleet instances exposed to the public internet. Fleet extracted client IP addresses from request headers (`True-Client-IP`, `X-Real-IP`, `X-Forwarded-For`) without validating that those headers originate from a trusted proxy. The extracted IP is used as the key for rate limiting and IP ban decisions. As a result, an attacker could rotate the value of these headers on each request, causing Fleet to treat each attempt as coming from a different client. This effectively bypasses per-IP rate limits on sensitive endpoints such as the login API, enabling unrestricted brute-force or credential stuffing attacks. This issue primarily affects Fleet instances that are directly exposed to the internet without a reverse proxy that overwrites forwarded-IP headers. Instances behind a properly configured proxy or WAF are less affected. Version 4.80.1 contains a patch. If an immediate upgrade is not possible, administrators should ensure Fleet is deployed behind a reverse proxy (e.g., nginx, Cloudflare, AWS ALB) that overwrites `X-Forwarded-For` with the true client IP, and apply rate limiting at the proxy or WAF layer. | Mon 26 Oct |
| CVE-2026-34391 | 6.6 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.1, a vulnerability in Fleet's Windows MDM command processing allows a malicious enrolled device to access MDM commands intended for other devices, potentially exposing sensitive configuration data such as WiFi credentials, VPN secrets, and certificate payloads across the entire Windows fleet. Version 4.81.1 patches the issue. | Mon 26 Oct |
| CVE-2026-34388 | 6.6 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.0, a denial-of-service vulnerability in Fleet's gRPC Launcher endpoint allows an authenticated host to crash the entire Fleet server process by sending an unexpected log type value. The server terminates immediately, disrupting all connected hosts, MDM enrollments, and API consumers. Version 4.81.0 patches the issue. | Mon 26 Oct |
| CVE-2026-56151 | 6.5 medium | 0.00% | elastic, kibana | Improper Input Validation (CWE-20) in Kibana can lead to a denial of service via Input Data Manipulation (CAPEC-153). An authenticated user can submit a specially crafted Fleet policy input that is not correctly validated, which can render Fleet agent, server, and policy management functionality unavailable. | Sun 25 Oct |
| CVE-2026-102412 | 6.5 medium | 0.00% | elastic, kibana | Incorrect Authorization (CWE-863) in Kibana can lead to sensitive information disclosure via Accessing Functionality Not Properly Constrained by ACLs (CAPEC-1). An authenticated Kibana user with limited Fleet management privileges could access sensitive credential material that should be restricted to users with Fleet settings administrative access. Successful exploitation could allow an attacker to obtain private cryptographic key material configured for Fleet Server host connections, potentially enabling impersonation of trusted Fleet infrastructure components in deployments where those keys are actively used. | 9 Oct |
| CVE-2026-34386 | 6.3 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.0, a SQL injection vulnerability in Fleet's MDM bootstrap package configuration allows an authenticated user with Team Admin or Global Admin privileges to modify arbitrary team configurations, exfiltrate sensitive data from the Fleet database, and inject arbitrary content into team configs via direct API calls. Version 4.81.0 patches the issue. | Mon 26 Oct |
| CVE-2025-23390 | 6.3 medium | 0.00% | no CPE yet | A vulnerability has been identified within Fleet where, by default, Fleet will automatically trust a remote server’s certificate when connecting through SSH if the certificate isn’t set in the `known_hosts` file. This could allow the execution of a man-in-the-middle (MitM) attack against Fleet. In case the server that is being connected to has a trusted entry in the known_hosts file, then Fleet will correctly check the authenticity of the presented certificate. | 19 Oct |
| CVE-2026-34385 | 6.2 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.0, a second-order SQL injection vulnerability in Fleet's Apple MDM profile delivery pipeline could allow an attacker with a valid MDM enrollment certificate to exfiltrate or modify the contents of the Fleet database, including user credentials, API tokens, and device enrollment secrets. Version 4.81.0 patches the issue. | Mon 26 Oct |
| CVE-2025-13819 | 6.1 medium | 0.00% | no CPE yet | Open redirect in the web server component of MiR Robot and Fleet software allows a remote attacker to redirect users to arbitrary external websites via a crafted parameter, facilitating phishing or social engineering attacks. | 18 Oct |
| CVE-2026-26060 | 6.0 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.0, a vulnerability in Fleet’s password management logic could allow previously issued password reset tokens to remain valid after a user changes their password. As a result, a stale password reset token could be reused to reset the account password even after a defensive password change. Version 4.81.0 patches the issue. | Mon 26 Oct |
| CVE-2026-57294 | 5.4 medium | 0.00% | jenkins, ec2_fleet | A missing permission check in Jenkins EC2 Fleet Plugin 4.2.3.539.v8fedff2a_81c3 and earlier allows attackers with Overall/Read permission to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing AWS credentials stored in Jenkins. | Sun 25 Oct |
| CVE-2026-57295 | 5.4 medium | 0.00% | jenkins, ec2_fleet | A cross-site request forgery (CSRF) vulnerability in Jenkins EC2 Fleet Plugin 4.2.3.539.v8fedff2a_81c3 and earlier allows attackers to connect to an attacker-specified URL using attacker-specified credentials IDs obtained through another method, capturing AWS credentials stored in Jenkins. | Sun 25 Oct |
| CVE-2026-44948 | 5.3 medium | 0.00% | suse, rancher_fleet | A path traversal vulnerability was found in Fleet's ImageScan subsystem in Rancher Fleet 0.12.0 up to 0.12.16, 0.13.0 up to 0.13.12, 0.14.0 up to 0.14.7 and 0.15.0 up to 0.15.3 could be used to traverse outside of the intended directory, causing a denial of service. | Sun 25 Oct |
| CVE-2026-103265 | 5.3 medium | 0.00% | fleetdm, fleet | Fleet versions before 4.89.0 fail to properly filter MDM command results by team authorization in the commands/results endpoint. Team-scoped users can read MDM command results for hosts on other teams when a shared command UUID targets hosts across multiple teams, exposing host UUIDs, command payloads, and device responses. | 8 Oct |
| CVE-2026-44936 | 5.0 medium | 0.00% | suse, rancher_fleet | Missing filtering when the helmRepoURLRegex field isn't set on a GitRepo resource in SUSE Rancher Fleet's bundle reader in 0.15 before 0.15.2, 0.14 before 0.14.6, 0.13 before 0.13.11 and 0.12 before 0.12.15 forwards Helm authentication credentials (BasicAuth) to any URL specified in the helm.repo field of a fleet.yaml file, allowing attackers able to push to fleet monitored git repos to leak helm access credentials. | Sun 25 Oct |
| CVE-2026-29180 | 4.9 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.1, a broken access control vulnerability in Fleet's host transfer API allows a team maintainer to transfer hosts from any team into their own team, bypassing team isolation boundaries. Once transferred, the attacker gains full control over the stolen hosts, including the ability to execute scripts with root privileges. Version 4.81.1 patches the issue. | Mon 26 Oct |
| CVE-2026-34389 | 4.9 medium | 0.00% | fleetdm, fleet | Fleet is open source device management software. Prior to 4.81.0, Fleet contained an issue in the user invitation flow where the email address provided during invite acceptance was not validated against the email address associated with the invite. An attacker who obtained a valid invite token could create an account under an arbitrary email address while inheriting the role granted by the invite, including global admin. Version 4.81.0 patches the issue. | Mon 26 Oct |
| CVE-2026-89987 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: transfer the pmd dirty bit to the folio on zap zap_huge_pmd_folio() propagates the pmd young bit to the folio for the file case, but not the dirty bit. The pte path does propagate it, in zap_present_folio_ptes() and so does the pmd split path, in __split_huge_pmd_locked(). For most file mappings the omission is harmless, because writing to a shared file mapping goes through page_mkwrite(), which dirties the folio. tmpfs is different: it has no page_mkwrite(), and vma_wants_writenotify() is false for it, so a *read* fault on a MAP_SHARED tmpfs mapping installs a writable pmd via do_read_fault(). do_read_fault() does not call fault_dirty_shared_page(), so subsequent stores through that mapping set only the hardware dirty bit in the pmd and never call folio_mark_dirty(). A shmem folio allocated by a fault is marked uptodate but not dirty (see the clear: block in shmem_get_folio_gfp()), so PG_dirty is never set at all. Unmapping such a folio - munmap(), or exit_mmap() when the process dies - then loses the only record that it was written, because zap_huge_pmd() drops the pmd without transferring the dirty bit. Reclaim afterwards sees a clean shmem folio: the whole swap-out block in shrink_folio_list() is inside "if (folio_test_dirty(folio))", so pageout() is skipped and the folio falls into __remove_mapping(). There, folio_is_file_lru() is false for a swapbacked folio, so no shadow entry is created and __filemap_remove_folio(folio, NULL) simply empties the i_pages slot. The data is freed without ever being written to swap, and the next fault on that index returns a freshly zeroed folio. This is silent data loss for any process that keeps state in a MAP_SHARED tmpfs segment across an unmap - for example a cache handed from one process generation to the next through /dev/shm. It requires the folio to be PMD-mapped, so it only shows up once shmem THP is enabled (which is what we did in Meta fleet and started noticing crashes); with THP off the pte path transfers the dirty bit correctly. It also only becomes visible when swap is enabled, because with no swap device shmem folios (which are on the anon LRU) are not scanned by reclaim at all, so the clean folio is never dropped. Reproduced on x86_64 with a tmpfs mounted huge=within_size: read-fault a 2MB-backed region, write a known pattern through the resulting mapping, munmap, force reclaim of the cgroup, then re-map and read back. Without this patch the region reads back as zeros and vmstat shows zswpout 0 - the data was discarded rather than swapped. With this patch the region reads back correctly and the pages are swapped out as expected. With huge=never, or when the first touch is a write, the test passes either way. | 21 Oct |
| CVE-2025-40246 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: xfs: fix out of bounds memory read error in symlink repair xfs/286 produced this report on my test fleet: ================================================================== BUG: KFENCE: out-of-bounds read in memcpy_orig+0x54/0x110 Out-of-bounds read at 0xffff88843fe9e038 (184B right of kfence-#184): memcpy_orig+0x54/0x110 xrep_symlink_salvage_inline+0xb3/0xf0 [xfs] xrep_symlink_salvage+0x100/0x110 [xfs] xrep_symlink+0x2e/0x80 [xfs] xrep_attempt+0x61/0x1f0 [xfs] xfs_scrub_metadata+0x34f/0x5c0 [xfs] xfs_ioc_scrubv_metadata+0x387/0x560 [xfs] xfs_file_ioctl+0xe23/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 kfence-#184: 0xffff88843fe9df80-0xffff88843fe9dfea, size=107, cache=kmalloc-128 allocated by task 3470 on cpu 1 at 263329.131592s (192823.508886s ago): xfs_init_local_fork+0x79/0xe0 [xfs] xfs_iformat_local+0xa4/0x170 [xfs] xfs_iformat_data_fork+0x148/0x180 [xfs] xfs_inode_from_disk+0x2cd/0x480 [xfs] xfs_iget+0x450/0xd60 [xfs] xfs_bulkstat_one_int+0x6b/0x510 [xfs] xfs_bulkstat_iwalk+0x1e/0x30 [xfs] xfs_iwalk_ag_recs+0xdf/0x150 [xfs] xfs_iwalk_run_callbacks+0xb9/0x190 [xfs] xfs_iwalk_ag+0x1dc/0x2f0 [xfs] xfs_iwalk_args.constprop.0+0x6a/0x120 [xfs] xfs_iwalk+0xa4/0xd0 [xfs] xfs_bulkstat+0xfa/0x170 [xfs] xfs_ioc_fsbulkstat.isra.0+0x13a/0x230 [xfs] xfs_file_ioctl+0xbf2/0x10e0 [xfs] __x64_sys_ioctl+0x76/0xc0 do_syscall_64+0x4e/0x1e0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 CPU: 1 UID: 0 PID: 1300113 Comm: xfs_scrub Not tainted 6.18.0-rc4-djwx #rc4 PREEMPT(lazy) 3d744dd94e92690f00a04398d2bd8631dcef1954 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-4.module+el8.8.0+21164+ed375313 04/01/2014 ================================================================== On further analysis, I realized that the second parameter to min() is not correct. xfs_ifork::if_bytes is the size of the xfs_ifork::if_data buffer. if_bytes can be smaller than the data fork size because: (a) the forkoff code tries to keep the data area as large as possible (b) for symbolic links, if_bytes is the ondisk file size + 1 (c) forkoff is always a multiple of 8. Case in point: for a single-byte symlink target, forkoff will be 8 but the buffer will only be 2 bytes long. In other words, the logic here is wrong and we walk off the end of the incore buffer. Fix that. | 19 Oct |
| CVE-2026-89756 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: mm/migrate: report RCU-tasks quiescent states in migrate_pages_batch() migrate_pages_batch() unmaps each folio before moving it, and every unmap runs the mmu_notifier invalidate callbacks. On KVM hosts try_to_migrate() ends up in kvm_mmu_notifier_invalidate_range_start() -> tdp_mmu_zap_leafs(), which is expensive, so unmapping a large batch keeps the CPU busy for a long time. The loop already calls cond_resched(), but on PREEMPTION kernels that is a no-op, and involuntary preemption is not a Tasks-RCU quiescent state. A long batch therefore never reports a quiescent state, and the migrating task (e.g. kcompactd) becomes a Tasks-RCU holdout, stalling the Tasks-RCU grace period for minutes, which is common at Meta fleet: INFO: rcu_tasks detected stalls on tasks: 0000000055349ecc: .. nvcsw: 1157401/1157401 holdout: 1 idle_cpu: -1/56 task:kcompactd0 state:R running task Call Trace: tdp_mmu_zap_leafs tdp_mmu_next_root gfn_to_pfn_cache_invalidate_start kvm_mmu_notifier_invalidate_range_start __mmu_notifier_invalidate_range_start try_to_migrate_one try_to_migrate migrate_pages_batch migrate_pages compact_zone compact_node kcompactd kthread Use cond_resched_tasks_rcu_qs() so a quiescent state is reported even when cond_resched() does nothing. This has also been discussed at [1] | 19 Oct |
| CVE-2026-89753 | unscored | 0.00% | no CPE yet | In the Linux kernel, the following vulnerability has been resolved: mm/vmscan: report RCU-tasks quiescent states in shrink_lruvec() I am seeing some rcu_tasks stalls in the Meta fleet during reclaim. INFO: rcu_tasks detected stalls on tasks: 0000000088620d09: .. nvcsw: 6735/6735 holdout: 1 idle_cpu: -1/8 task:GlobalCPUThread state:R running task pid:2552016 tgid:2524552 Call Trace: shrink_lruvec mem_cgroup_iter shrink_node do_try_to_free_pages try_to_free_pages __alloc_frozen_pages_noprof alloc_pages_noprof pte_alloc_one __pte_alloc handle_mm_fault Nothing promises direct reclaim returns in bounded time, and the scan loop in shrink_lruvec() only calls cond_resched(), which is a no-op on PREEMPTION kernels. Involuntary preemption is not a Tasks-RCU quiescent state, so the reclaiming task never reports one and becomes a holdout. Upgrade it to cond_resched_tasks_rcu_qs(), which reports a quiescent state even when cond_resched() does nothing. PS: This has been discussed in [1] | 19 Oct |
46 of 46
Download these 46 as CSV · subscribe to this list.
EPSS scores: 2026-10-28. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.