HIGH 7.8

CVE-2026-12957: Language Servers for AWS Arbitrary Code Execution via Malicious Workspace

Language Servers for AWS versions before 1.65.0 contain a vulnerability that allows arbitrary code execution when a user opens a malicious workspace. The vulnerability stems from insufficient trust boundary enforcement—if a local user is tricked into trusting a workspace containing malicious commands in project configuration files, those commands will execute automatically. An attacker would need to craft a malicious workspace and convince a user to open and trust it, making this a local attack that relies on social engineering.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.8 HIGH · CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Weaknesses (CWE)
CWE-732
Affected products
0 configuration(s)
Published / Modified
2026-06-23 / 2026-06-23

NVD description (verbatim)

Improper trust boundary enforcement in Language Servers for AWS before version 1.65.0 on all supported platforms may allow a for arbitrary code execution. If a local user opens a maliciously crafted workspace, any commands within the project configuration files may be automatically executed. This issue requires the user to trust the workspace when prompted. To remediate this issue, users should upgrade to Language Servers for AWS version 1.65.0 or higher.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-12957 is an improper trust boundary enforcement flaw (CWE-732) in Language Servers for AWS affecting all supported platforms prior to version 1.65.0. The vulnerability allows arbitrary code execution through maliciously crafted workspace configurations. When a user opens a workspace and grants trust permission when prompted, any commands embedded in project configuration files execute with the privileges of that user. The attack vector is local, requires no special privileges to initiate, and has low attack complexity, but does require user interaction (trust confirmation).

Business impact

For organizations using Language Servers for AWS, this vulnerability poses a meaningful code execution risk in development environments. A compromised or malicious workspace could lead to lateral movement, credential theft, or supply chain contamination if development machines are connected to sensitive infrastructure. The impact is highest in environments where developers work with untrusted or community-sourced projects, or where workspace files are shared across teams without careful vetting.

Affected systems

Language Servers for AWS versions before 1.65.0 on all supported platforms are affected. Organizations should inventory deployments across development teams, CI/CD pipeline agents, and shared development environments. Verify the installed version and identify systems that have not yet been patched to 1.65.0 or later.

Exploitability

Exploitability is moderate but achievable in real-world scenarios. The attack requires user action—the victim must open a malicious workspace and explicitly grant trust when prompted. This is a realistic social engineering vector, particularly effective against developers working with new or community projects. No network attack is possible; this is strictly local. The CVSS 3.1 score of 7.8 (HIGH) reflects the high impact potential (full confidentiality, integrity, and availability compromise) balanced against the local and user-interaction requirements.

Remediation

Upgrade Language Servers for AWS to version 1.65.0 or higher. This patch addresses the trust boundary enforcement flaw. Additionally, reinforce developer training on workspace trust prompts—users should verify the source and contents of workspaces before granting trust, particularly for unfamiliar or externally-sourced projects.

Patch guidance

Apply Language Servers for AWS version 1.65.0 or later across all development environments and machines. Verify the update through the version check in your IDE or tooling. Given the user-interaction requirement, you may coordinate patching during regular maintenance windows, but prioritize machines that work with external or untrusted code repositories. Test the update in a non-critical environment first to ensure compatibility with existing workflows.

Detection guidance

Monitor for suspicious command execution originating from project configuration files (.aws, build configs, etc.) on developer machines. Review audit logs for unexpected process spawning following workspace trust confirmations. Endpoint Detection and Response (EDR) tools can flag execution chains initiated by configuration file parsing. Additionally, flag any instances where users are prompted to trust workspaces—while benign in normal operation, patterns of repeated trust prompts or prompts from unusual sources may indicate reconnaissance or phishing attempts.

Why prioritize this

Prioritize patching based on developer exposure. Teams working with untrusted, community-sourced, or externally-contributed code should be patched first. This includes open-source project contributors, security researchers, and development teams evaluating third-party libraries. While the user-interaction requirement limits immediate risk, the high-impact nature of arbitrary code execution in development environments and the realistic social engineering vector justify urgent remediation.

Risk score, explained

CVSS 3.1 score of 7.8 (HIGH) reflects: (1) High impact—full confidentiality, integrity, and availability compromise if code execution occurs; (2) Low attack complexity and no privilege requirement—execution is straightforward once the workspace is trusted; (3) Local attack vector and required user interaction—the attack is feasible but not autonomous. The score appropriately captures the severity for development environments without overstating the likelihood due to social engineering dependency.

Frequently asked questions

Do I need to manually trust the workspace every time I open it, or does the trust persist?

The vulnerability description indicates that users are prompted to trust the workspace, but does not specify persistence behavior. Verify with your specific Language Servers for AWS implementation and IDE integration. In either case, patching to version 1.65.0 mitigates the underlying flaw.

Can this vulnerability be exploited over the network or through cloud-hosted workspaces?

No. This is a local attack only—an attacker must place a malicious workspace on a victim's machine or convince the user to download and open one. Network-based or cloud-hosted workspaces are outside the attack scope unless they are cloned or downloaded to a local system.

Should we block trust prompts entirely, or educate developers on when to trust?

A hybrid approach is best: educate developers never to trust unknown or externally-sourced workspaces, and immediately patch to version 1.65.0 to remove the vulnerability. Blocking trust prompts entirely may interfere with legitimate workflow and team collaboration. Focus remediation on patching, supported by security awareness training.

What if we don't use workspace configuration files in our projects?

If your projects do not rely on automated configuration files or do not use features that auto-execute commands on workspace load, your exposure may be lower. However, you should still patch to version 1.65.0, as the vulnerability exists in the product and the trust boundary flaw could be exploited through unexpected configuration vectors.

This analysis is based on the vulnerability description and CVSS vector provided. Specific details about configuration file formats, workspace trust persistence, and platform-specific mitigations should be verified against the official Language Servers for AWS security advisory and release notes. No exploit code or weaponized proof-of-concept is included. Organizations should conduct internal testing before deploying patches in production environments. Source: NVD (public-domain), retrieved 2026-07-28. Analysis generated by SEC.co (claude-haiku-4-5).