[File] [BUG] False positive: ZIP whose first member is ppt/ is identified as Microsoft PowerPoint 2007+

Frank franknow.work at gmail.com
Fri Jul 31 05:38:39 EDT 2026


Hello,

I am resending this report without an attachment because the previous
message was rejected with: "550 5.7.1 Sorry, we do not accept .zip
file types."

I found a reproducible false positive in file/libmagic's MS OOXML magic rules.

Environment:
- macOS 15.0 (24A335)
- /usr/bin/file 5.41

Minimal reproduction (the resulting ZIP contains only an empty directory):

    d="$(mktemp -d)"
    mkdir "$d/ppt"
    (cd "$d" && zip -r repro.zip ppt)
    file "$d/repro.zip"
    file --mime-type "$d/repro.zip"
    unzip -t "$d/repro.zip"

Actual result:

    repro.zip: Microsoft PowerPoint 2007+
    repro.zip: application/vnd.openxmlformats-officedocument.presentationml.presentation

Expected result:

    repro.zip: Zip archive data
    repro.zip: application/zip

The generated archive is a valid 158-byte generic ZIP containing only
an empty top-level directory named "ppt/". It contains no
[Content_Types].xml, _rels/.rels, or ppt/presentation.xml. `unzip -t`
reports no errors.

The likely cause is magic/Magdir/msooxml: the named `msooxml` rule
accepts "ppt/" as sufficient evidence of a PowerPoint document, and
the ZIP rule calls it on the first member name at offset 0x1e. The
current upstream rule appears to retain the same direct match:

https://github.com/file/file/blob/master/magic/Magdir/msooxml

Suggested direction: when the first member is "ppt/", "word/", or
"xl/", require independent OOXML package evidence such as a root
[Content_Types].xml and/or _rels/.rels, or a format-specific main part
such as ppt/presentation.xml. A regression test should also cover
generic ZIP files whose first member is one of those ordinary
directory names.

I can prepare a patch and regression test if this direction is acceptable.

Regards,
Frank


More information about the File mailing list