A single photo file — the kind professional photographers routinely share with clients, editors, and colleagues — could be silently weaponized to leak the contents of your computer's memory to an attacker watching from anywhere on the internet.
Who's Affected and Why It Matters
This vulnerability lives inside the DNG Software Development Kit (SDK), a foundational piece of software built by Adobe that handles the reading and processing of Digital Negative (DNG) files — the raw, uncompressed image format used by millions of photographers worldwide. If you've ever shot in RAW format on a Canon, Leica, or Hasselblad camera, or processed images in Adobe Lightroom, Photoshop, or dozens of third-party apps like Darktable or RawTherapee, there's a very good chance your software touches this code.
The affected versions — DNG SDK 1.7.0 and earlier — are embedded across a sprawling ecosystem: desktop photo editors, cloud-based asset management platforms, media ingestion pipelines, and even mobile apps. There is no single vendor to patch; this is a library that countless developers have baked into their own products. That means the actual number of users at risk is almost certainly in the tens of millions globally, spanning hobbyist photographers to enterprise media workflows at news agencies and advertising studios.
What an Attacker Can Actually Do to You
Picture this: A freelance photographer receives what looks like a client's sample image in their inbox. They double-click it. Their photo editing software opens it without any drama — no warning, no crash, maybe a slightly sluggish load time. What they don't see is that the file was carefully crafted by an attacker to trigger a flaw deep inside the image-reading code. In the background, fragments of the computer's active memory — the working space where software temporarily stores everything it's doing — begin leaking outward. That memory could contain anything: session tokens that keep you logged into websites, fragments of documents you had open, passwords cached by a browser, encryption keys, or authentication credentials.
The attack works because the DNG-reading software trusts data embedded in the image file a little too much. When it tries to process certain fields in the file, it writes more data into a reserved memory bucket than that bucket was designed to hold. The overflow spills into adjacent memory regions the program was never supposed to touch — and in doing so, it can either expose what's stored there to the attacker, or cause the entire application to crash. The first outcome is a data leak. The second is a denial of service — your editing software or the server processing your uploads simply dies. For enterprise media pipelines ingesting thousands of images a day, repeated crashes could mean significant operational disruption.
Critically, the attacker doesn't need to be anywhere near you. They just need to get their poisoned DNG file in front of you — via email, a file-sharing platform, a stock photo site, or even a seemingly legitimate client delivery. The only action required from the victim is the most natural thing in the world: opening a photo.
The Technical Detail That Should Make Researchers Pay Attention
The vulnerability is classified as a heap-based buffer overflow (CWE-122), meaning the overflow occurs in the heap memory region — the dynamic memory space where applications store data at runtime. This is a particularly dangerous location for an overflow. Unlike stack-based overflows, heap overflows can be harder for automatic memory protections to catch, and they are frequently chained with secondary techniques to escalate from a simple crash into a full memory disclosure primitive. With a CVSS score of 7.1 (HIGH), this vulnerability sits just below the critical threshold — but its cross-platform reach and the passive, user-triggered nature of exploitation make it a priority target for anyone building a phishing or supply-chain attack chain.
Real-World Context: Who Found It and What We Know So Far
As of publication, no active exploitation has been confirmed in the wild. There are no known victim campaigns, no ransomware groups or nation-state actors publicly attributed to leveraging CVE-2025-64784, and no reported data breaches tied to this flaw. That is genuinely good news — but it carries a caveat that every security team knows well: the absence of confirmed exploitation does not mean exploitation isn't happening quietly. Memory disclosure vulnerabilities of this class are precisely the kind that sophisticated actors use without triggering alarms, because a successful attack may leave no visible trace on the victim's system.
The vulnerability was assigned under standard coordinated disclosure processes. Adobe's DNG SDK is open-source and widely mirrored, which means researchers — and adversaries — can inspect the underlying code to understand exactly where the flaw lives. The clock is ticking on that information asymmetry. Security teams managing media-heavy environments should treat this as an active threat horizon, not a future concern.
What You Should Do Right Now
Here are three specific, actionable steps — whether you're an individual photographer or an IT administrator managing a media workflow:
- Update to DNG SDK version 1.8.0 or later immediately. If you are a developer who has integrated the DNG SDK into your own application, check your dependency manifest right now and patch to the latest version. If you're an end user of software like Adobe Lightroom or Camera Raw, apply any pending updates — Adobe typically bundles SDK updates inside application patches. Check for updates in Help → Updates in any Adobe Creative Cloud application.
- Treat unexpected DNG files as untrusted — even from known contacts. Until you've confirmed your software is fully patched, apply the same skepticism you'd give an unexpected email attachment. If a client, colleague, or collaborator sends you a DNG file you weren't expecting, verify the send through a separate channel before opening it. This is especially critical for anyone running automated ingestion pipelines that process incoming image files without human review.
- Audit your stack for embedded DNG SDK dependencies. If you manage software products or internal tools that process DNG files, search your codebase and third-party libraries for any reference to DNG SDK 1.7.0 or earlier. Use software composition analysis (SCA) tools — open-source options include Syft and Grype — to scan your dependencies. Any application linked against the vulnerable library version needs to be rebuilt and redeployed, even if the application itself hasn't changed.
CVE: CVE-2025-64784 | CVSS: 7.1 (HIGH) | Affected versions: DNG SDK 1.7.0 and earlier | Platform: Cross-platform | Active exploitation: Not confirmed at time of publication