feishu file transfer guide

• Outcome: Review
• Latest audit: Sep 12, 2026 · 1:12 AM UTC
• Version: 1.0.0

Overview

The skill is a coherent Feishu file-transfer guide, but its sample code disables HTTPS verification while sending app secrets, tokens, and local file contents.

Review before installing or using. Do not run the Python examples as written: remove the lines that set check_hostname to False and verify_mode to CERT_NONE, keep Feishu app secrets outside source code, and only upload files and send messages after confirming the exact file path and recipient are intended.

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

Error

• Location: SKILL.md:96

Finding

TLS Certificate and Hostname Verification Disabled

Content

View full analysis

Vulnerability Details

File Location: SKILL.md, lines 96–98 and 244–246
Vulnerability Type: Improper TLS certificate validation
Risk Level: High

Vulnerable Code

The recommended upload example disables both hostname and certificate verification:

python

ssl_context = ssl.create_default_context()
ssl_context.check_hostname = False
ssl_context.verify_mode = ssl.CERT_NONE

The complete example repeats the same configuration:

python

self.ssl_context = ssl.create_default_context()
self.ssl_context.check_hostname = False
self.ssl_context.verify_mode = ssl.CERT_NONE

This context is then passed to the token, file-upload, and message API requests:

python

with urllib.request.urlopen(req, context=self.ssl_context) as res:
    result = json.loads(res.read().decode('utf-8'))

Technical Analysis

The Skill's declared purpose requires sending credentials, file contents, and message information to the official Feishu API. That network behavior is functionally necessary. However, disabling TLS certificate and hostname verification is not necessary and violates least-secure-access principles.

ssl.CERT_NONE causes the client to accept an untrusted or attacker-controlled certificate. Disabling check_hostname also prevents the client from confirming that the certificate belongs to open.feishu.cn. Although the URL uses HTTPS, these settings remove the server-authentication guarantee normally provided by TLS.

The affected requests include:

• Token acquisition, which transmits the Feishu app_id and app_secret.
• File upload, which transmits a bearer token and the entire selected local file.
• Message delivery, which transmits a bearer token, recipient identifier, and file key.

The examples use the same insecure context for all these operations. A user following the documentation would therefore deploy code vulnerable to interception.

Attack Path

1. A victim ...[truncated 1626 chars]

Remediation

View remediation

Remediation Suggestions

1. Remove both insecure TLS assignments from every example:

   python

   ssl_context.check_hostname = False
   ssl_context.verify_mode = ssl.CERT_NONE
   

2. Retain Python's secure default certificate and hostname validation:

   python

   ssl_context = ssl.create_default_context()
   

3. Apply the corrected context consistently to token acquisition, file upload, and message-delivery requests.

4. If a private trust store is genuinely required, accept an explicit CA bundle rather than disabling verification:

   python

   ssl_context = ssl.create_default_context(cafile="/path/to/trusted-ca.pem")
   

5. Do not provide a permissive fallback that retries with CERT_NONE after a certificate error. Fail closed and report certificate-validation failures to the user.

6. Store application secrets outside source code, preferably in a protected secret manager or environment variable, and avoid printing tokens or secrets in logs.

7. After correcting the examples, rotate any application secrets and invalidate tokens that may previously have traversed networks using the insecure configuration.

SkillSpector

Vulnerability Patterns

• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• MCP Tool Poisoning: Hidden Instructions, Unicode Deception, Parameter Description Injection
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (5)

Missing User Warnings

Medium

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

Finding

The skill is specifically designed to upload local files to Feishu and send them over the network, yet it provides no explicit warning, consent requirement, or privacy boundary around transmitting local data to a third-party service. In an agent context, this increases the risk of accidental exfiltration of sensitive files because users may treat it as a local file-send helper without understanding the external transfer and retention implications.

Content

No source excerpt is available for this finding.

Cloud Storage Exfiltration

Medium

• Category: Data Exfiltration
• Confidence: 94% confidence

Finding

The example code performs outbound transfer of a local file to Feishu, which is a genuine exfiltration primitive even though it is presented as intended functionality. In the context of an agent skill, that is more dangerous because the pattern can be repurposed to send arbitrary local files, and the code also disables TLS certificate verification, further weakening transport trust while handling potentially sensitive content.

Content

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

md

# 执行传输（支持中文文件名）
    transfer = FeishuFileTransfer(APP_ID, APP_SECRET)
    token = transfer.get_token()
    file_key = transfer.upload_file(token, FILE_PATH, '语文.docx')  # 中文文件名
    result = transfer.send_file(token, file_key, RECEIVE_ID)
    
    print(f'发送成功: {result}')

Natural-Language Policy Violations

Low

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

Finding

SQP-3 applies to all file types and includes language or locale policy violations. The instruction '文件名使用英文' directs users toward a specific language choice rather than offering it as an optional workaround, and the document does not frame this as a user opt-in decision or a formally required regional constraint.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Low

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

Finding

The '关键要点' section says filenames should use English to avoid Chinese encoding problems, which implies Chinese names are problematic or unsupported. However, the Python example immediately demonstrates display_name='语文.docx' and later comments state Chinese filenames are supported and can display correctly, creating a direct documentation contradiction rather than a mere omission.

Content

No source excerpt is available for this finding.

Intent-Code Divergence

Low

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

Finding

The notes and troubleshooting table instruct readers to ensure the file_name field is correctly encoded, suggesting an actual form field named file_name is required. In the provided Python implementation, the multipart body only includes file and file_type, with the filename carried in Content-Disposition: ... filename=..., so the documentation actively describes a different mechanism than the code uses.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.