oscerd opened a new pull request, #26121: URL: https://github.com/apache/camel/pull/26121
# Description `GenericFileHelper.jailToLocalWorkDirectory` — used by the file-based components to keep downloads within the configured `localWorkDirectory` — performed a **lexical** path-boundary check only. A symbolic link inside the work directory that resolves outside of it could therefore be used to write files elsewhere on the filesystem. This change brings it to parity with the cloud storage hardening done in CAMEL-24548 / CAMEL-24549 (`AzureFileNameHelper` / `GoogleCloudStorageFileNameHelper`): after the lexical check, the existing filesystem path segments are resolved (following symbolic links) and the containment is re-verified. Valid nested download paths continue to work unchanged. ## Affected components Fix lives in the shared `camel-file` helper, so all callers benefit: - `camel-file`, `camel-ftp` (FTP + SFTP), `camel-smb`, `camel-mina-sftp`, `camel-azure-files` ## Changes - `GenericFileHelper.jailToLocalWorkDirectory` now resolves existing path segments and re-checks containment (defensively guarded; skipped when no work directory boundary is configured). - Added `resolveExistingPathSegments` mirroring the approach in `AzureFileNameHelper`. - Added a symlink-escape test case to `GenericFileHelperTest`. - Upgrade guide note added for 4.23. ## Testing - `mvn test -Dtest=GenericFileHelperTest` in `components/camel-file` — all green (existing lexical cases + new symlink case; the symlink test self-skips on platforms without symlink support). _Claude Code on behalf of oscerd_ 🤖 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]
