T03 · Remote Payload Retrieval and Execution
- Location
references/flyio_config.md:20- Finding
Unverified Remote Installer Is Piped Directly into a Shell
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill is a coherent quantum-app starter kit, but it asks users to deploy public cloud services and handle secrets with unsafe defaults that need careful review.
Review and harden this before installation or use: avoid real PHI/PII, do not use the one-command deploy path for production, do not put API keys in VITE_* frontend variables, inspect any Fly.io installer before running it, replace placeholder dependency guidance with verified pinned packages, and manually review exactly which secrets are uploaded to Fly.io.
references/flyio_config.md:20Unverified Remote Installer Is Piped Directly into a Shell
scripts/flyio_deploy.py:27Fly.io Secrets Are Exposed in Plaintext Command Logs and Process Arguments
assets/selene-template/main.py:128Public Quantum API Is Deployed Without Authentication, Authorization, or Enforced Rate Limits
assets/lovable-template/src/lib/api.ts:3Frontend API Key Is Embedded in Public Vite Assets
scripts/lovable_integrate.py:89Untrusted CLI Values Are Interpolated Directly into Generated Executable Source
Quantum {quantum_use_case} powered by Guppy/Selene
``` The interpolated files are written without validation or context-specific escaping: ```python (project_dir / "vite.config.ts").write_text(VITE_CONFIG.format(backend_url=backend_url)) print(" ✓ Created vite.config.ts") (project_dir / "index.html").write_text( INDEX_HTML.format(app_name=app_name, quantum_use_case=quantum_use_case) ) print(" ✓ Created index.html") (src_dir / "App.tsx").write_text( APP_TSX.format( app_name=app_name, quantum_use_case=quantum_use_case, backend_url=backend_url ) ) ``` The values originate directly from CLI argu ...[truncated 1985 chars]SKILL.md:140Instructions Recommend Installing an Ambiguous Unpinned Guppy Package
The declared description promises a specialized skill for building and deploying quantum computing applications, including healthcare-oriented use cases and cloud/deployment integrations. The actual code chunk does not implement any of that functionality. It only configures a local Vite development server for a React app and proxies API calls to a localhost backend. This is a materially different primary purpose from the declared description, so it is a clear mismatch.
The declared description is broader and more operational than the code. This script only scaffolds frontend files for a React/Vite app and configures them to call a presumed backend URL. It does not deploy anything, provision infrastructure, communicate with Fly.io, invoke quantum services, or implement healthcare-specific features. While it is related to integrating quantum results into a user-facing interface, the primary behavior is much narrower than the declared purpose, so this is a meaningful description-behavior mismatch.
Referenced artifact was not completely inspected
python3 scripts/lovable_integrate.py \
Referenced artifact was not completely inspected
python3 scripts/lovable_integrate.py \
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
cp .env.example .env
# Edit .env to set QUANTUM_HARDWARE if using real hardware
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Configure environment:
cp .env.example .env
# Edit .env to set QUANTUM_HARDWARE if using real hardware
Customize the quantum algorithm:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Configure environment:
cp .env.example .env
# Edit .env to set QUANTUM_HARDWARE if using real hardware
Customize the quantum algorithm:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Configure environment:
cp .env.example .env
# Edit .env to set QUANTUM_HARDWARE if using real hardware
Customize the quantum algorithm:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
2. **Configure environment:**
```bash
cp .env.example .env
# Edit .env to set QUANTUM_HARDWARE if using real hardware
```
3. **Customize the quantum algorithm:**
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
2. **Configure environment:**
```bash
cp .env.example .env
# Edit .env to set QUANTUM_HARDWARE if using real hardware
```
3. **Customize the quantum algorithm:**
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
2. **Configure environment:**
```bash
cp .env.example .env
# Edit .env to set QUANTUM_HARDWARE if using real hardware
```
3. **Customize the quantum algorithm:**
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
2. **Configure environment:**
```bash
cp .env.example .env
# Edit .env to set QUANTUM_HARDWARE if using real hardware
```
3. **Customize the quantum algorithm:**
This pattern attempts to override system instructions or ignore safety constraints. Without LLM analysis, manual review is recommended.
| `PORT` | Service port (Fly.io sets this) | No (default: 8080) |
| `QUANTUM_HARDWARE` | Hardware target: h2, h1, emulator | No |
| `QUANTUM_API_KEY` | Quantinuum API key for real hardware | Only for real hardware |
| `DEBUG` | Enable debug mode | No (default: false) |
### fly.toml Configuration
The file pins FastAPI to version 0.104.1, and the static analysis reports a known high-severity advisory (CVE-2024-24762) affecting that version. Because this template is for building deployable web APIs, shipping a vulnerable framework version can expose downstream applications to exploitable request-handling or API-layer weaknesses in real deployments.
Package name closely resembles a popular package, suggesting possible typosquatting. Attackers publish malicious packages with similar names to trick developers into installing them.
Piping a remote script directly into the shell executes code fetched over the network without integrity verification, pinning, or prior review. If the remote endpoint, transport, or upstream script is compromised, users can suffer arbitrary code execution on their local machine or CI runner.
# 1. Install flyctl
curl -L https://fly.io/install.sh | sh
# 2. Login
fly auth login
Tool calls are chained to bypass individual safety checks or escalate capabilities beyond what any single tool call would allow.
# 1. Install flyctl
curl -L https://fly.io/install.sh | sh
# 2. Login
fly auth login
The script automatically reads a local .env-style file and prepares to push its contents into Fly.io secrets, which can transfer sensitive credentials to a remote platform with little operator scrutiny. In this healthcare/clinical deployment context, bulk-importing environment variables increases the chance of unintentionally exporting development, test, or regulated secrets to the wrong cloud app or tenant.
print(f"✅ App created")
def configure_secrets(app_name, env_file_path):
"""Set secrets on Fly.io from .env file"""
print(f"\n🔐 Configuring secrets for {app_name}")
if not env_file_path.exists():
The secret-loading workflow trusts any existing .env path and does not distinguish between safe local configuration and highly sensitive credentials that should never be propagated automatically. This can cause accidental credential exposure to cloud deployment targets, especially dangerous given the skill's focus on clinical and healthcare projects where credentials may guard protected data and regulated systems.
print(f"\n🔐 Configuring secrets for {app_name}")
if not env_file_path.exists():
print(f"⚠️ .env file not found at {env_file_path}. Skipping secrets.")
return
# Read .env file
This code reads every non-comment key/value pair from the .env file and uploads them, creating a mass-secret exfiltration path from local developer storage to remote Fly.io configuration. Because there is no filtering, classification, or review step, sensitive tokens unrelated to the deployed service could be uploaded inadvertently.
print(f"⚠️ .env file not found at {env_file_path}. Skipping secrets.")
return
# Read .env file
secrets = {}
for line in env_file_path.read_text().splitlines():
line = line.strip()
The script defaults to consuming .env from the service directory during deployment preparation, which makes secret export automatic rather than deliberate. In a healthcare-oriented skill, this increases the operational risk of pushing credentials tied to PHI-bearing systems or other regulated services into the wrong environment.
# Step 3: Configure secrets
if not args.skip_secrets:
env_file = service_dir / ".env"
if not env_file.exists():
env_file = service_dir / ".env.example"
print(f"⚠️ .env not found, using .env.example as reference")
Falling back to .env.example as a source for secret configuration is dangerous because example files are often committed, stale, shared, or attacker-modifiable; if populated with real-looking values, they may be uploaded to production or used to poison deployment configuration. This is particularly risky in an agent skill where repository content must be treated as untrusted and where cloud deployment actions have real external side effects.
env_file = service_dir / ".env"
if not env_file.exists():
env_file = service_dir / ".env.example"
print(f"⚠️ .env not found, using .env.example as reference")
configure_secrets(args.app_name, env_file)
# Step 4: Deploy (unless setup-only)
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
.gitignore_content = '''node_modules/
dist/
.env.local
.env.*.local
*.log
.DS_Store
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
print(f"\n✅ Selene service created at: {project_dir}")
print(f"\nNext steps:")
print(f"1. cd {project_dir}")
print(f"2. Install dependencies and configure .env")
print(f"3. Implement actual Guppy algorithm in main.py")
print(f"4. Test locally: python main.py")
print(f"5. Deploy: fly launch --now")
The README promotes one-command generation, deployment, and public frontend/backend wiring for clinical use cases without giving an immediate, prominent warning about sensitive health data, endpoint exposure, authentication, or data minimization in the same workflow section. In a healthcare-themed skill, this omission can lead users to rapidly deploy internet-accessible services that process clinical inputs before they have added auth, restricted CORS, or ensured de-identification, increasing the likelihood of data exposure or unsafe handling.
Detected: suspicious.exposed_secret_literal