GHSA-m4x6-gwgp-4pm7 is a critical-severity (CVSS 9) Code Injection vulnerability in @aws/agentcore. O3 Security confirms whether GHSA-m4x6-gwgp-4pm7 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
AgentCore CLI Bedrock Agent Import Vulnerable to Code Injection via Improper Triple-Quote Escaping
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-m4x6-gwgp-4pm7.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-m4x6-gwgp-4pm7 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 365,017 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
@aws/agentcorenpmDescription
Summary
The AgentCore CLI (@aws/agentcore) is a developer tool for managing agent infrastructure lifecycle on Amazon Bedrock AgentCore. An issue exists where, under certain circumstances, a crafted collaborationInstruction value stored in Bedrock Agent collaborator metadata can break out of a Python triple-quoted string in code generated by the agentcore add agent --type import command, resulting in arbitrary code execution when the generated file is loaded or deployed.
Impact
When a user runs agentcore add agent --type import to import a Bedrock supervisor agent that has multi-agent collaboration enabled, the CLI fetches collaborator metadata from the Bedrock API and interpolates the collaborationInstruction field directly into a triple-quoted Python string in the generated main.py file of the imported agent. Due to insufficient escaping, a collaborationInstruction value containing triple double-quote characters can terminate the string boundary and inject arbitrary Python statements into the generated source file.
An authenticated AWS user in the same account with the bedrock:AssociateAgentCollaborator IAM permission can associate a collaborator agent carrying a crafted collaborationInstruction with a supervisor agent. A developer who subsequently imports that supervisor agent using an affected CLI version will have the injected code written to their local main.py of the imported agent. The injected code executes in two contexts: on the developer's local machine when running agentcore dev, under the developer's local AWS credentials; and in the AWS AgentCore Runtime environment when the developer runs agentcore deploy followed by agentcore invoke, under the agent's IAM execution role.
Customers who have already imported a supervisor agent using an affected version and deployed it to AWS remain exposed on every agent invocation until they regenerate and redeploy the agent using a patched CLI version.
Impacted versions: @aws/agentcore >= 0.4.0 AND <= 0.14.1, preview >= 0.3.0-preview.7.0 AND <= 1.0.0-preview.8
Patches
This issue has been addressed in AgentCore CLI version 0.14.2 and preview version 1.0.0-preview.9. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Customers who have previously run agentcore add agent --type import on an affected version must also remove the affected agent from their project, re-run the import with the patched CLI to regenerate a clean main.py for the imported agent, and redeploy their agent to AWS to replace the previously deployed artifact. Upgrading the CLI alone does not remediate already-generated or already-deployed code.
Workarounds
If an immediate upgrade is not possible, customers can manually inspect the generated main.py of the imported agent for any collaboratorInstruction values that contain triple double-quote character sequences and replace each occurrence with escaped equivalents before running agentcore dev or agentcore deploy.
References
If you have any questions or comments about this advisory, AWS asks that you contact AWS Security via the vulnerability reporting page or directly via email to [email protected]. Please do not create a public GitHub issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @aws/agentcore | ≥ 0.4.0&&< 0.14.2 | 0.14.2 |
| 📦npm | @aws/agentcore | ≥ 0.3.0-preview.7.0 | No fix |
| 📦npm | @aws/agentcore | ≥ 1.0.0-preview.1&&< 1.0.0-preview.9 | 1.0.0-preview.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @aws/agentcore. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @aws/agentcore to 0.14.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m4x6-gwgp-4pm7 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-m4x6-gwgp-4pm7 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-m4x6-gwgp-4pm7. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-m4x6-gwgp-4pm7 in your dependencies?
O3 detects GHSA-m4x6-gwgp-4pm7 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.