Skip to content

Security: AskElira/AskElira3

Security

SECURITY.md

Security Policy

Supported Versions

Version Supported
3.x Yes
< 3.0 No

Reporting a Vulnerability

Do not open a public GitHub issue for security vulnerabilities.

Report security issues by emailing the maintainers directly. Include:

  • A description of the vulnerability
  • Steps to reproduce
  • Potential impact
  • Any suggested fixes (optional)

You will receive a response within 72 hours. If the issue is confirmed, a fix will be released as soon as possible, typically within 7 days for critical issues.

Known Security Limitations

AskElira 3 is designed to run locally on your machine. The following behaviors are intentional but worth understanding:

Shell Command Execution

David (the build agent) generates code and the executor runs install commands (npm install, pip3 install, etc.) directly on your machine. Commands are restricted to an allowlist (npm, npx, pip3, pip, node, python3, python, which, ls) and use execFile (no shell spawning), but be aware that generated package installs can introduce third-party code.

Recommendation: Review generated package.json / requirements.txt before running goals that install dependencies.

No Auth by Default

The /api/* routes are open with no authentication when API_TOKEN is not set in .env. This is intentional for local-only use. If you expose port 3000 to a network, always set API_TOKEN in your .env.

LLM Output Execution

Workspace code generated by David is written to workspaces/[goal-id]/ and is not auto-executed. You review and run it yourself. The exception is shell commands in the executor (see above).

Workspace Isolation

All generated files are sandboxed to workspaces/[goal-id]/ using path validation. Files cannot escape this directory via path traversal.

Security Features

  • Path traversal protection on all workspace file operations
  • execFile (not exec) for all shell commands — no shell injection
  • SQL column whitelist prevents SQL injection via dynamic field names
  • Bearer token auth for all API routes (when API_TOKEN is configured)
  • LLM prompt injection mitigation via <user_input> XML wrapping
  • Input truncation and control character stripping before LLM calls

There aren’t any published security advisories