Manus.im Security Disclosure Report (April 2025) - Revised

Executive Summary

This report details critical security vulnerabilities discovered within the Manus.im infrastructure. Investigation revealed that an improperly isolated code-server development environment grants authenticated users extensive access to server internals. This includes the root filesystem, sensitive configuration files (e.g., within /etc), internal API tokens, cryptographic tools, and core platform logic. The severity of this exposure presents a significant risk, potentially allowing compromise of the entire Manus.im backend stack. Immediate remediation is strongly advised.

Detailed Findings

The following vulnerabilities were identified through analysis of the Manus.im platform and its associated code-server environment:

1. Root Filesystem Exposure via Code-Server

• Description: The integrated code-server environment, accessible to authenticated users, does not properly restrict filesystem access. Users can browse and potentially modify the entire server filesystem, including critical system directories like /, /etc, /opt, /root, and user home directories.
• Evidence: Screenshots confirm browsing access to / and /etc directories via the code-server web interface (See Appendix A, Figures 1 & 2). Additional screenshots show access to specific files within /etc (See Appendix A, Figure 3).
• Impact: Unauthorized access to system configuration files, environment variables, potentially sensitive user data, application source code, and deployment scripts. This allows attackers to understand the system architecture, discover further vulnerabilities, escalate privileges, or disrupt services.

2. Insecure Handling of API Tokens

• Description: An internal API token for ApiProxyService is stored in plaintext within the user's home directory at .secrets/sandbox_api_token. The runtime code reads this token directly from the file, as indicated by the following snippet identified in the environment:

  with Path().home().joinpath('.secrets/sandbox_api_token').open('r') as f:
      self.token = f.read().strip()

• Evidence: Code snippet identified in the runtime environment. Filesystem access (Finding 1) allows any user to navigate to the .secrets/ directory and read this token (See Appendix A, Figure 4).
• Impact: Any user with code-server access can retrieve this token and potentially impersonate the system or other users when interacting with internal APIs, bypassing intended access controls and gaining unauthorized access to sensitive operations or data.

3. Exposure of Cryptographic Tools and Potential Key Compromise

• Description: The Python runtime environment located at /opt/.manus/.sandbox-runtime/.venv/bin/ includes the full PyRSA cryptographic tool suite (pyrsa-keygen, pyrsa-decrypt, pyrsa-sign, etc.).
• Evidence: Filesystem access (Finding 1) allows browsing to this directory and confirms the presence of these tools, as initially noted in the original report.
• Impact: Allows users within the code-server environment to perform arbitrary cryptographic operations such as key generation, signing, and decryption directly from the runtime. If private keys are stored unprotected on the filesystem (which is accessible due to Finding 1), they are susceptible to compromise. Executing cryptographic operations directly from this environment bypasses potential security layers, auditing mechanisms, and proper key management practices.

4. Potential Concurrency Issues with greenlet

• Description: The runtime environment utilizes the greenlet library, a low-level tool for managing coroutines (micro-threads). While potentially offering performance benefits in I/O-bound systems, manual concurrency control with libraries like greenlet is inherently complex and significantly increases the risk of subtle errors compared to standard async/await patterns.
• Evidence: Presence of the greenlet library identified in the runtime environment, as described in the original report.
• Impact: High potential for difficult-to-detect bugs such as race conditions, deadlocks, or unpredictable application states, particularly if greenlet is employed in critical components responsible for handling parallel logic or processing user data concurrently. Such flaws could lead to data corruption, denial of service, or security vulnerabilities.

5. Insecure Direct Object References & API Exposure

• Description: Multiple internal API endpoints and file resources appear to be directly accessible without sufficient authorization checks or identifier obfuscation. Files are served from a content delivery network (CDN) path (files.manuscdn.com/tmp/) using seemingly predictable or easily guessable paths, lacking necessary security mechanisms like presigned URLs. Furthermore, API endpoints reveal internal service names and versioning information (e.g., api.manus.im/user.v1.UserService, api.manus.im/operation.v1.PlayCard).
• Evidence: Network traffic logs captured during testing show direct requests being made to various internal API endpoints and CDN file paths (See Appendix A, Figure 5). Analysis of API request and response headers confirms interactions with internal services and reveals structural information (See Appendix A, Figures 6 & 7).
• Impact: Leakage of sensitive information about the internal system architecture, which can aid attackers in mapping out the system and identifying further weaknesses. Potential for unauthorized access to user data or restricted system functionality by crafting malicious API requests or guessing file URLs. The lack of URL signing for CDN resources allows unauthorized sharing, caching, and access to potentially sensitive files.

