ClawHub
Back to skill

Security audit

Android Native Dev.Bak

Security checks for vulnerabilities and agentic risk

Overview

This is a documentation-only Android development guide with one privacy-weak logging example, but no hidden execution, persistence, or unrelated access behavior.

Before installing, treat this as a broad Android coding reference. Avoid copying the sample log line that prints userId or other identifiers; follow the privacy-security reference instead and keep sensitive or linkable data out of logs. Review Gradle dependency versions and device install commands before allowing an agent to run them in your project.

A.I.G

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
SKILL.md:434
Finding

Production-Style Logging Exposes User Identifiers

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, line 434
Vulnerability Type: Sensitive information exposure through application logging
Risk Level: Medium

Complete Code Snippet:

kotlin
Log.i(TAG, "loadData: started, userId = $userId")

Technical Analysis

The Skill presents an INFO-level log containing a user identifier as a recommended logging pattern. User IDs are potentially personal or linkable information. The example has no BuildConfig.DEBUG guard, redaction, hashing, or release-build log suppression, so an agent following this guidance may incorporate it into production code.

This recommendation also conflicts with references/privacy-security.md, line 67, which correctly states that personal information must not be logged. Logging the identifier at INFO level increases the likelihood that it will be retained by diagnostic systems or included in collected application logs.

Attack Path

  1. An agent uses the Skill while implementing Android application logging.
  2. The agent follows the recommended pattern and substitutes a real account identifier for userId.
  3. The logging statement remains enabled in a release build.
  4. The application writes the identifier to Logcat whenever data loading begins.
  5. A connected debugging host, a process with sufficient log access, device-diagnostic tooling, or a log-collection SDK obtains the log entry.
  6. The exposed identifier may be correlated with application activity or other collected records.

This does not independently provide privilege escalation or code execution; exploitation requires access to application logs or a diagnostic pipeline that collects them.

Impact Assessment

The issue can disclose user-linked identifiers and operational activity within the affected application. Its scope is limited to values passed to the logging statement and the parties capable of reading or collecting those logs. Potential consequences include privacy leakage, cross-record ...[truncated 257 chars]

Remediation
View remediation

Remediation Suggestions

Remove user identifiers and other request parameters from the recommended logging example. Log only a generic operational event:

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

Apply the following hardening measures:

  1. Prohibit passwords, tokens, email addresses, user IDs, session IDs, payment data, and other personal or linkable values in logs.
  2. Restrict development diagnostics to debug builds using BuildConfig.DEBUG.
  3. Configure release builds to remove or suppress verbose logging.
  4. If correlation is strictly necessary, use a short-lived, non-user-derived diagnostic identifier rather than a persistent account identifier.
  5. Add automated lint or static-analysis rules to detect sensitive values passed to Android logging APIs.
  6. Align the primary logging section with the stricter rule in references/privacy-security.md.

SkillSpector

Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Tool MisuseTool Parameter Abuse, Chaining Abuse, Unsafe Defaults
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (5)

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
79% confidence
Finding

The markdown includes the instruction "Left edge (LTR)", which encodes locale-specific UI behavior in natural language. Because the document does not explicitly mention handling RTL locales or making this locale-aware, it may conflict with language/locale policy expectations.

Content

No source excerpt is available for this finding.

Natural-Language Policy Violations

Low
Category
Not specified by scanner
Confidence
78% confidence
Finding

The guideline explicitly states body text should be left-aligned for LTR languages, but provides no corresponding recommendation for RTL languages. This can encode a locale-specific assumption in a general design reference without documenting user choice or broader locale support.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.