Do not open a public GitHub issue for security vulnerabilities.

Use one of the following private channels:

• GitHub private security advisory (preferred): https://github.com/FlavioCFOliveira/GoMetadata/security/advisories/new
• Email: Include a minimal reproducer, the Go version, and the OS. If attaching a sample file, a synthetically crafted minimal file is preferred over a real photo that may contain personal data.

You will receive an acknowledgement within 72 hours. A fix will be prepared and released before public disclosure. Credit will be given in the release notes unless you prefer to remain anonymous.

Only the latest release receives security fixes. If you are on an older release, upgrade before filing a report.

GoMetadata is a parsing library. Its primary attack surface is untrusted bytes supplied as image input. The threat model and the guarantees the library provides are described below.

• The library is safe to use on untrusted input. Every parser that consumes bytes from an external source has a corresponding fuzz target that is run continuously in CI. Crashes found by the fuzzer are treated as P0 bugs.
• The library does not panic on malformed input. Parsers return errors instead of panicking. Spec deviations are handled gracefully and documented in code comments.
• No unbounded allocations. All parsers enforce size limits before allocating. Value counts and string lengths derived from file data are validated before use.
• No external network access. The library reads only from the io.ReadSeeker or file path the caller provides. It never initiates network connections.
• No file-system side effects. Read operations are read-only. Write operations are scoped strictly to the output path provided by the caller.

Write operations have a narrower, explicitly documented trust boundary that is distinct from the read-path guarantees above:

• Symlink following is intentional. WriteFile resolves the target path with filepath.EvalSymlinks and rewrites the resolved real file, not the symlink itself (decision #125). This is correct for the common case — rewriting metadata on a file reached through a symlink — but it means WriteFile follows a symlink to wherever it points, including outside any directory tree the caller may have intended to restrict writes to. WriteFile performs no path-safety validation of its own. Path validation is the caller's responsibility: an application that accepts a path from an untrusted source (user input, a web request parameter, an archive entry name, etc.) must validate or reject symlinks before calling WriteFile, exactly as it would before calling os.OpenFile or any other path-based standard library function.
• The streaming Write(r, w, m) API may emit partial output on error. Write writes directly to the caller's io.Writer as it encodes; it does not buffer the complete result first. If encoding fails partway through, w may already contain a truncated or inconsistent byte sequence. Callers that require all-or-nothing semantics — the destination is either the complete, correct result or is left untouched — must use WriteFile, which isolates all output in a temporary file created in the target directory and removed on any error, only replacing the original file via an atomic os.Rename after a full, synced write succeeds.
• Privilege bits are never propagated to rewritten output. WriteFile preserves the original file's ordinary permission bits (e.g. 0644, 0755) but always clears setuid, setgid, and the sticky bit on the replacement file, even if the original file carried them (#259). A metadata rewrite must never (re)create a privilege-escalation surface, even preservation-only.

All 29 fuzz targets run continuously in CI using Go's built-in fuzzer. Crash-inducing inputs found during a run are committed to testdata/fuzz/<Target>/ and are replayed automatically on every subsequent go test invocation. MakerNote parsing (Canon, Nikon, Sony, Olympus, Panasonic, Pentax, DJI, FujiFilm, Leica, Samsung, Sigma, Minolta, Casio) is consolidated into a single file, exif/makernote_parse.go, dispatched from and covered by FuzzParseEXIF — there are no separate per-vendor MakerNote fuzz targets or packages.

This inventory is verified directly against the source tree (grep -rn '^func Fuzz' --include='*.go' .); if you add or rename a fuzz target, update this table in the same change.

Every container format with a write path has both an Extract (read) and an Inject (write) fuzz target, each round-tripping Extract → mutate → Inject → Extract and asserting the library never panics on untrusted input.

Run any fuzz target directly with the Go toolchain. Substitute the target name and package path as needed:

go test -fuzz=FuzzParseEXIF -fuzztime=60s ./exif/...
go test -fuzz=FuzzJPEGExtract -fuzztime=60s ./format/jpeg/...
go test -fuzz=FuzzJPEGInject -fuzztime=60s ./format/jpeg/...
go test -fuzz=FuzzCR3Inject -fuzztime=60s ./format/raw/cr3/...

The -fuzztime flag controls how long the fuzzer runs. Crash-inducing inputs are written to testdata/fuzz/<Target>/ within the relevant package directory and replayed automatically on all subsequent go test runs.

Vulnerabilities that are reachable only from trusted, locally-provided input (e.g., a developer calling an internal API with hand-crafted data) will be treated as bugs rather than security issues unless there is a realistic exploit path.