Aws Emr Skill

• Outcome: Review
• Latest audit: Sep 12, 2026 · 5:43 AM UTC
• Version: 2.0.0

Overview

The skill is a disclosed AWS EMR management tool, but it needs review because it can make impactful AWS changes and one result-retrieval path can return data from the wrong job.

Install only with least-privilege AWS credentials, preferably in a non-production account first. Require explicit confirmation before job submission, cancellation, cluster termination, or virtual-cluster deletion. Avoid using get_job_result with shared S3 result prefixes until the package binds results to exact job IDs, and pin installer/dependency versions instead of using latest.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/on_serverless/jobs.py:477

Finding

Cross-job disclosure caused by unbound S3 result lookup

Content

View full analysis

latest_modified ): latest_modified = modified result_key = key if not result_key: return { "error": "No result file found in S3 for this job run.", "job_run_id": job_run_id, } # Read the result JSON. obj_response = self._s3_client.get_object(Bucket=bucket, Key=result_key) raw_text = obj_response["Body"].read().decode("utf-8").strip() return json.loads(raw_text) ``` ### Technical Analysis The method accepts a `job_run_id` and verifies that the corresponding EMR job completed successfully, but it does not bind that identifier to the S3 object subsequently returned. Instead, it lists a shared `skill-results/` prefix and selects the most recently modified object whose key ends in `/ ...[truncated 1989 chars]

Remediation

View remediation

T08 · Insecure Dependencies

Note

• Location: README_EN.md:85

Finding

Installation instructions execute unpinned third-party dependencies

Content

View full analysis

=1.26.0" ``` Equivalent unpinned dependency guidance also appears in `SKILL.md:68` and `README.md`. ### Technical Analysis The documented installation process resolves executable npm packages dynamically. In particular, `npx clawhub@latest` explicitly selects a moving release, while `npx skills` does not specify an immutable reviewed version. The boto3 requirement specifies only a lower bound and does not use a lockfile or package hash. These commands are not evidence that the current dependencies are malicious. The risk is that the effective installation payload can change after this Skill has been audited. If a package publisher, registry account, release process, or dependency is compromised, following the documented command may execute or install code different from the reviewed version. Because `npx` can download and run package entry points, compromise may result in code execution under the account performing installation. An unbounded Python dependency can also introduce future incompatibility or a compromised transitive dependency. ### Attack Path 1. An attacker compromises a referenced npm publisher, package release process, registry account, or transitive dependency. 2. The attacker publishes a malicious version that satisfies the unpinned command, or replaces what the moving `@latest` tag resolves to. 3. A user follows the project’ ...[truncated 1132 chars]

Remediation

View remediation

