oscerd opened a new pull request, #26661: URL: https://github.com/apache/camel/pull/26661
This fixes [CAMEL-24433](https://issues.apache.org/jira/browse/CAMEL-24433) — both ends of the same sender-chosen value. **On unmarshal**, `MimeMultipartDataFormat.getAttachmentKey()` took the file name from the part, decoded it and used it as-is to identify the attachment. `MailBinding.extractAndNormalizeFileName()` already strips control characters and reduces the name to a leaf with `FileUtil.stripPath`; the data format did neither, so a name carrying path components survived intact. It now applies the same normalisation — an attachment named `../../evil.sh` is now `evil.sh`. **On marshal**, the outgoing `Content-Type` header was built by concatenation (`contentType + "; name=" + attachmentFilename`). A legal file name may contain a semicolon or a double quote — exactly the characters that matter in a MIME parameter — so a name like `report.jpeg; boundary=--injected` injected a parameter of its own (`getParameter("boundary")` returned `--injected`). The header is now built with `ContentType.setParameter`, so `ParameterList` quotes and escapes the value when needed: the result is `image/jpeg; name="report.jpeg; boundary=--injected"` with no extra parameter. Covered by the new `MailAttachmentFileNameQuotingTest` and additions to `MimeMultipartDataFormatTest`, both failing against the previous code. The existing `MailContentTypeResolverTest` still passes: `ParameterList` only quotes values containing tspecials, so ordinary names are formatted as before. 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
