Phoenix API Generator

• Outcome: Review
• Latest audit: Sep 10, 2026 · 8:53 AM UTC
• Version: 1.0.0

Overview

The skill is not executable malware, but its Phoenix API templates can generate unsafe multi-tenant authorization patterns that users should review before use.

Install only if you are comfortable reviewing the generated Phoenix security code. In particular, do not rely on the included tenant examples as-is: validate tenant selection against authenticated membership, scope every read/update/delete by the validated tenant, ignore client-supplied tenant_id on create, and add negative cross-tenant authorization tests before using generated code in a real app.

A.I.G

Vulnerability Patterns

• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: SKILL.md:64
• Finding: Caller-Controlled Tenant Header Enables Tenant Impersonation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:64-66` **Vulnerability Type**: Unvalidated tenant identity selection **Risk Level**: High ### Vulnerable Code ```elixir tenant_id = get_req_header(conn, "x-tenant-id") |> List.first() assign(conn, :tenant_id, tenant_id) ``` ### Technical Analysis The documented tenant plug treats the caller-controlled `x-tenant-id` header as an authoritative tenant identity. It does not verify that: - The requester is authenticated. - The selected tenant exists. - The authenticated account is a member of the selected tenant. - The account has permission to perform the requested operation in that tenant. Authentication and tenant authorization are therefore disconnected. Any generated endpoint that relies on `conn.assigns.tenant_id` for isolation may operate on an arbitrary tenant selected by the requester. The header can be retained as a tenant selector only if its value is validated against trusted authentication claims or a server-side membership lookup. It must not itself grant tenant access. ### Attack Path 1. An attacker authenticates using a legitimate account. 2. The attacker learns or guesses the identifier of another tenant. 3. The attacker sends a request with `x-tenant-id` set to that tenant's identifier. 4. `SetTenant` assigns the attacker-supplied value to `conn.assigns.tenant_id` without membership validation. 5. Tenant-filtered context operations use the forged assignment and execute against the victim tenant. 6. Depending on the endpoint, the attacker can enumerate, create, or otherwise manipulate victim-tenant resources. ### Impact Assessment An authenticated user may cross tenant boundaries and exercise the API privileges associated with endpoints rather than the privileges granted by actual tenant membership. The potential scope includes unauthorized disclosure and manipulation of all resources selected through the forged tenant assignment. The precise data affected depends on which g ...[truncated 53 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Derive the active tenant from verified token claims when possible. - If `x-tenant-id` is used as a selector, verify it against a server-side membership and authorization record before assigning it. - Reject missing, malformed, unknown, or unauthorized tenant identifiers with an appropriate `401` or `403` response. - Store the validated tenant or membership record in `conn.assigns`, not merely the untrusted identifier. - Ensure create operations overwrite any client-provided `tenant_id` with the server-validated tenant identifier. - Add tests proving that an authenticated member of tenant A cannot list, create, read, update, or delete resources in tenant B. - Centralize tenant authorization in a plug or policy layer so individual controllers cannot accidentally omit it. ]]>

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/phoenix-conventions.md:60
• Finding: Unscoped Resource Lookups Permit Cross-Tenant Read, Update, and Deletion<![CDATA[ ## Vulnerability Details **File Location**: `references/phoenix-conventions.md:60-62, 89-108` **Vulnerability Type**: Cross-tenant insecure direct object reference **Risk Level**: High ### Vulnerable Code The context exposes global lookups that do not include a tenant constraint: ```elixir def get_user!(id), do: Repo.get!(User, id) def get_user(id), do: Repo.get(User, id) ``` The controller uses the global lookup for individual-resource operations: ```elixir def show(conn, %{"id" => id}) do user = Accounts.get_user!(id) render(conn, :show, user: user) end def create(conn, %{"user" => params}) do with {:ok, user} <- Accounts.create_user(params) do conn |> put_status(:created) |> render(:show, user: user) end end def update(conn, %{"id" => id, "user" => params}) do user = Accounts.get_user!(id) with {:ok, user} <- Accounts.update_user(user, params) do render(conn, :show, user: user) end end def delete(conn, %{"id" => id}) do user = Accounts.get_user!(id) with {:ok, _} <- Accounts.delete_user(user) do send_resp(conn, :no_content, "") end end ``` ### Technical Analysis Although the documented list operation can apply a tenant filter, the `show`, `update`, and `delete` actions retrieve users globally by primary key. Possession of a resource UUID is consequently treated as sufficient authorization. UUIDs may reduce casual enumeration, but identifier secrecy is not an access-control mechanism. Identifiers can be exposed through logs, URLs, API responses, browser history, support records, analytics, or other application features. After retrieval, neither the controller nor the context compares the record's `tenant_id` with a validated tenant assignment or verifies the authenticated principal's authorization. The update and delete functions then operate directly on the globally retrieved schema. The generated tests in `references/test-patterns.md:107-157` exercise CRUD operations only within one tenant and contain ...[truncated 1199 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Replace global lookups with tenant-scoped context functions, for example: ```elixir def get_user!(tenant_id, id) do Repo.get_by!(User, id: id, tenant_id: tenant_id) end ``` - Pass only a server-validated tenant identifier or membership record into context functions. - Apply tenant constraints to every read, update, and delete query, not only list queries. - Prefer scoped atomic updates and deletes where appropriate so authorization cannot become stale between lookup and mutation. - Ensure create operations inject the validated tenant server-side and ignore or reject a client-supplied `tenant_id`. - Return `404` or `403` consistently for cross-tenant access without leaking whether a foreign resource exists. - Add negative controller and context tests that create records in two tenants and verify that a tenant-A principal cannot: - List tenant-B records. - Read a tenant-B record by UUID. - Update a tenant-B record. - Delete a tenant-B record. - Review all generated contexts for unscoped `Repo.get/2`, `Repo.get!/2`, update, and delete patterns. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• 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 (5)

Tool Parameter Abuse

High

• Category: Tool Misuse

Content

end
  end

  describe "DELETE /api/v1/users/:id" do
    test "204 deletes user", %{conn: conn, user: user} do
      conn = delete(conn, ~p"/api/v1/users/#{user.id}")
      assert response(conn, 204)

• Confidence: 80% confidence
• Finding: Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).

Vague Triggers

Medium

• Confidence: 89% confidence
• Finding: The manifest description says to use the skill for broad situations like "building a new Phoenix REST API," "adding CRUD endpoints," and especially "natural language description." These triggers are not expressed as a narrow invocation scope or explicit trigger list, so the skill could be selected for many ordinary coding requests involving Phoenix APIs.

Intent-Code Divergence

Medium

• Confidence: 97% confidence
• Finding: The controller example advertises authenticated and tenant-scoped API conventions, but the show, update, and delete actions load records with Accounts.get_user!(id) and never constrain the lookup by conn.assigns.tenant_id. In a multi-tenant Phoenix app, code generators and developers often copy reference patterns directly, so this example can propagate insecure direct object reference behavior that lets authenticated users access or modify another tenant’s records by guessing IDs.

External Transmission

Medium

• Category: Data Exfiltration

Content

test "calls external service" do
  expect(MyApp.HTTPClientMock, :post, fn url, body ->
    assert url == "https://api.example.com/webhook"
    {:ok, %{status: 200}}
  end)

• Confidence: 50% confidence
• Finding: Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Natural-Language Policy Violations

Low

• Confidence: 84% confidence
• Finding: The example hard-codes `default: "en"` for the `locale` field, which is a natural-language locale choice. Under the policy, forcing a specific language or locale without user opt-in can be a violation unless clearly justified or optional.

Static analysis

No suspicious patterns detected.