Skip to content

fix: unbounded upload size when scan=false - #514

Closed
cschuerings wants to merge 1 commit into
cap-js:mainfrom
cschuerings:fix/unbounded-upload-size-scan-false
Closed

fix: unbounded upload size when scan=false#514
cschuerings wants to merge 1 commit into
cap-js:mainfrom
cschuerings:fix/unbounded-upload-size-scan-false

Conversation

@cschuerings

@cschuerings cschuerings commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Problem

validateAttachmentSize (lib/generic-handlers.js) fell back to MAX_FILE_SIZE (a function reference) instead of calling it, so length > MAX_FILE_SIZE was always false — any body size was accepted on entities without @Validation.Maximum.

Even when called correctly, MAX_FILE_SIZE() returns -1 when scan=false, and createSizeCheckHandler treats -1 as "no limit". Together, both paths produced an unbounded upload.

Fix

  • Remove MAX_FILE_SIZE in favour of a plain DEFAULT_MAX_FILE_SIZE constant (400 MB). The constant is always a real byte limit regardless of whether malware scanning is enabled, matching the documented default ("The default is 400MB" in README).
  • sizeInBytes fallbacks updated to use DEFAULT_MAX_FILE_SIZE for the same reason.

Out of scope

Uploads with a valid @Validation.Maximum annotation were not affected by this bug — the annotation path called sizeInBytes() correctly.

validateAttachmentSize used MAX_FILE_SIZE (a Function) as a plain value,
so `length > MAX_FILE_SIZE` was always false (number vs. Function object),
and any upload size was accepted on entities without @Validation.Maximum.

Two fixes:
1. Replace the MAX_FILE_SIZE function reference with DEFAULT_MAX_FILE_SIZE
   (the 400 MB constant) so the comparison is always number vs. number.
2. Don't let MAX_FILE_SIZE()'s -1 (scan=false sentinel) flow into
   validateAttachmentSize — the upload size limit must apply regardless
   of whether malware scanning is enabled (README: "The default is 400MB").

MAX_FILE_SIZE() and its -1-when-scan=false behaviour are unchanged;
DEFAULT_MAX_FILE_SIZE is exported so callers that need a hard cap can
use it directly without re-deriving the magic number.
@cschuerings
cschuerings requested a review from a team as a code owner August 4, 2026 16:28
@eric-pSAP

Copy link
Copy Markdown
Contributor

This is intended behavior, if no malware scanner is present then there is no need for a file size limit.

@eric-pSAP eric-pSAP closed this Aug 6, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants