The hidden attack layer nobody is talking about
by Steve Kamerman
A few years ago, researchers discovered a vulnerability in libpng — the open-source library that decodes PNG images on essentially every phone, browser, and computer on the internet. Chrome, Safari, Android, iOS — all of them. The vulnerability was so widespread that security researchers estimated it affected over a billion people.
Most people never knew it happened.
That’s not luck. That’s the nature of image-layer security: the attack surface is enormous, the exploits are invisible, and the consequences only show up if you happen to be unlucky.
The uncomfortable truth is that this problem isn’t solved. It is a growing one.
How the attack actually works
Understanding image security requires understanding one thing: the vulnerability is in the decoder, not the image format itself.
When someone uploads a product photo to your marketplace, a review image to your eCommerce site, a property photo to your real estate platform — or a photo to a university’s admissions portal, campus ID system, or student records system — software on your server decodes — reads and processes — that image. That decoding software has bugs. Those bugs are discovered, disclosed publicly, and then exploited. This is the standard lifecycle of every software vulnerability, and image-decoding libraries are no exception.
Here is how a targeted attack unfolds:
- A vulnerability is discovered in an image decoding library — libpng, libjpeg, ImageMagick, WebP, whatever your stack relies on.
- It receives a CVE number and gets publicly disclosed. At that moment, everyone on the internet — including malicious actors — knows exactly how to exploit it.
- An attacker identifies your platform and uploads an image containing an exploit payload.
- They find a way to get one of your employees to view that image — a formatting complaint, a support ticket, anything that gets someone to open the listing.
- Your employee’s browser or internal tooling decodes the image. If their software hasn’t been patched, the exploit runs.
- Remote code execution. The attacker now has access to that machine.
This is not theoretical. This is a documented, repeating pattern.
The DIY trap
Many platforms handle image processing themselves, often with ImageMagick — the most widely used open-source image processing library in the world.
ImageMagick has had over 190 critical vulnerabilities disclosed in the past two years.
Not minor issues. Critical ones. The kind that allow remote code execution, data exfiltration, and full system compromise.
If your engineering team runs ImageMagick, the question isn’t whether you are vulnerable. The question is whether you have been targeted yet, and whether you would even know if you had been.
The same is true if you are using a SaaS image platform. Cloudinary, Cloudflare Images, and every other cloud-based image service run on the same underlying open-source decoders — libpng, libjpeg, ImageMagick, libwebp. The difference is that you cannot see which versions they are running, whether they are patched, or what known vulnerabilities exist in their current build. Under the hood, their proprietary platform is a soup of the same open-source libraries everyone else uses. They just don’t tell you.
That is not a criticism. That is how all software works. The problem is the opacity.
The delivery side is not safe either
The attack surface is not limited to your upload pipeline. When a malicious image is already in your system — cached, already served — every user who visits the affected page decodes it. Their browser reads it. If their software is unpatched, they are exposed.
A CDN like CloudFront will either pass the malicious image through to your users intact, or crash trying to process it and take your images offline entirely. Either way, someone pays.
There is no antivirus for images. These attacks target image decoders specifically because they sit beneath the layer that security software typically monitors.
AI makes this exponentially worse
Here is the part that should genuinely concern you over the next 12 to 24 months.
AI systems can now discover software vulnerabilities at a scale and speed no human team can match. What previously required a skilled researcher and months of analysis can now be automated. The rate of vulnerability discovery — and therefore exploit development — is accelerating.
At the same time, AI-generated imagery has made it impossible to trust the provenance of the images flowing through your platform. A synthetic product image containing an exploit payload looks identical to a legitimate one. No visual signal indicates something is wrong.
The only defense is a system that:
- Decodes images safely, using libraries actively maintained and patched before deployment
- Re-encodes all output, producing clean derivative images that strip any exploit payload from the original
- Maintains a software bill of materials — a verifiable record of every library in your image pipeline, its version, and its current vulnerability status
- Provides provenance guarantees — cryptographic evidence of where an image came from and what changes were made to it
Without all four, you are relying on luck.
What “secure by default” actually means
At ImageEngine, we have a strict policy: Kube does not ship with known critical vulnerabilities. That is not a marketing claim — it is enforced in our release process. To ship a version with an unpatched critical vulnerability, even I, as the architect, would have to manually override the system I built.
More importantly, we are transparent about it. We document and audit every version of every library inside Kube. You can see what is running under the hood, whether it is patched, and what CVEs have been addressed. No competitor can offer that because their commercial interests — protecting their secret sauce — prevent them from showing you what is actually in their stack.
This is why containerized deployment fundamentally changes the security equation. When the software runs in your infrastructure, you can know what is in it. When it runs in someone else’s cloud, you cannot.
Built for teams that can’t afford to be reactive
Most image infrastructure decisions are made once and revisited only when something breaks — a surprise bill, a performance complaint, or a security incident. By then, switching is expensive, and staying is even more so.
Kube is designed for teams that want to get ahead of that curve, not react to it.
The SaaS model is heading in one direction. As cloud-native tooling matures, the maintenance burden that once justified SaaS pricing has largely disappeared. SaaS providers are running Kubernetes and automated pipelines — the same tools you can run yourself. Their underlying costs dropped years ago. Their prices haven’t kept pace. We’ve seen competing providers cut enterprise contracts by 75% — in one case, more than $100,000 a month — just to avoid losing an account. That’s not a sustainable business model. It’s a countdown. Teams that migrate to infrastructure they control before that pressure forces the issue will be in a much better position than those who wait.
You’re probably already paying for the infrastructure. Peak capacity planning means most enterprise environments are over-provisioned. That excess compute can absorb a full Kube deployment at no additional cost. The optimization savings — typically a 70–80% reduction in image payload — become net positive almost immediately.
The threat surface will only grow. AI is accelerating both the discovery of image decoder vulnerabilities and the creation of synthetic imagery that’s indistinguishable from authentic content. Organizations that build auditability and provenance into their image pipeline now will be ahead of what is rapidly becoming a compliance and security expectation, not just a best practice. The teams still relying on a SaaS provider’s opaque promise that “it’s handled” will be the ones scrambling when a CVE drops on a library they didn’t know was in their stack.
Deployment is not the obstacle it used to be. On Kubernetes, the full Kube stack deploys in five to ten minutes with a single Helm command. AWS, DigitalOcean, Google Cloud Platform, and Linode all support Kubernetes natively. OCI/Docker containers are available for environments that aren’t on Kubernetes. The complexity that historically made self-managed image infrastructure impractical no longer exists.
Futureproofing an image pipeline used to mean locking into the biggest SaaS provider and hoping they kept up. It now means owning the stack, knowing what’s in it, and patching and adapting without waiting for a vendor to decide your security concern is worth prioritizing.
The coming standard: content provenance
The image security conversation is expanding beyond decoder vulnerabilities into something broader: provenance.
The Coalition for Content Provenance and Authenticity (C2PA) — founded by Adobe, backed by Google, Microsoft, BBC, and others — has developed a technical standard for cryptographically signing images. When an image is created or significantly modified, it carries a verifiable record of its origin and transformation history. Anyone downstream can verify that record.
This matters for eCommerce platforms (was this product image real or synthetic?), news organizations (did this photo actually come from the claimed source?), marketplaces (did this property photo go through your legitimate pipeline?), and social platforms (is this user-generated content what it claims to be?).
We are building C2PA compatibility into Kube’s roadmap. We have also joined the Coalition as a contributing member.
Image governance — knowing what you are serving, where it came from, and whether it has been altered — is becoming a security requirement. Not an operational nice-to-have. A requirement.
The question to ask your current provider
“Can you tell me which version of libheif you are currently running, whether it has any known critical vulnerabilities, and what your process is for patching them?”
If they cannot answer with specifics, you are YOLOing your image security. That was a reasonable position in 2018. It is not a reasonable position in 2026.
What to do today
- Audit your image decoding stack.
Which libraries process uploads before they reach storage? What are their current CVE statuses? - Understand your re-encoding pipeline.
If user-uploaded images are stored and served without being decoded and re-encoded through a patched pipeline, your users are being served whatever was uploaded. - Ask your vendors for their software bill of materials.
If they cannot provide one, treat that as an answer. - Consider where your image processing runs.
SaaS platforms offer convenience; on-premises deployment offers auditability, control, and a cost structure that doesn’t turn against you at scale.
Image security is not a niche concern for enterprises with dedicated security teams. It is a foundational requirement for any platform that accepts image uploads from users.
The attack surface is real. The exploits are well-documented. The only question is whether you are patched before you are targeted.
ImageEngine Kube is a containerized image optimization engine built for organizations that need full control over their image pipeline and cost.