CVE-2025-4318

GHSA-hf3j-86p7-mfw8 CRITICAL
Published July 30, 2026

### Summary The AWS Amplify Studio [amplify-codegen-ui](https://github.com/aws-amplify/amplify-codegen-ui) is a package that generates front-end code from UI Builder entities (components, forms, views, and themes) primarily used in AWS Amplify Studio for component previews and in AWS Command Line...

Full CISO analysis pending enrichment.

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Ray npm <= 2.20.2 2.20.3
43.4K OpenSSF 5.7 616 dependents Pushed 5d ago 81% patched ~112d to patch Full package profile →

Do you use Ray? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
1.0%
chance of exploitation in 30 days
Higher than 60% of all CVEs
Exploitation Status
No known exploitation
Sophistication
N/A

What should I do?

Patch available

Update Ray to version 2.20.3

Which compliance frameworks are affected?

Compliance analysis pending. Sign in for full compliance mapping when available.

Frequently Asked Questions

What is CVE-2025-4318?

### Summary The AWS Amplify Studio [amplify-codegen-ui](https://github.com/aws-amplify/amplify-codegen-ui) is a package that generates front-end code from UI Builder entities (components, forms, views, and themes) primarily used in AWS Amplify Studio for component previews and in AWS Command Line Interface (AWS CLI) for generating component files in customers' local applications. An issue exists in the Amplify Studio property binding process of the `amplify-codegen-ui `package that could potentially allow an authenticated user to run arbitrary JavaScript code during the component rendering and build process. ### Impact When importing a component schema using the [create-component](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/amplifyuibuilder/create-component.html) command, Amplify Studio will import and generate the component on the users' behalf. The expression-binding function does not validate the component schema properties before converting them to expressions. As a result, an authenticated user who can create or modify components could run arbitrary JavaScript code during the component rendering and build process. **Impacted versions: <=2.20.2** ### Patches This issue has been addressed partially in version [2.20.3](https://github.com/aws-amplify/amplify-codegen-ui/pull/1174) and additional fixes in [2.20.4](https://github.com/aws-amplify/amplify-codegen-ui/pull/1196). We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. ### Workarounds There are no workarounds. Upgrade to version [2.20.4](https://github.com/aws-amplify/amplify-codegen-ui/releases/tag/v2.20.4). If you have any questions or comments about this advisory, AWS asks that you contact AWS/Amazon Security via the [issue-reporting page](https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue. ### Credit AWS would like to thank `ray the bounty hunter` for collaborating on this issue through the coordinated issue disclosure process.

Is CVE-2025-4318 actively exploited?

No confirmed active exploitation of CVE-2025-4318 has been reported, but organizations should still patch proactively.

How to fix CVE-2025-4318?

Update to patched version: Ray 2.20.3.

What is the CVSS score for CVE-2025-4318?

No CVSS score has been assigned yet.

What are the technical details?

Original Advisory

### Summary The AWS Amplify Studio [amplify-codegen-ui](https://github.com/aws-amplify/amplify-codegen-ui) is a package that generates front-end code from UI Builder entities (components, forms, views, and themes) primarily used in AWS Amplify Studio for component previews and in AWS Command Line Interface (AWS CLI) for generating component files in customers' local applications. An issue exists in the Amplify Studio property binding process of the `amplify-codegen-ui `package that could potentially allow an authenticated user to run arbitrary JavaScript code during the component rendering and build process. ### Impact When importing a component schema using the [create-component](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/amplifyuibuilder/create-component.html) command, Amplify Studio will import and generate the component on the users' behalf. The expression-binding function does not validate the component schema properties before converting them to expressions. As a result, an authenticated user who can create or modify components could run arbitrary JavaScript code during the component rendering and build process. **Impacted versions: <=2.20.2** ### Patches This issue has been addressed partially in version [2.20.3](https://github.com/aws-amplify/amplify-codegen-ui/pull/1174) and additional fixes in [2.20.4](https://github.com/aws-amplify/amplify-codegen-ui/pull/1196). We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes. ### Workarounds There are no workarounds. Upgrade to version [2.20.4](https://github.com/aws-amplify/amplify-codegen-ui/releases/tag/v2.20.4). If you have any questions or comments about this advisory, AWS asks that you contact AWS/Amazon Security via the [issue-reporting page](https://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue. ### Credit AWS would like to thank `ray the bounty hunter` for collaborating on this issue through the coordinated issue disclosure process.

Weaknesses (CWE)

CWE-95 — Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection'): The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

  • [Architecture and Design, Implementation] If possible, refactor your code so that it does not need to use eval() at all.
  • [Implementation] Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylis

Source: MITRE CWE corpus.

Timeline

Published
July 30, 2026
Last Modified
July 30, 2026
First Seen
July 31, 2026

Related Vulnerabilities