CVE-2026-49431: FreeBSD ZFS: unprivileged user can spoof recv metadata flag

AWAITING NVD
Published August 19, 2026
CISO Take

A local, unprivileged user on FreeBSD can abuse the ZFS_IOC_SET_PROP ioctl to falsely mark a ZFS dataset as having received data via zfs-recv, because the kernel fails to properly validate caller privileges (CWE-863). There is no CVSS score, no EPSS data, no public exploit, and it is not in CISA KEV, so this reads as a low-urgency, narrowly-scoped integrity bug rather than an actively exploited threat. It has no direct relevance to AI/ML frameworks, models, or inference pipelines — its relevance to this feed is indirect, limited to organizations that use ZFS-backed storage (e.g., FreeBSD/TrueNAS hosts) to store training datasets, model checkpoints, or MLOps artifacts, where dataset replication metadata could be manipulated by a local user with any shell access. Apply the FreeBSD Security Advisory FreeBSD-SA-26:40.zfs patch on affected hosts; no workaround beyond restricting local shell access to trusted users is described in the advisory.

Sources: NVD security.freebsd.org

What is the risk?

Low risk in isolation: exploitation requires local, authenticated access to a FreeBSD host running ZFS, there is no privilege escalation to root or code execution — only the ability to spoof an internal replication metadata flag ($hasrecvd) on a dataset. No CVSS/EPSS scoring is published, it's not KEV-listed, and no public exploit or scanner template exists. Impact scales only in environments where ZFS replication state is used as an integrity or trust signal (e.g., automated pipelines that gate actions on whether a dataset was legitimately received via zfs-recv).

How does the attack unfold?

Local Access
Attacker obtains unprivileged local shell access to a FreeBSD host running ZFS-backed dataset/model storage.
Metadata Spoofing
Attacker calls ZFS_IOC_SET_PROP directly to set the $hasrecvd flag on a dataset without proper privilege validation.
Integrity Impact
Downstream tooling that trusts replication metadata as a provenance signal may act on the falsified dataset state, undermining data lineage integrity.
AML.T0059

What systems are affected?

Package Ecosystem Vulnerable Range Patched
FreeBSD No patch

Do you use FreeBSD? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Trivial

What should I do?

1 step
  1. Apply the fix referenced in FreeBSD-SA-26:40.zfs (security.freebsd.org/advisories/FreeBSD-SA-26:40.zfs.asc) to patch ZFS_IOC_SET_PROP privilege validation. In the interim, restrict local shell/console access on ZFS hosts to trusted administrators only, and avoid relying on the $hasrecvd metadata flag as a security or provenance boundary for datasets shared with less-trusted local users. No detection signature is published; auditing zfs get/set property changes via system audit logs (if enabled) can help identify anomalous property manipulation.

How is it classified?

Auth Bypass Training Data

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2026-49431?

A local, unprivileged user on FreeBSD can abuse the ZFS_IOC_SET_PROP ioctl to falsely mark a ZFS dataset as having received data via zfs-recv, because the kernel fails to properly validate caller privileges (CWE-863). There is no CVSS score, no EPSS data, no public exploit, and it is not in CISA KEV, so this reads as a low-urgency, narrowly-scoped integrity bug rather than an actively exploited threat. It has no direct relevance to AI/ML frameworks, models, or inference pipelines — its relevance to this feed is indirect, limited to organizations that use ZFS-backed storage (e.g., FreeBSD/TrueNAS hosts) to store training datasets, model checkpoints, or MLOps artifacts, where dataset replication metadata could be manipulated by a local user with any shell access. Apply the FreeBSD Security Advisory FreeBSD-SA-26:40.zfs patch on affected hosts; no workaround beyond restricting local shell access to trusted users is described in the advisory.

Is CVE-2026-49431 actively exploited?

No confirmed active exploitation of CVE-2026-49431 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-49431?

Apply the fix referenced in FreeBSD-SA-26:40.zfs (security.freebsd.org/advisories/FreeBSD-SA-26:40.zfs.asc) to patch ZFS_IOC_SET_PROP privilege validation. In the interim, restrict local shell/console access on ZFS hosts to trusted administrators only, and avoid relying on the $hasrecvd metadata flag as a security or provenance boundary for datasets shared with less-trusted local users. No detection signature is published; auditing zfs get/set property changes via system audit logs (if enabled) can help identify anomalous property manipulation.

What systems are affected by CVE-2026-49431?

This vulnerability affects the following AI/ML architecture patterns: training pipelines.

What is the CVSS score for CVE-2026-49431?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

training pipelines

What are the technical details?

Original Advisory

The ZFS_IOC_SET_PROP ioctl, used by zfs-set(8), incorrectly validated the calling user such that an unprivileged user is able to set metadata on a dataset indicating that the dataset has received properties from a zfs-recv(8) stream. Any local user can set the internal ZFS metadata flag "$hasrecvd" on datasets via ZFS_IOC_SET_PROP.

Exploitation Scenario

An attacker who has obtained low-privilege local shell access to a FreeBSD host used as a dataset/model artifact store (e.g., a shared ML data server) invokes the ZFS_IOC_SET_PROP ioctl directly to set the $hasrecvd flag on a dataset they don't administratively own. If any internal tooling or pipeline logic trusts that flag to infer the dataset was legitimately replicated from a trusted source, the attacker could use this to bypass property-change restrictions normally reserved for zfs-recv streams, subtly undermining trust in dataset lineage without needing root or triggering any AI-specific attack path.

Weaknesses (CWE)

CWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.

  • [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
  • [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].

Source: MITRE CWE corpus.

Timeline

Published
August 19, 2026
Last Modified
August 19, 2026
First Seen
August 19, 2026

Related Vulnerabilities