Federico Mariani created CAMEL-24166:
----------------------------------------
Summary: camel-zipfile / camel-tarfile - maxDecompressedSize is
bypassed entirely in iterator/splitter mode (decompression-bomb protection
defeated)
Key: CAMEL-24166
URL: https://issues.apache.org/jira/browse/CAMEL-24166
Project: Camel
Issue Type: Bug
Components: camel-zipfile, camel-tarfile
Reporter: Federico Mariani
Attachments: ZipFileMaxDecompressedSizeIteratorIssueTest.java
*Severity:* High (security)
*Affects:* 4.x
h3. Problem
{{maxDecompressedSize}} (default 1 GB, documented as throwing {{IOException}}
when the decompressed size exceeds the cap) is enforced only in the
single-entry {{unmarshal}} path, where it is passed to {{IOHelper.copy(...,
maxDecompressedSize)}}. When {{usingIterator=true}}:
* {{ZipFileDataFormat.unmarshal}} constructs {{ZipIterator}} without passing
the limit, and {{ZipIterator.getNextElement()}} copies with a plain
{{IOHelper.copy(zipInputStream, cos)}} (no cap);
* {{TarFileDataFormat}} / {{TarIterator}} have the same gap.
The iterator mode is exactly the multi-entry mode used with
{{.split(bodyAs(Iterator.class)).streaming()}} — the case most exposed to
hostile uploads — so the protection is absent where it matters most.
h3. Failure scenario (reproduced)
{{maxDecompressedSize=10}}, an entry that decompresses to > 10 bytes:
* {{usingIterator=false}} -> {{IOException}} (correct);
* {{usingIterator=true}}, iterator fully consumed -> *no exception*, full
payload decompressed.
h3. Suggested fix
Plumb {{maxDecompressedSize}} into {{ZipIterator}} and {{TarIterator}}
(per-entry minimum; whole-archive if that is the documented intent). Until
fixed, the docs should note the limit is only honored when
{{usingIterator=false}}.
(Note: zip-slip is *not* a default-config vuln — the file producer's
{{jailStartingDirectory=true}} rejects traversal.)
h3. Reproducer
Attached {{ZipFileMaxDecompressedSizeIteratorIssueTest.java}}: control
({{usingIterator=false}}) throws as documented (passes); iterator-mode
assertion expects {{IOException}} and is RED (nothing thrown). The tarfile twin
shares the pattern.
----
_Reported by Claude Code on behalf of Federico Mariani (Croway). A failing
JUnit reproducer (confirmed RED on 4.22.0-SNAPSHOT) is attached._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
