[Bug] Uploading files containing `<?php` causes `multipart: NextPart: unexpected EOF` and service crash

[loreflux]

Environment

Item	Version/Info
1Panel Version	v1.10.34-lts
OS	Ubuntu 20.04.6 LTS
Browser	Chrome
Installation Type	Standard systemd service

Summary

Uploading any file containing the string <?php via the 1Panel web file manager causes:

1. Upload progress stuck at 100%
2. Browser console shows AxiosError: Network Error (ERR_NETWORK)
3. 1Panel backend process crashes and systemd auto-restarts it
4. Backend logs show: multipart: NextPart: unexpected EOF

Steps to Reproduce

1. Login to 1Panel web UI
2. Navigate to Files → any directory
3. Upload a file containing <?php (e.g., api.php, or even test.php with just <?php\n// comment)
4. Upload progress reaches 100% and hangs indefinitely
5. After ~40s timeout, browser shows network error
6. journalctl -u 1panel shows process restart at crash time

Minimal Reproduction File

<?php
// This single line is enough to trigger the bug

Control Tests

Test Case	Result
Empty test.php	✅ Uploads successfully
test.php with <?php + any content	❌ Crashes
Same content saved as .txt (e.g., api.txt)	❌ Still crashes (content-dependent, not extension)
Same content without <?php line	✅ Uploads successfully
index.html (no <?php)	✅ Uploads successfully

Logs

Browser Console

AxiosError: Network Error
  code: "ERR_NETWORK"
  config: {transitional: {...}, adapter: Array(3), timeout: 40000, ...}
  event: ProgressEvent {isTrusted: true, lengthComputable: false, loaded: 0, total: 0, type: 'error'}
  request: XMLHttpRequest {readyState: 4, timeout: 40000, withCredentials: true, ...}

Backend Log (journalctl)

Jun 30 18:28:20 tpc-control01 systemd[1]: Stopping 1Panel...
Jun 30 18:28:20 tpc-control01 systemd[1]: 1panel.service: Succeeded.
Jun 30 18:28:20 tpc-control01 systemd[1]: Started 1Panel...
Jun 30 18:28:21 tpc-control01 1panel[3562823]: [INFO] listen at http://0.0.0.0:37715 [tcp4]

Note: The crash occurs before the backend can log the actual error. The multipart: NextPart: unexpected EOF was observed in other upload attempts.

System Status at Crash Time

• Memory: 452.5M (plenty available)
• Disk: 216G free on /
• No OOM killer involvement
• No ClamAV running
• WAF disabled during testing

Root Cause Analysis

The issue is frontend-side: the 1Panel web frontend appears to incorrectly handle the <?php string when constructing the multipart/form-data request body. Possible causes:

1. Template engine interference: The frontend build system (Vue/Vite) may interpret <?php as a template directive, corrupting the request payload
2. XSS/content filtering: Frontend sanitization may strip or alter <?php, causing Content-Length mismatch
3. Boundary collision: The <?php string may accidentally match or interfere with the multipart boundary separator

The backend crash is a secondary effect: it receives a malformed multipart body and panics during mime/multipart parsing.

Impact

• Critical: Cannot upload any PHP files via web UI
• Workaround: Use SSH/scp or edit files in-place after uploading an empty file
• Security concern: Users may resort to less secure transfer methods

Workarounds

1. Upload an empty file, then use 1Panel's built-in editor to paste content
2. Use scp or rsync directly
3. Base64-encode the file, upload as .b64, then decode on server

Suggested Fix

1. Review frontend file upload component's request body construction
2. Ensure <?php and similar strings are treated as opaque binary data, not parsed
3. Add defensive error handling in backend multipart parser to avoid panics
4. Consider adding integration tests for PHP file uploads

Related

• Go mime/multipart package: NextPart should not panic on malformed input

[wanghe-fit2cloud]

感谢反馈。我们检查了文件上传链路，前端使用浏览器 FormData 直接提交原始文件内容，不会解析或改写 <?php，后端 multipart 解析异常也会正常返回错误；目前日志中未看到可确认 1Panel 进程崩溃的 panic/堆栈信息。

multipart: NextPart: unexpected EOF 更像是请求体在传输过程中被中断或被代理、WAF、安全策略等链路截断。建议先排查相关环境因素。由于当前信息不足以确认是 1Panel 本身问题，此 issue 先关闭；如后续能提供完整崩溃日志和稳定复现环境，可再继续跟进。