Minimax Android Native Dev

• Outcome: Pass
• Latest audit: Sep 16, 2026 · 5:20 AM UTC
• Version: 1.0.0

Overview

This is a markdown Android development guide, with one privacy-sensitive logging example to watch for.

Install only if you want Android development guidance that may lead an agent to edit Gradle files, add dependencies, run builds, and install debug apps when asked. Review generated logging code and remove account identifiers, emails, tokens, or other personal data from logs.

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:431

Finding

User Identifier Exposed Through Application Logging

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 431-434
Vulnerability Type: Sensitive information written to application logs
Risk Level: Medium

Vulnerable Code

kotlin

import android.util.Log

// Info: Key checkpoints in normal flow
Log.i(TAG, "loadData: started, userId = $userId")

Technical Analysis

The Skill recommends including a user identifier in an informational Logcat message. User identifiers can constitute personal or linkable information and should not be recorded unless logging them is strictly necessary, appropriately protected, and subject to a defined retention policy.

This recommendation directly conflicts with references/privacy-security.md, which states that PII and credentials must never be logged. Informational logs may remain enabled in production and can be copied into debugging output, automated telemetry, crash reports, support bundles, or device logs. Access conditions vary by Android version and application configuration, but debuggable builds, rooted devices, development tools, privileged applications, and integrated log collectors can expose the value.

The issue is an insecure coding recommendation rather than a network exfiltration implementation. The audited code does not itself upload the identifier.

Attack Path

1. A developer or coding agent follows the logging example when implementing an Android application.
2. The resulting application records the current userId whenever loadData starts.
3. The log statement remains active in a development, testing, or production build.
4. An actor with access to Logcat, a debugging session, a diagnostic archive, a support bundle, or an integrated log collection service retrieves the entry.
5. The actor correlates the identifier with application activity, other logged events, or external account information.

This path does not grant system privileges or arbitrary code execution. Exploitation requires ...[truncated 707 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove the user identifier from the example:

   kotlin

   Log.i(TAG, "loadData: started")
   

2. If event correlation is operationally necessary, use a short-lived, non-user-derived request identifier rather than an account identifier.

3. Avoid presenting hashing alone as anonymization. Stable hashes can still permit cross-event correlation and may be reversible through enumeration when the identifier space is predictable.

4. Restrict diagnostic logging to debug builds:

   kotlin

   if (BuildConfig.DEBUG) {
       Log.d(TAG, "loadData: started")
   }
   

5. Configure release optimization rules or a structured logging abstraction to remove verbose and informational logs from production builds.

6. Add an explicit rule to the main logging section prohibiting passwords, tokens, email addresses, account identifiers, device identifiers, and other PII.

7. Review telemetry, crash-reporting, and support-bundle integrations to ensure sensitive values are redacted before collection, transmission, or retention.

8. Add static-analysis checks or lint rules that detect sensitive variable names and values passed to Android logging APIs.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Tool Misuse: Tool Parameter Abuse, Chaining Abuse, Unsafe Defaults
• 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 (4)

Hidden Instructions

High

• Category: Prompt Injection
• Confidence: 70% confidence

Finding

Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 537)May include surrounding context.

Recommended: Use Adaptive Icon (Android 8+):

xml

<!-- res/mipmap-anydpi-v26/ic_launcher.xml -->
<adaptive-icon>
    <background android:drawable="@color/ic_launcher_background"/>
    <foreground android:drawable="@mipmap/ic_launcher_foreground"/>

Hidden Instructions

High

• Category: Prompt Injection
• Confidence: 70% confidence

Finding

Hidden instructions were detected in comments or invisible text. These could contain malicious directives. Manual review is recommended.

Content

Scanner excerpt · SKILL.md (reported line 574)May include surrounding context.

#FFFFFF #000000

#FFFFFF #000000

text

Unsafe Defaults

Medium

• Category: Tool Misuse
• Confidence: 70% confidence

Finding

Tool defaults are unsafe or overly permissive (e.g. disabled TLS verification, no authentication, world-writable permissions). Unsafe defaults widen the attack surface.

Content

Scanner excerpt · references/privacy-security.md (reported line 51)May include surrounding context.

md

| Type | Security | Usage |
|------|----------|-------|
| Internal storage | Private to app | Sensitive data |
| External storage | World-readable | Shared files only |
| SharedPreferences | Private, unencrypted | Non-sensitive settings |
| EncryptedSharedPreferences | Private, encrypted | Sensitive settings |
| Room database | Private, optional encryption | Structured data |

Natural-Language Policy Violations

Low

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

Finding

The text states 'Left-aligned for body text (LTR languages)', which encodes a locale-specific presentation rule but does not provide corresponding guidance for RTL languages or indicate that alignment should adapt to the user's locale. This can be read as a language/locale policy issue because it privileges one locale direction without explicit opt-in or balanced multilingual guidance.

Content

No source excerpt is available for this finding.