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

Content

View full analysis

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

View remediation

T05 · Unauthorized Access and Privilege Escalation

Error

• Location: references/phoenix-conventions.md:60

Finding

Unscoped Resource Lookups Permit Cross-Tenant Read, Update, and Deletion

Content

View full analysis

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

View remediation

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
• 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).

Content

Scanner excerpt · references/test-patterns.md (reported line 176)May include surrounding context.

md

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)

Vague Triggers

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

External Transmission

Medium

• Category: Data Exfiltration
• Confidence: 50% confidence

Finding

Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Content

Scanner excerpt · references/test-patterns.md (reported line 201)May include surrounding context.

md

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

Natural-Language Policy Violations

Low

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.