add yhyyz/aws-emr-skills npx clawhub@ install aws-emr-skills ``` 2. Where supported, install the Skill from an immutable Git commit or a signed release tag rather than a mutable repository reference. 3. Pin Python dependencies to tested versions in a requirements or lock file: ```text boto3== botocore== ``` 4. Use hash-verified Python installation: ```bash pip install --require-hashes -r requirements.txt ``` 5. Commit lockfiles and update them through a controlled dependency-review process. 6. Verify package publisher identities, release signatures, provenance attestations, and registry integrity before recommending installation commands. 7. Run installer tooling in a restricted environment without unnecessary AWS credentials or access to sensitive agent configuration. 8. Document the exact dependency versions covered by each security review and automate alerts for changes to the resolved dependency graph. ]]>

SkillSpector

Vulnerability Patterns

• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (50)

Credential Access

High

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · README.md (reported line 134)May include surrounding context.

md

## Configuration

All environment variables are optional. AWS credentials are resolved via the boto3 default credential chain (env vars → `~/.aws/config` → IAM Role).

| Variable | Description | Default |
|----------|-------------|---------|

Credential Access

High

• Category: Privilege Escalation
• Confidence: 70% confidence

Finding

Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Content

Scanner excerpt · README_EN.md (reported line 134)May include surrounding context.

md

## Configuration

All environment variables are optional. AWS credentials are resolved via the boto3 default credential chain (env vars → `~/.aws/config` → IAM Role).

| Variable | Description | Default |
|----------|-------------|---------|

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence

Finding

The description claims a multi-mode EMR skill for managing jobs across EMR Serverless, EMR on EC2, and EMR on EKS. The supplied code chunk is much narrower: it manages only EMR on EC2 clusters, specifically list/describe/terminate cluster operations. There is no code for job submission, step management, status of jobs, log access, cancellation of jobs, serverless applications/job runs, or EKS virtual clusters. While cluster-related triggers partially fit, the declared primary purpose is materially broader than the implemented behavior in this chunk.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence

Finding

The code is clearly scoped to EMR on EC2, as shown by the module path (on_ec2), docstring, function names, and use of EMRClusterManager and EMRStepManager for EC2 clusters and steps. It supports cluster management, EC2 step submission for Spark/PySpark/Hive, step lifecycle operations, and fetching step logs. However, nothing in this chunk implements EMR Serverless application/job-run operations or EMR on EKS virtual cluster/job execution APIs. Therefore, the declared description materially overstates the implemented coverage and does not accurately represent this code chunk's behavior.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 92% confidence

Finding

The description claims a unified EMR skill for EMR Serverless, EMR on EC2, and EMR on EKS, but the supplied code chunk is specifically limited to EMR on EC2 step operations. It uses EMR APIs such as add_job_flow_steps, list_steps, describe_step, cancel_steps, and describe_cluster, which are specific to classic EMR clusters, not Serverless applications/job runs or EMR on EKS virtual clusters. The code does accurately cover parts of the declared purpose for EMR on EC2—submitting Spark, PySpark, and Hive jobs; checking status; canceling jobs; and getting logs—but it materially does not implement the other two declared deployment modes. Therefore the description overstates the actual behavior in a meaningful way.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 92% confidence

Finding

The code chunk is narrowly focused on EMR on EKS. It exposes operations for EKS virtual clusters, EKS job submission, job status/list/cancel, and log retrieval. This partially matches the declared description, but the declaration materially overstates scope by claiming management of EMR Serverless, EMR on EC2, and Hive/PySpark jobs across all three deployment modes. In this code, only EMR on EKS and Spark/Spark SQL behaviors are evident. Therefore the description does not accurately represent this supplied code chunk.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence

Finding

The code chunk is narrowly focused on EMR on EKS (EMR Containers). It uses an EMR Containers client to start, describe, list, and cancel job runs tied to a virtual cluster, and an S3 client to fetch compressed driver logs. Job submission supports Spark submit and Spark SQL only. There is no evidence here of EMR Serverless APIs, EMR on EC2 cluster/step management, or Hive job handling. Therefore the declared description overstates the implemented scope and capabilities, making it a material description/behavior mismatch.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 94% confidence

Finding

The declared description presents a broad EMR management skill spanning three deployment modes and job execution/monitoring workflows. The supplied code chunk is much narrower: it uses the EMR Containers client specifically for EMR on EKS virtual cluster CRUD-style operations. While virtual cluster management is mentioned in the description and is relevant to EMR on EKS, the primary represented capabilities in the description—submitting and managing data processing jobs across Serverless, EC2, and EKS—are not implemented here. This is a material description-behavior mismatch in scope and capability.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence

Finding

The declared description promises a comprehensive EMR management skill across three deployment modes with job execution and monitoring features. The supplied code chunk is materially narrower: it only accesses EMR Serverless application APIs (list/get/start/stop application). While this is related to EMR Serverless, it does not implement the central declared capabilities around job submission/management or support EMR on EC2 and EMR on EKS. This is a description-to-behavior mismatch due to overstated scope and missing core functionality.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 97% confidence

Finding

The description claims a broad EMR skill covering EMR Serverless, EMR on EC2, and EMR on EKS. However, the supplied code chunk is explicitly and exclusively an EMR Serverless CLI wrapper. Every tool delegates to EMRServerless-specific managers or application managers, and the exposed functions only operate on Serverless applications and Serverless job runs. There are no functions for EMR EC2 clusters, steps, or EMR on EKS virtual clusters. The mention of Spark, Hive, and PySpark job submission is accurate only within the EMR Serverless scope. Therefore the description materially overstates the supported deployment modes and related management capabilities.

Content

No source excerpt is available for this finding.

Tp4

High

• Category: MCP Tool Poisoning
• Confidence: 95% confidence

Finding

The description overstates the scope. The code exclusively uses EMR Serverless concepts and APIs: applicationId, start_job_run, get_job_run, cancel_job_run, list_job_runs, plus S3-based result/log retrieval under EMR Serverless log paths. There is no code for EMR on EC2 clusters, EMR steps, instance groups/fleets, or EMR Containers/EKS virtual clusters and job runs. The implemented Spark/Hive/PySpark submission and lifecycle features do align with part of the description, but only for the Serverless deployment mode. This is a material description-behavior mismatch because the declared primary capability spans three EMR deployment modes while the supplied code covers just one.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

High

• Category: Not specified by scanner
• Confidence: 99% confidence

Finding

get_job_result claims to return the result for a specific job_run_id, but it ignores that identifier when selecting the S3 object and instead returns the most recently modified part-00000 under a shared skill-results/ prefix. In a multi-user or multi-job environment, this can disclose another job's query output, causing cross-job data exposure and integrity confusion.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 88% confidence

Finding

The README highlights log retrieval and SQL result access but does not warn that these outputs may contain sensitive business data, identifiers, queries, or operational details. In a skill designed for AI agents, retrieved logs/results may be surfaced into chat history or downstream tooling, increasing exposure if users are not cautioned about privacy and data handling.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 82% confidence

Finding

The README highlights log retrieval and SQL result access but does not warn that these outputs may contain sensitive business data, identifiers, queries, or operational details. In a skill designed for AI agents, retrieved logs/results may be surfaced into chat history or downstream tooling, increasing exposure if users are not cautioned about privacy and data handling.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 87% confidence

Finding

The README instructs users to run npx skills add ... without pinning a specific package version. That causes the installer to fetch the latest published package at execution time, which increases supply-chain risk if the upstream package is compromised or a breaking/malicious version is published. In an agent-skill ecosystem, installation commands are likely to be copied verbatim, so this guidance materially affects user safety.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 87% confidence

Finding

This command again uses unpinned npx skills, which executes whatever version npm resolves at runtime. If the package or one of its dependencies is compromised, users following the README could execute attacker-controlled code during installation.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 87% confidence

Finding

The README provides another unpinned npx skills invocation for a different target agent. Repeating unsafe install guidance across multiple examples increases the chance that users execute an unreviewed latest package version.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 87% confidence

Finding

This installation command is subject to the same supply-chain exposure: npx will resolve and execute the current package version, not a reproducible one. Since the skill is meant for AI-agent environments, copy-paste execution is especially likely and makes the risk more practical.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 87% confidence

Finding

The --all variant still relies on an unpinned package and could have broader impact because it may install into multiple detected agent environments at once. If a malicious package version were served, compromise could propagate across several local tooling contexts.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 87% confidence

Finding

This line continues the pattern of unpinned npx skills execution, preserving the same supply-chain risk. Because the README is installation-focused, unsafe examples here directly influence user behavior and should be treated as a real documentation security issue.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 85% confidence

Finding

npx clawhub@latest install aws-emr-skills explicitly requests the latest version, which is non-reproducible and vulnerable to upstream compromise or malicious updates. Using latest is even riskier than an unqualified package because it clearly opts into whatever is current at execution time.

Content

No source excerpt is available for this finding.

Missing User Warnings

Medium

• Category: Not specified by scanner
• Confidence: 87% confidence

Finding

The README advertises management capabilities including cluster control, job submission, and log retrieval across AWS EMR modes without warning that these actions can incur cost, affect production workloads, or terminate resources. In an AI-agent context, describing destructive or costly operations as routine capabilities increases the chance that users trigger impactful actions through natural language without adequate confirmation.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 94% confidence

Finding

The README instructs users to execute npx skills add yhyyz/aws-emr-skills without pinning the package version. This can cause users to fetch and run whatever the registry serves at install time, increasing supply-chain risk if the package is updated maliciously, compromised, or if a breaking release introduces unsafe behavior.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 94% confidence

Finding

This installation example again uses unpinned npx skills, which executes code resolved at runtime from the package registry. In an AI-skill ecosystem where users are encouraged to run commands directly, this increases exposure to supply-chain compromise or unexpected behavior from future releases.

Content

No source excerpt is available for this finding.

Rp1

Medium

• Category: MCP Rug Pull
• Confidence: 94% confidence

Finding

The README recommends npx skills without a fixed version for another agent target. Because npx downloads and runs current package code, readers may unknowingly execute altered installer logic if the upstream package changes or is compromised.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.