Repository navigation
add followSymlinks option to restrict symlink traversal #297
Description
Currently, send resolves file paths using string normalization but does not check whether the final canonical path (after symlink resolution) remains inside the configured root. This means symbolic links inside the root can point to — and serve — files outside of it.
Proposal
Add a followSymlinks option (default: true for backward compatibility):
true— current behavior, symlinks are followed.false— resolve the canonical path viafs.realpath()and reject the
request if it falls outsideroot.
Example implementation sketch:
if (!options.followSymlinks) {
const real = await fs.promises.realpath(path)
if (!real.startsWith(root + path.sep) && real !== root) {
return this.error(403)
}
}Motivation
This gives developers an explicit opt-in safeguard, similar to how dotfiles already provides control over another filesystem-level concern. It is especially useful for applications that serve user-writable directories.
Backward Compatibility
Defaults to true, so no breaking change just a semver-minor.
Notes
Original idea by @san3ncrypt3d
Activity
[-]followSymlinks option to restrict symlink traversal[/-][+]add `followSymlinks` option to restrict symlink traversal[/+]feat: add followSymlinks option to restrict symlink traversal
san3ncrypt3d commentedon Feb 27, 2026
https://github.com/pillarjs/send-ghsa-c3vr-2mrr-vp94
I had created a private repo with the fix
blakeembrey commentedon Mar 21, 2026
A heads up, but there is an ongoing plan to refactor some of this API to decouple it a bit from node HTTP request/response (#159). If that occurs, this might be a good candidate for a feature that lives upstream of the package, as we can return the filename/stream and it can be used to alter the behavior before sending it to
res. This feature may also be able to tackle the request in #71 too.So I'd like to hold off on this in the immediate future and potentially re-investigate in a few months.