If you have found a security vulnerability in Exiv2, please follow these steps:

• Click this link to create a draft security advisory.
• Write a detailed description of the vulnerability in the draft advisory.
• Include all of the following details in your description of the vulnerability:
  • Exact version of Exiv2 that you tested. For example: commit 194bb65ac568a5435874c9d9d73b1c8a68e4edec
  • Platform used. For example: Ubuntu 22.04.3 LTS (x86_64)
  • Exact command used to build Exiv2. For example: mkdir build; cd build; cmake ..; make
  • Attach a copy of the image file that triggers the bug. For example: poc.jpg
  • Exact command line arguments that trigger the bug. For example: ./bin/exiv2 poc.jpg
  • Crash output (stdout + stderr).
  • The source location of the bug and/or any other information that you are able to provide about what the cause of the bug is.

The draft security advisory is private until we publish it, so it is a good place to discuss the details of the vulnerability privately.

To qualify as a security issue, the bug must be reproducible on an official release of Exiv2, via a realistic attack vector. That means it should be reproducible with a simple command like: exiv2 poc-file. And the reproduction steps need to cause something genuinely bad to happen, like an out-of-bounds memory write. We also always treat OSS-Fuzz crashes (see our OSS-Fuzz configuration for build instructions) as security issues.

Examples of issues that are not security issues:

• Bugs in the applications in the samples sub-directory. Those are demo applications that are not intended for production use.
• A bug that can only be triggered with a custom-written main() function.
• A bug that can only be triggered by an unrealistic command line, such as exiv2 <weird command line arguments generated by a Python script>.
• Performance issues, such as: "exiv2 <very large input file> runs slowly."
• Sub-optimal error messages. For example, exiv2 exits with the error message: "uncaught exception".

These are regular bugs, not security issues. Please create a public issue, not a security advisory.

Official releases are listed here (not including those labeled "pre-release"). Bugs that are only reproducible on the main branch or on a pre-release are not security issues and can be reported as regular issues.

Team Exiv2 does not back-port security (or any other fix) to earlier releases of the code. An engineer at SUSE has patched and fixed some security releases for Exiv2 v0.26 and Exiv2 v0.25 in branches 0.26 and 0.25. Exiv2 has provided several Dot Release for v0.27. Exiv2 has never issued a Security Release.

The version numbering scheme is explained below. The design includes provision for a security release. A Dot Release is an updated version of the library with security PRs and other changes. A Dot Release offers the same API as its parent. A Security Release is an existing release PLUS one or more security PRs. Nothing else is changed from it parent.

Users can register on GitHub.com to receive release notices for RC and GM Releases. Additionally, we inform users when we begin a project to create a new release on FaceBook (https://facebook.com/exiv2) and Discuss Pixls (https://discuss.pixls.us). The announcement of a new release project has a preliminary specification and schedule.

The list of Exiv2 vulnerabilities that were previously found and fixed can be found at https://github.com/Exiv2/exiv2/security/advisories.