CVE-2026-46388 Overview
CVE-2026-46388 affects osquery, a SQL-powered operating system instrumentation, monitoring, and analytics framework. The vulnerability allows an unprivileged local attacker to read the contents of an in-progress osquery file carve before the temporary files are deleted. The root cause is that in-progress carve directories are not created with private permissions, exposing sensitive data during the carving process. If the carve targets a directory that the attacker controls, arbitrary file reads become possible. The issue is tracked under [CWE-279: Incorrect Execution-Assigned Permissions] and is fixed in osquery version 5.23.1.
Critical Impact
A local unprivileged attacker can read the contents of file carves executed by osquery, potentially exposing sensitive local files collected by security monitoring workflows.
Affected Products
- osquery versions prior to 5.23.1
- Deployments using the file carving feature on multi-user systems
- Any host where an unprivileged local user shares the filesystem with an osquery agent
Discovery Timeline
- 2026-07-10 - CVE-2026-46388 published to NVD
- 2026-07-10 - Last updated in NVD database
Technical Details for CVE-2026-46388
Vulnerability Analysis
osquery's file carve feature copies target files into a temporary staging directory before packaging them for exfiltration to the collection endpoint. Prior to version 5.23.1, this staging directory was created using fs::create_directory, which relies on the default umask and does not enforce owner-only permissions. As a result, the directory could be briefly world-readable, exposing carved file contents to any local user on the host while the carve was in progress.
Because osquery frequently runs as a privileged service and carves may target sensitive administrator-controlled paths, an unprivileged attacker who reads from the staging directory can obtain data they would not otherwise be permitted to access. The attack window closes only when the carve completes and the temporary files are deleted.
Root Cause
The root cause is a permissions-assignment flaw in osquery/carver/carver.cpp. The carve directory was created without explicit mode restrictions, allowing group and other read access based on the process umask. Combined with predictable paths derived from kCarvePathPrefix and a carve GUID, a local attacker could enumerate and read staged files.
Attack Vector
Exploitation requires local access with an unprivileged account and some user interaction or timing to align with an active carve. If the attacker can influence the target path of a carve, for example by staging a symbolic link or controlling a directory that gets carved, they can read the carved file contents from the staging location before cleanup. Confidentiality impact is high while integrity and availability are unaffected.
// Security patch in osquery/carver/carver.cpp
// Ensure in-progress file carves are readable only by the user running osquery
// TODO: Adding in a manifest file of all carved files might be nice.
carveDir_ =
fs::temp_directory_path() / fs::path(kCarvePathPrefix + carveGuid_);
- auto ret = fs::create_directory(carveDir_);
- if (!ret) {
- return Status::failure("Failed to create carve file store");
+ auto s = platformCreatePrivateDir(carveDir_);
+ if (!s.ok()) {
+ return s;
}
// Store the path to our archive for later exfiltration
Source: osquery commit 6dabe9d
The patch introduces a new helper platformCreatePrivateDir that creates the directory atomically with owner-only permissions (mode 0700 on POSIX, subject to umask), eliminating the race window where the directory is briefly world-readable or world-writable:
/**
* @brief Creates a directory with only owner-accessible permissions.
*
* Unlike creating a directory and then restricting it with platformChmod,
* this function ensures the directory is created without any group/other access
* (i.e., mode 0700 on POSIX, subject to umask), eliminating the race window
* where the directory is briefly world-readable or world-writable.
*
* @param path The path of the directory to create.
* @return Status indicating success or failure.
*/
Status platformCreatePrivateDir(const boost::filesystem::path& path);
Source: osquery commit 6dabe9d
Detection Methods for CVE-2026-46388
Indicators of Compromise
- Unexpected read access from unprivileged users to directories under the system temp path matching the osquery-carve-* naming pattern.
- Presence of long-lived carve staging directories that were not cleaned up after a carve completed.
- Local processes enumerating /tmp or the OS-equivalent temporary directory in tight loops while osquery carves are active.
Detection Strategies
- Audit filesystem permissions on any existing osquery carve staging directories to confirm mode 0700 after upgrading.
- Enable file access auditing (auditd on Linux, FIM on Windows) for the osquery temporary carve path to identify unauthorized reads.
- Correlate osquery carves table events with local user process activity to detect concurrent access during in-progress carves.
Monitoring Recommendations
- Track the installed osquery version across the fleet and alert on any host still running a version below 5.23.1.
- Monitor for unusual local access to files under the temp directory by accounts other than the osquery service user.
- Log all file carve operations centrally and review the source paths for carves targeting attacker-writable locations.
How to Mitigate CVE-2026-46388
Immediate Actions Required
- Upgrade all osquery agents to version 5.23.1 or later across every managed endpoint and server.
- If immediate patching is not feasible, disable the file carving feature by removing the carver_disable_function override or setting disable_carver=true in the osquery configuration.
- Restrict shell access on hosts running vulnerable osquery agents to limit local attacker opportunities.
Patch Information
The fix is available in the osquery 5.23.1 release. The relevant change is pull request #8961, which introduces platformCreatePrivateDir to create carve staging directories with owner-only permissions. Full details are documented in GitHub Security Advisory GHSA-fg78-9q98-62hh.
Workarounds
- Disable file carving in osquery configuration until agents can be upgraded to 5.23.1.
- Configure carves to target only paths owned by root or the osquery service user, avoiding attacker-writable directories.
- Tighten the system umask for the osquery service to 0077 so newly created directories inherit restrictive default permissions.
# Verify installed osquery version
osqueryi --version
# Disable carving as a temporary workaround in osquery.flags
echo "--disable_carver=true" >> /etc/osquery/osquery.flags
# Restart the osquery service to apply
systemctl restart osqueryd
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

