Skip to content

An oversized execution argument list could overflow the telemetry log buffer

Critical
mlw published GHSA-xcpp-qvv3-r3xf Aug 4, 2026

Software

santa

Affected versions

<= 2026.6

Patched versions

2026.7

Description

Summary

Santa's file and JSON telemetry writers accumulate serialized events in a growable buffer. When an event did not fit, the buffer was grown to twice its current capacity, which is the right amount most of the time but not when the incoming event is itself larger than that. The subsequent copy then wrote past the end of the allocation.

The argument list of an executing process is attacker-controlled and is included in execution telemetry, so an unprivileged local user could produce an event large enough to trigger this by running a program with a sufficiently long argument list.

Growing a buffer by a fixed multiple is only correct if the multiple is checked against what is actually needed.

Impact

An unprivileged local user could cause a heap buffer overflow inside santad, which runs with root privileges as an Endpoint Security system extension. The size of the overwrite, and the data written, derive from input the user controls.

The demonstrated impact is memory corruption. That can destabilize the process responsible for enforcement, and enforcement is not reliable while its own memory is being corrupted.

Nobody has shown that the corruption can be driven further, into controlled execution inside the privileged extension. The severity below reflects the reasonable worst case for attacker-influenced memory corruption in a process running as root, which is the usual basis for scoring defects of this kind, rather than only what has been demonstrated.

Affected configurations

This affects the file and json values of EventLogType. Because file is the default, a deployment that has not set EventLogType at all is affected.

The syslog, null, and all protobuf values, including protobufstream, protobufstreamgzip, and protobufstreamzstd, are not affected.

What changes in 2026.7

Nothing observable. The buffer is grown to whichever is larger, twice its current capacity or the size actually required, so large events are written correctly instead of overflowing. There is no configuration change and no change to telemetry output.

The fix was contributed independently as #1070 and has been present in main since 15 July 2026. Deployments building from source after that commit already have it. No tagged release before 2026.7 contains it.

Affected versions

Field Value
Affected Santa <= 2026.6, when EventLogType is file or json
Fixed in Santa 2026.7, and in main since #1070
Severity Critical, CVSS v4.0 base score 9.3
CVSS CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
CWE CWE-122: Heap-based Buffer Overflow, CWE-131: Incorrect Calculation of Buffer Size

Mitigation

Upgrade to Santa 2026.7 or later, or build from main at or after #1070.

Deployments that cannot do either can avoid the affected code by setting EventLogType to any value other than file or json. The protobuf variants are the closest equivalent for structured telemetry. Treat this as a way to close the exposure rather than as a preference, since it changes the format your telemetry pipeline receives.

Credit

Reported by OpenAI Codex Security, Jamie Brim (@jamieb-oai).

The underlying defect was independently found and fixed by @tnek in #1070, which landed before the report arrived.

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Local
Attack Complexity Low
Attack Requirements None
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability High
Subsequent System Impact Metrics
Confidentiality High
Integrity High
Availability High

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

CVE ID

No known CVE

Weaknesses

Heap-based Buffer Overflow

A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc(). Learn more on MITRE.

Incorrect Calculation of Buffer Size

The product does not correctly calculate the size to be used when allocating a buffer, which could lead to a buffer overflow. Learn more on MITRE.

Credits