CVE-2025-54080 — exiv2
Fix: Exiv2/exiv2@e737332CVE-2025-54080 is a Out-of-bounds Read vulnerability in exiv2. No vendor fix is recorded yet; mitigation options are listed below.
Exiv2 Segmentation Faults in Exiv2::EpsImage::writeMetadata() via crafted EPS file
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for CVE-2025-54080.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
exiv2Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Impact
An out-of-bounds read was found in Exiv2 versions v0.28.5 and earlier. Exiv2 is a command-line utility and C++ library for reading, writing, deleting, and modifying the metadata of image files. The out-of-bounds read is triggered when Exiv2 is used to write metadata into a crafted image file. An attacker could potentially exploit the vulnerability to cause a denial of service by crashing Exiv2, if they can trick the victim into running Exiv2 on a crafted image file.
Note that this bug is only triggered when writing the metadata, which is a less frequently used Exiv2 operation than reading the metadata. For example, to trigger the bug in the Exiv2 command-line application, you need to add an extra command-line argument such as delete.
Patches
The bug is fixed in version v0.28.6.
Credit
Thank you to @dragonArthurX for reporting this issue.
Details (from original report by @dragonArthurX )
Version: Tested on v0.28.5 (latest official release) Commit: 907169fa643c2c74c14fd4106e55eaeee3634d9f
Platform: Ubuntu 20.04.6 LTS (x86_64)
Build Steps:
git clone https://github.com/Exiv2/exiv2.git
cd exiv2
git checkout v0.28.5
mkdir build-v0.28.5 && cd build-v0.28.5
cmake -DCMAKE_C_COMPILER=/fuzzer/afl-clang-fast -DCMAKE_CXX_COMPILER=/fuzzer/afl-clang-fast++ -DCMAKE_C_FLAGS="-g -fsanitize=address" -DCMAKE_CXX_FLAGS="-g -fsanitize=address" -DBUILD_SHARED_LIBS=OFF ../
Command line to reproduce:
/home/exiv2/build/bin/exiv2 -d a -f /home/poc
Crash Output:
AddressSanitizer:DEADLYSIGNAL
================================================================ =
==376531==ERROR: AddressSanitizer: SEGV on unknown address 0x7fd92236b0e7 (pc 0x7fd82314dcd2 bp 0x7ffd540ceba0 sp 0x7ffd540ce358 T0)
==376531==The signal is caused by a READ memory access.
#0 0x7fd82314dcd2 /build/glibc-B3wQXB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:383
#1 0x4ed131 in __asan_memcpy (/home/exiv2/build-v0.28.5/bin/exiv2+0x4ed131)
#2 0x6184b1 in Exiv2::MemIo::write(unsigned char const*, unsigned long) /home/exiv2/src/basicio.cpp:704:5
#3 0xad336d in (anonymous namespace)::writeTemp(Exiv2::BasicIo&, unsigned char const*, unsigned long) /home/exiv2/src/epsimage.cpp:90:14
#4 0xac3a07 in (anonymous namespace)::readWriteEpsMetadata(Exiv2::BasicIo&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::vector<Exiv2::NativePreview, std::allocator<Exiv2::NativePreview> >&, bool) /home/exiv2/src/epsimage.cpp:1009:7
#5 0xad1175 in Exiv2::EpsImage::writeMetadata() /home/exiv2/src/epsimage.cpp:1103:3
#6 0x5d2383 in Action::Erase::run(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) /home/exiv2/app/actions.cpp:713:14
#7 0x522d02 in main /home/exiv2/app/exiv2.cpp:177:25
#8 0x7fd8230b6082 in __libc_start_main /build/glibc-B3wQXB/glibc-2.31/csu/../csu/libc-start.c:308:16
#9 0x4714dd in _start (/home/exiv2/build-v0.28.5/bin/exiv2+0x4714dd)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /build/glibc-B3wQXB/glibc-2.31/string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:383
==376531==ABORTING
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | exiv2 | all versions | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for exiv2, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Remediation status
No patched version of exiv2 has shipped for CVE-2025-54080 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Mitigate without a patch
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2025-54080 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2025-54080. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
Frequently Asked Questions
Is CVE-2025-54080 in your dependencies?
O3 Security finds CVE-2025-54080 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.