Security audit

umeng-analytics-integration

Security checks for vulnerabilities and agentic risk

Overview

This skill appears to do what it claims: it automates Umeng analytics integration for Android projects, but it can modify project files, run Gradle builds, and add analytics network behavior.

Install only if you intend to add Umeng analytics to the target Android app. Run it on a version-controlled or copied project, review Gradle, manifest, ProGuard, and Application changes before committing, use Gradle builds only on projects you trust, and verify that added analytics collection, network permissions, and UMConfigure logging are acceptable for your app and compliance needs.

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Behavioral ASTexec() Call, eval() Call, Dynamic Import
MCP Least PrivilegeUnderdeclared Capability, Wildcard Permission, Missing Permission Declaration
MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands

Findings (14)

subprocess module call

Medium

Category: Dangerous Code Execution
Content: try: # 获取启动Activity result = subprocess.run( ['adb', '-s', device_serial, 'shell', 'cmd', 'package', 'resolve-activity', '--brief', package_name], capture_output=True, text=True,
Confidence: 88% confidence
Finding: This call passes `package_name` into `adb shell cmd package resolve-activity`, which executes within a remote shell context on the Android device. Even though Python is not spawning a local shell, untrusted values sent through `adb shell` can still trigger device-side argument or shell interpretation issues, making this a real injection surface if `package_name` is attacker-controlled.

subprocess module call

Medium

Category: Dangerous Code Execution
Content: activity = lines[-1] # 最后一行是Activity # 启动应用 subprocess.run( ['adb', '-s', device_serial, 'shell', 'am', 'start', '-n', activity], capture_output=True, timeout=10
Confidence: 93% confidence
Finding: The `activity` value is derived from device output and then passed into `adb shell am start -n`, creating a trust boundary violation. A malicious or compromised device, emulator, or manipulated ADB response could return crafted text that alters device-side command behavior, leading to unintended command execution or actions on the connected device.

subprocess module call

Medium

Category: Dangerous Code Execution
Content: return True else: # 如果无法获取Activity,使用monkey启动 subprocess.run( ['adb', '-s', device_serial, 'shell', 'monkey', '-p', package_name, '-c', 'android.intent.category.LAUNCHER', '1'], capture_output=True, timeout=10
Confidence: 87% confidence
Finding: This call passes `package_name` into `adb shell monkey -p`, again sending potentially untrusted input into a device-side shell command. If an attacker can influence the package name, they may be able to manipulate the command executed on the Android device or trigger unintended behavior.

subprocess module call

Medium

Category: Dangerous Code Execution
Content: print(f" ⚠️ 配置JAVA_HOME失败: {str(e)}") # 执行编译 result = subprocess.run( [gradlew, 'assembleDebug', '--no-daemon'], cwd=self.project_path, capture_output=True,
Confidence: 97% confidence
Finding: The validator executes the project's local Gradle wrapper from an attacker-controlled repository path. Running `gradlew assembleDebug` is not a passive check: Gradle build scripts, plugins, init scripts, and the wrapper itself can execute arbitrary code during configuration or build, so analyzing an untrusted project can trigger code execution on the host.

Lp3

Medium

Category: MCP Least Privilege
Confidence: 95% confidence
Finding: The skill advertises and documents capabilities to read environment variables, modify project files, and execute shell commands, but it does not declare permissions or clearly bound those operations. This creates a trust and review gap: users cannot accurately assess what the skill may access or change before running it, especially because it performs automated edits and build/adb-related commands.

Intent-Code Divergence

Medium

Confidence: 96% confidence
Finding: The workflow documentation and step numbering indicate that SDK/logcat verification is part of the automated process, but the main function never calls the verification step. This creates a false sense of completion: users may trust the tool's success message even though runtime telemetry initialization and reporting were never actually checked.

Description-Behavior Mismatch

Medium

Confidence: 88% confidence
Finding: The code presents a verification step but, on failure, only prints manual logcat instructions and always returns True, so the pipeline treats verification as non-blocking and effectively unaudited. In a build/integration skill, this is dangerous because it can mark an SDK integration as complete without confirming the analytics SDK is correctly initialized or safely behaving at runtime.

Intent-Code Divergence

Low

Confidence: 90% confidence
Finding: The report function accepts build and verification results but ignores them and hardcodes partial/pending states, which undermines the integrity of the generated report. This is primarily a trust and auditability issue: downstream users or automation cannot rely on the report to understand what was actually validated.

Description-Behavior Mismatch

Medium

Confidence: 95% confidence
Finding: The code labeled as project 'validation' mutates `gradle.properties` by setting `org.gradle.java.home`, which violates the principle of least surprise and can permanently alter the target project state. In an agent skill context, hidden modification during a verification step is risky because it can break builds, override existing configuration, or mask later changes as part of routine validation.

Description-Behavior Mismatch

Medium

Confidence: 95% confidence
Finding: The integrator can create a new settings.gradle/settings.gradle.kts with hard-coded rootProject.name and include(":app") when it cannot find an expected repositories block. In an existing Android project, this can silently overwrite or replace core build configuration, breaking module layout or causing the build to resolve the wrong project structure; while not an exploit primitive by itself, it is an unsafe destructive modification of project metadata.

Missing User Warnings

Medium

Confidence: 92% confidence
Finding: The skill states it will automatically integrate the SDK by changing Gradle files, manifests, ProGuard rules, and Application classes, but it does not prominently warn users up front that source and build configuration will be modified. In a codebase automation context, silent or under-disclosed file mutation can introduce supply-chain, stability, and review risks if users run it without understanding the extent of changes.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The skill includes analytics SDK initialization, network reporting, and logcat-based verification, but it does not clearly warn users that the integration may transmit analytics data off-device and emit identifiable SDK status information to logs. Because this is an analytics integration skill, the behavior is expected, but the missing privacy and network disclosure still increases risk for unsuspecting users or regulated environments.

Missing User Warnings

Medium

Confidence: 90% confidence
Finding: The script injects analytics SDK initialization and adds INTERNET/ACCESS_NETWORK_STATE permissions without any explicit disclosure that application/runtime data may be transmitted to a third party. In the context of an automation skill that modifies production app code, this creates a meaningful privacy and compliance risk because users may unknowingly ship telemetry-enabled software.

Missing User Warnings

Medium

Confidence: 89% confidence
Finding: The integrator performs broad source, Gradle, manifest, ProGuard, and Application-class modifications immediately once invoked, with no approval step beyond command execution. In a skill context, this is dangerous because it automates high-impact changes to build and runtime behavior, increasing the chance of unintended or unsafe modifications being applied to the wrong project or module.

Static analysis

No suspicious patterns detected.