Skip to content

v3.0.1

Choose a tag to compare

@zinja-coder zinja-coder released this 25 Apr 11:20
65ef29a

v3.0.1 — Security Patch: Path Traversal Hardening (CWE-22)

  • CAUTION
    • All users on v3.0.0 and below should upgrade immediately. This release fixes critical path traversal vulnerabilities that allow arbitrary file read, write, and deletion via unsanitized tool parameters.

🛡️ Security Fixes

  • Critical: Unrestricted project_dir in all tools (CWE-22)

  • All 13 MCP tools that accept a project_dir parameter previously validated it only for existence — never against the configured WORKSPACE_DIR. This allowed an AI agent (or a prompt-injected LLM) to read, write, or delete files from any location on the filesystem.

  • Most dangerous examples:

clean_project(project_dir="/var/www/myapp") → deletes build/, dist/, temp/ subdirectories via shutil.rmtree()
modify_smali_file(project_dir="/sensitive/path", ...) → arbitrary file write
search_in_files(project_dir="/etc", ...) → reads file contents from anywhere

Fix: Every tool now validates project_dir against WORKSPACE_DIR using os.path.realpath(), blocking all traversal attempts.

Affected tools: build_apk, get_manifest, get_apktool_yml, list_smali_directories, list_smali_files, get_smali_file, modify_smali_file, list_resources, get_resource_file, modify_resource_file, search_in_files, clean_project, analyze_project_structure

Critical: Path traversal via output_dir in decode_apk (CWE-22) - #9

The output_dir parameter in decode_apk and output_apk in build_apk were passed directly to apktool commands without validation, allowing APK contents to be extracted to arbitrary filesystem locations.

Fix: Both parameters are now validated against WORKSPACE_DIR using os.path.realpath().

Thanks to @head-blini for the responsible disclosure.

High: Path traversal via resource_type / resource_name sub-parameters (CWE-22)

In get_resource_file and modify_resource_file, the resource_type and resource_name parameters were concatenated into file paths via os.path.join() without sanitization. These parameters could contain .. components to escape the project directory.

Example attack: get_resource_file(project_dir="...", resource_type="../../..", resource_name="etc/passwd") → reads /etc/passwd

Fix: The resolved resource path is now validated to stay within project_dir using os.path.realpath().

High: Path traversal via smali_dir parameter (CWE-22)

In list_smali_files, the smali_dir parameter could contain .. components to list files from arbitrary directories.

Fix: The resolved smali path is now validated to stay within project_dir.

Medium: Overly permissive validate_class_name
The class name validator allowed the / character, which is not a valid Java class name character and unnecessarily increased traversal risk.

Fix: Removed / from allowed characters.

⬆️ Upgrade
No breaking changes or configuration required. All existing tool interfaces remain the same — only invalid (malicious) inputs are now rejected with clear error messages.

Full Changelog: v3.0.0...v3.0.1

Checksum SHA256:

  • apktool-mcp-server-v3.0.1.zip: 6b44ee571c644d3997a099f98216e0d590c0d50ec889480c25e812bb0ec949c6