Re: Path Traversal Vulnerability in pg_dump Directory Format - Mailing list pgsql-hackers

On Fri, Jul 3, 2026 at 10:53 PM Imran Zaheer <imran.zhir@gmail.com> wrote:
>
> Hi
>
> +        strstr(relativeFilename, "..") != NULL ||
>
> This will also reject a valid unix filename i.e. "blob..1.toc" which
> are unrelated to path traversal. Should we care about such file names
> here?
>
I think instead of strstr we can check direct string "." and ".." as
changed in my patch..
>
>
> On Fri, Jul 3, 2026 at 8:07 PM Jonathan Gonzalez V.
> <jonathan.abdiel@gmail.com> wrote:
> >
> >
> > Hello!!
> >
> > Dilip Kumar <dilipbalaut@gmail.com> writes:
> > > I would like to submit a patch to address a path traversal
> > > vulnerability in pg_dump's directory format mode (-F d). Currently,
> > > filenames listed in directory-format TOC files (toc.dat and
> > > blobs_*.toc) are treated as trusted when reading an archive during a
> > > restore. If an archive entry filename is maliciously modified to
> > > contain path traversal elements (such as ..) or directory separators,
> > > pg_restore can be tricked into reading files outside the intended
> > > backup directory.  The attached patch fixes this vulnerability.
> >
> > I was taking a look into the patch and, yes it works as expected, but I
> > also manage to get the same result of a path traversal having a with a
> > symlink as follow:
> >
> > blob_16388.dat -> ../../../../../../../etc/passwd
> >
> > Probably it could be worthy to add the symlink check with lstat() ?

Yeah that makes sense. I have fixed that.

--
Regards,
Dilip Kumar
Google