Attachment Preset Size-Limit Bypass and Storage Accounting Corruption in Local-Storage Mode

Summary

In local-storage mode the two-step upload flow (attachments.create → files.create) separates size enforcement from the actual file write: attachments.create checks the caller-declared size against a per-preset limit, while files.create enforces only the global multipart cap (max(FILE_STORAGE_UPLOAD_MAX_SIZE, FILE_STORAGE_IMPORT_MAX_SIZE)). Because the schema accepts any z.number() including negatives, and because @IsNumeric with validator.js 13 accepts signed numbers, a user can declare size: -1 to bypass the API guard. The actual file written is limited only by the global multipart cap (which can greatly exceed per-preset limits in typical operator configurations), and the attachment record retains the forged size value — permanently poisoning team storage accounting.

Severity

Medium (CVSS 3.1: 4.2)

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

• Attack Vector: Network — the two endpoints are reachable over the API by any authenticated team member.
• Attack Complexity: Low — two sequential HTTP requests; no chaining or prior state required.
• Privileges Required: Low — any authenticated user (member, editor) can call attachments.create.
• User Interaction: None.
• Scope: Unchanged — impact stays within the application's own storage and accounting subsystems.
• Confidentiality Impact: None.
• Integrity Impact: Low — storage accounting records (DB size field, team usage totals) are permanently corrupted wi…