Cloud-hosted desktop environments have become a foundational component of modern enterprise infrastructure. Organizations increasingly rely on managed virtual desktop platforms to deliver secure, scalable, and centrally governed workstations to remote and hybrid employees. Among these solutions, Amazon WorkSpaces provides fully managed Windows desktop environments integrated with enterprise identity providers such as Active Directory and Microsoft Entra ID. These environments are generally designed to enforce the same security boundaries found in traditional corporate endpoints, where users operate with standard privileges while critical system components run under highly privileged service accounts.
A recently disclosed vulnerability, tracked as CVE-2026-7791, demonstrates how seemingly routine operational functionality can become a pathway to privilege escalation when trust assumptions around filesystem operations are not properly validated. The issue affects the Amazon Skylight Workspace Config Service, a component responsible for configuration management, health monitoring, and operational maintenance within Amazon WorkSpaces. By abusing weaknesses in the service’s log rotation mechanism, a low-privileged authenticated user can potentially obtain a powerful SYSTEM-level file write primitive and leverage it to achieve local privilege escalation.
Understanding the Amazon Skylight Workspace Config Service
The Amazon Skylight Workspace Config Service operates as a background Windows service running under the highly privileged NT AUTHORITY\SYSTEM account. Its responsibilities include maintaining configuration consistency, collecting operational telemetry, monitoring service health, and facilitating component updates. Because these activities require broad access across the operating system, the service executes with the highest local privileges available on Windows. As part of its operational workflow, the service exposes a log pull API endpoint that is periodically queried by the AWS management plane. Approximately every twenty minutes, the management infrastructure initiates a log collection process that triggers a sequence of file-management operations. During this process, log files are moved between multiple directories before being transmitted to AWS for analysis and support purposes.
While the mechanism appears straightforward, the security implications are significant because every filesystem operation involved in the workflow executes within the SYSTEM security context. Any weakness in how paths, directories, junctions, or files are validated can therefore create opportunities for privilege escalation. The vulnerability emerges precisely because the service places excessive trust in directory structures located under C:\ProgramData\Amazon\Skylight Metrics Agent, without adequately verifying ownership, integrity, or destination validity.
How the Skylight Log Rotation Architecture Works
The Skylight logging workflow follows a structured three-stage lifecycle designed to archive and transmit operational logs. Files initially reside in a primary working directory commonly referred to as the Current location. During the log pull process, files are first moved into a ROTATE directory where they are archived. Subsequently, those archived files are transferred into a TRANSMITTED directory where they receive a timestamp prefix before being forwarded to AWS management systems.
The workflow consists of six primary phases:
- The AWS management plane invokes the Skylight log pull API.
- The service verifies the existence of the Skylight Metrics Agent directory.
- The service initializes and accesses the Current, ROTATE, and TRANSMITTED folders.
- Files are moved from Current to ROTATE while preserving original filenames.
- Files are moved from ROTATE to TRANSMITTED while adding a timestamp prefix.
- The files are transmitted as part of the log collection process.
Under normal conditions, this workflow functions as intended. However, the service assumes that the directory hierarchy remains trustworthy throughout the operation. That assumption becomes dangerous when an attacker gains the ability to manipulate directory structures, especially through Windows junction points.
The Security Risks Introduced by Windows Junction Points
Windows junction points are a type of filesystem reparse point that allow one directory path to transparently redirect to another location. From the perspective of applications interacting with the filesystem, the redirected directory appears legitimate even though it actually points elsewhere. The critical security concern is that standard users can create junction points without requiring administrative privileges. If a privileged process performs file operations against an attacker-controlled junction, the resulting writes may occur in unintended locations. This behavior has historically been responsible for numerous privilege escalation vulnerabilities across Windows software ecosystems. In the case of CVE-2026-7791, the Skylight service does not verify whether directories involved in log rotation are legitimate directories or attacker-controlled junctions. As a result, a low-privileged user can redirect SYSTEM-level file operations into sensitive locations throughout the operating system, effectively transforming a routine maintenance function into an arbitrary file write primitive.
Technical Analysis of the Core Weaknesses
1. Missing Directory Ownership Validation
One of the most significant design flaws is the service’s failure to validate directory ownership and origin before interacting with critical paths. The service automatically creates required directories if they do not exist and subsequently trusts those locations without verifying whether they were established by trusted service components. This behavior creates an opportunity for attackers to pre-create or manipulate the directory structure before the service accesses it. Since the service later operates on these paths with SYSTEM privileges, the trust boundary between user-controlled and service-controlled resources effectively disappears.
2. Absence of Junction Point Detection
The Skylight service performs no meaningful validation to determine whether directories are junction points or other reparse objects. Before executing sensitive file operations, privileged services should explicitly verify that destination paths resolve to expected physical directories and are not attacker-controlled redirections. Because such validation is absent, the service follows junction points transparently and unknowingly writes files to locations selected by the attacker. This behavior forms the foundation of the arbitrary file write capability.
3. Unrestricted File Processing
The service archives and moves files regardless of their type or extension. During enumeration of the Current directory, every file is considered eligible for processing. No validation is performed to ensure that files are genuine log artifacts. This lack of filtering allows attackers to introduce arbitrary payloads such as DLL files into the workflow. Once processed by the service, these payloads can be written into locations where privileged applications may later load or execute them.
4. SYSTEM-Level Execution Context
Every file operation involved in the vulnerability executes under the SYSTEM account. While the filesystem interactions themselves may appear routine, the security impact becomes severe because any successful redirection inherits SYSTEM privileges. Consequently, a low-privileged domain user can indirectly perform actions that would normally require administrative access, dramatically increasing the exploitation potential of the vulnerability.
5. Race Condition Exposure
A small but exploitable timing window exists between the archival and transmission phases of the log rotation workflow. Researchers identified an approximate 1–10 millisecond gap between file movement and subsequent enumeration operations. An attacker who successfully wins this race condition can prevent the service from applying the timestamp prefix normally added during transmission. This capability enables placement of files using their original names, a crucial requirement for many DLL hijacking and service-loading scenarios.
Exploitation Path and Attack Chain
The proof-of-concept exploit demonstrates how multiple weaknesses can be chained together to achieve privilege escalation. The attack begins by creating the Skylight Metrics Agent directory structure and replacing the ROTATE directory with a junction point that redirects file operations to a target location selected by the attacker. Next, the attacker places a malicious payload, such as a DLL file, within the Current directory. When the Skylight service performs its scheduled log rotation operation, it unknowingly moves the payload through the attacker-controlled junction. Because the operation executes under SYSTEM privileges, the file is written into the target directory with elevated trust. The exploit then attempts to win the identified race condition to preserve the original filename. Once the payload has been planted in a location consumed by a privileged process, the attacker can restart or trigger the associated service and execute code with elevated privileges. This transforms the arbitrary file write primitive into full local privilege escalation.
Business and Security Impact
The implications of CVE-2026-7791 extend beyond a simple local privilege escalation flaw. In enterprise environments, virtual desktops often provide access to sensitive corporate resources, cloud identities, internal applications, and confidential business data. Successful exploitation could allow an authenticated WorkSpaces user to elevate privileges from a standard domain account to SYSTEM, effectively gaining complete control over the affected virtual desktop. Such access may enable credential theft, security control bypass, persistence establishment, lateral movement preparation, and broader compromise of enterprise assets. Because WorkSpaces frequently serve as endpoints for remote employees, contractors, and third-party users, vulnerabilities of this nature represent a significant risk to organizational security programs and cloud desktop deployments.
Remediation and AWS Response
AWS has addressed the vulnerability through updates to the Skylight service. The issue is reported as fully remediated in Amazon WorkSpaces Skylight version 2.6.2034.0. Organizations using Amazon WorkSpaces should verify that all deployed instances have received the updated version and that no legacy images continue to run vulnerable releases.
Beyond patch deployment, organizations should perform retrospective threat hunting activities. Security teams should review historical telemetry for evidence of junction point creation within Skylight directories, unusual file writes into privileged system locations, suspicious DLL placement events, and unexpected modifications affecting services, scheduled tasks, startup folders, or application directories.
Security validation exercises should also be conducted to ensure that endpoint detection and response platforms, SIEM correlation rules, and incident response playbooks are capable of detecting filesystem redirection attacks and privilege escalation techniques involving privileged services.