Recommendations

Based on the findings, the following remediation steps are recommended, categorized by urgency:

Immediate Actions (Critical Priority)

• Isolate Code-Server Environment: Implement strict sandboxing for the code-server environment immediately. This must prevent access to the host filesystem, especially sensitive directories (/etc, /opt, /root, other user home directories), configuration files, and secrets. Utilize containerization technologies (e.g., Docker) with tightly controlled volume mounts (read-only where possible) and user privilege restrictions.
• Secure API Token Handling: Remove the plaintext API token from the .secrets/sandbox_api_token location immediately. Transition to a secure secret management solution (e.g., HashiCorp Vault, AWS Secrets Manager, Google Secret Manager, or securely injected environment variables) for handling all API tokens, keys, and other credentials. Ensure secrets are never stored in code or accessible filesystems within user-reachable environments.
• Review and Restrict API Endpoints: Conduct an immediate audit of all exposed API endpoints. Implement robust authentication and authorization checks for every single request, enforcing the principle of least privilege. Ensure endpoints only expose the absolute minimum data required for their function. Consider implementing an API gateway for centralized security policy enforcement, rate limiting, and request validation.

Further Actions (High Priority)

• Implement Presigned URLs: Mandate the use of URL signing (presigned URLs) with short, configurable expiry times for all files and resources served via the CDN (files.manuscdn.com) or any other public-facing storage. This prevents unauthorized access, enumeration, and deep-linking.
• Anonymize Resource Identifiers: Replace predictable or sequential identifiers for files, user resources, and other objects with random, non-guessable identifiers (e.g., UUIDs - Universally Unique Identifiers).
• Remove Unnecessary Tools from Runtime: Remove the PyRSA cryptographic tool suite and any other non-essential development tools, compilers, or system utilities from the production runtime environment accessible via code-server. Cryptographic operations must only be performed in dedicated, secure, and audited backend services using approved key management practices.
• Security Audit of Concurrency Logic: If greenlet is essential for performance, conduct a thorough security audit of all code utilizing it, specifically looking for race conditions, resource leaks, and other concurrency-related vulnerabilities. Evaluate the feasibility of migrating critical concurrent logic to standard, safer async/await patterns provided by modern Python.
• Implement Detailed Audit Logging: Enhance API and system-level audit logging significantly. Logs should capture details of access attempts (successful and failed), operations performed, resources accessed, source IP addresses, and user identifiers. Implement robust anomaly detection systems monitoring these logs to proactively identify suspicious activity.
• Review JWT/Session Security: If using JWT or session-based authentication, implement fine-grained scopes or permissions within tokens to enforce least privilege at the API level. Ensure secure token generation, transmission (HTTPS only), storage (HttpOnly, Secure cookies), and timely invalidation upon logout, password change, or detection of suspicious activity.

Disclosure Timeline

• April 28, 2025: Initial contact made to Manus.im support regarding security concerns.
• April 29, 2025: Technical details compiled and supporting evidence gathered.
• April 30, 2025: This revised and detailed security disclosure report prepared. As of this date, Manus.im has not yet formally acknowledged or responded to the initial security report despite repeated contact attempts.

Conclusion

The vulnerabilities identified in this report represent a critical and immediate risk to the security, integrity, and availability of the Manus.im platform and the confidentiality of its user data. The combination of unrestricted filesystem access from a development environment, exposed API tokens, insecure file handling practices, accessible cryptographic tools, and potentially vulnerable internal logic creates a high-impact attack surface.

Continued operation in the current state poses a severe risk of significant data breaches, potential non-compliance with data protection regulations (e.g., GDPR), substantial financial penalties, and irreparable damage to the Manus.im brand and user trust.

We strongly recommend taking the affected systems offline immediately to conduct a full security audit and implement the critical remediation steps outlined in this report before restoring service to users.

Appendix A: Visual Evidence

The following figures provide visual evidence supporting the findings detailed in this report.

(Note: Additional screenshots, including one showing potentially binary data (figure_extra.png), were provided but not explicitly referenced unless directly supporting a specific finding.)