erlang-otp-behaviors

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 6:19 AM UTC
• Version: 0.1.0

Overview

This is a documentation-only Erlang OTP skill with examples and no hidden execution, persistence, or data access behavior.

Safe to install as instructional material. Users should keep in mind that the examples are simplified teaching snippets, especially the hardcoded door unlock code, and should adapt them with proper authentication and production controls before reuse.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (1)

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:254

Finding

Hardcoded Unlock Credential in State-Machine Example

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 254–279
Vulnerability Type: Hardcoded plaintext credential
Risk Level: Medium

Vulnerable Code

erlang

-define(CODE, "1234").

start_link() ->
    gen_statem:start_link({local, ?MODULE}, ?MODULE, [], []).

open() ->
    gen_statem:call(?MODULE, open).

close() ->
    gen_statem:call(?MODULE, close).

lock() ->
    gen_statem:call(?MODULE, lock).

unlock(Code) ->
    gen_statem:call(?MODULE, {unlock, Code}).

init([]) ->
    {ok, locked, #{}}.

callback_mode() ->
    state_functions.

%% Locked state
locked(call, {unlock, Code}, Data) when Code =:= ?CODE ->
    {next_state, unlocked, Data, [{reply, ok}]};

Technical Analysis

The example embeds the unlock credential 1234 directly in source code and compares a caller-supplied value against that constant. Anyone who can inspect the source, documentation, or potentially compiled artifacts can recover the credential. The value cannot be independently rotated without changing and redeploying the code.

The comparison also treats knowledge of a reusable plaintext value as sufficient authorization. It provides no per-user authentication, rate limiting, replay protection, credential hashing, authorization policy, or audit controls.

This file is instructional documentation rather than a directly executable application. Therefore, exploitation requires a developer to copy or adapt the example into a deployed system without replacing the placeholder authentication mechanism.

Attack Path

1. A developer copies the documented door_fsm example into an application.
2. The fixed CODE value remains unchanged in the deployed implementation.
3. An attacker reads the public example, obtains leaked source, or extracts the constant from an accessible artifact.
4. The attacker submits unlock("1234") through an exposed application interface that reaches gen_statem:call/2.
5. The guard evaluates successfully and transitions the state ma ...[truncated 823 chars]

Remediation

View remediation

Remediation Suggestions

1. Mark the credential and state-machine implementation explicitly as a non-production demonstration.
2. Remove the fixed plaintext value from source code.
3. Load authentication configuration at runtime from an approved secret manager or protected configuration source.
4. Store and compare a password verifier produced by a suitable password-hashing algorithm rather than retaining the plaintext credential.
5. Restrict access to the unlock API and apply authorization independently of possession of a shared code.
6. Add failed-attempt throttling, temporary lockout, monitoring, and security audit logging.
7. Use constant-time comparison where secret comparison remains necessary.
8. Establish a credential-rotation process that does not require source changes.
9. Add a secure production-oriented example demonstrating secret injection and access control so users are less likely to copy the insecure placeholder unchanged.

SkillSpector

Vulnerability Patterns

• Trigger Abuse: Overly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (1)

Vague Triggers

Medium

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

Finding

The 'When to Use This Skill' section uses expansive phrases like 'any stateful process,' 'all applications requiring fault tolerance,' and 'production systems requiring reliability,' without defining boundaries or exclusions. In a markdown skill file, this can create ambiguous activation scope and increase the chance of unintended invocation for general Erlang work rather than this specific OTP-behaviors skill.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.