Back to skill

Security audit

Didit Phone Verification

Security checks for vulnerabilities and agentic risk

Overview

The skill is mostly coherent for Didit phone verification, but it handles phone numbers, OTPs, optional device telemetry, API keys, and billing-related actions without enough protective guidance.

Review this skill before installing if you will use it with real users. Only provide Didit API keys in a controlled environment, avoid passing real OTPs directly on the command line, minimize optional device/IP signals unless needed for fraud prevention, and require explicit user confirmation before any billing or credit top-up action.

Vulnerability Patterns
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (1)

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/verify_phone.py:72
Finding
Sensitive Phone Number and OTP Exposed Through Command-Line Arguments## Vulnerability Details **File Location**: `scripts/verify_phone.py`, lines 72–73 **Vulnerability Type**: Sensitive data exposure through process arguments **Risk Level**: Medium ```python check_p.add_argument("phone", help="Phone number in E.164 format") check_p.add_argument("code", help="Verification code received") ``` ### Technical Analysis The verification workflow requires users to pass both the phone number and one-time verification code as positional command-line arguments. Command-line arguments are not an appropriate secret-input channel because they may be: - Stored in shell history. - Captured by endpoint monitoring, audit, or process telemetry. - Exposed in diagnostic logs or terminal transcripts. - Temporarily visible to other local users through process-inspection facilities, depending on operating-system permissions and configuration. The OTP is short-lived, but disclosure during its validity period may allow an attacker to submit it to the verification service. Associating the OTP with the simultaneously exposed phone number makes the captured data directly actionable. The script sends the API key, phone number, and OTP only to the declared HTTPS Didit endpoint. That network transmission is necessary for the Skill's stated phone-verification functionality and does not itself exceed minimum required privileges. No unrelated network destination or covert exfiltration behavior was identified. ### Attack Path 1. A user follows the documented workflow and runs the script with the phone number and OTP as positional arguments. 2. The shell records the command in history, process telemetry captures it, or a locally authorized observer inspects the process arguments while it is running. 3. The observer extracts both the phone number and active OTP. 4. Before the OTP expires or reaches its attempt limit, the observer submits the captured values to the corresponding verification endpoint. 5. If the verific ...[truncated 820 chars]
Remediation
## Remediation Suggestions - Remove the OTP positional argument and read it interactively using `getpass.getpass()` so it is not echoed or placed in shell history. - Support protected standard input for automation, with clear guidance to use a restricted pipe or secret-management facility rather than a command-line argument. - Consider collecting the phone number interactively as well where privacy requirements treat it as sensitive personal data. - Update all usage examples in `SKILL.md` and the script docstring so they do not show OTPs directly on the command line. - Document that users should clear any existing shell-history entries, terminal recordings, or automation logs containing real OTPs. - Avoid logging request payloads and redact phone numbers and verification codes from exceptions, diagnostics, and monitoring output.
Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (8)

Lp3

Medium
Category
MCP Least Privilege
Confidence
95% confidence
Finding
The skill requires environment access and clearly instructs network requests to external APIs, but it does not declare explicit tool scope such as allowed-tools or permissions. This weakens sandboxing and review controls because an agent may be able to use capabilities not transparently declared to users or policy systems.

Missing User Warnings

Medium
Confidence
90% confidence
Finding
The skill documents a top-up flow that can initiate paid account actions, but it does not clearly warn that following the instructions may create charges. In an agent setting, undocumented billing actions can lead to unauthorized or surprising financial impact if a workflow executes or suggests them without strong confirmation.

Missing User Warnings

Medium
Confidence
92% confidence
Finding
The skill instructs sending phone numbers plus optional IP address, device ID, platform, model, OS version, app version, and user agent to a third-party API without an explicit privacy notice or user-consent warning. This creates a real privacy and compliance risk because sensitive personal and device telemetry may be transmitted externally without informed disclosure or data-minimization guidance.

External Transmission

Medium
Category
Data Exfiltration
Content
```python
import requests

response = requests.post(
    "https://verification.didit.me/v3/phone/send/",
    headers={"x-api-key": "YOUR_API_KEY", "Content-Type": "application/json"},
    json={
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
```python
import requests

response = requests.post(
    "https://verification.didit.me/v3/phone/send/",
    headers={"x-api-key": "YOUR_API_KEY", "Content-Type": "application/json"},
    json={
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
```python
import requests

response = requests.post(
    "https://verification.didit.me/v3/phone/send/",
    headers={"x-api-key": "YOUR_API_KEY", "Content-Type": "application/json"},
    json={
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
```

```typescript
const response = await fetch("https://verification.didit.me/v3/phone/send/", {
  method: "POST",
  headers: { "x-api-key": "YOUR_API_KEY", "Content-Type": "application/json" },
  body: JSON.stringify({
Confidence
60% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

External Transmission

Medium
Category
Data Exfiltration
Content
### Example

```python
response = requests.post(
    "https://verification.didit.me/v3/phone/check/",
    headers={"x-api-key": "YOUR_API_KEY", "Content-Type": "application/json"},
    json={
Confidence
70% confidence
Finding
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.

Static analysis

No suspicious patterns detected.