WordPress security does not stop at the dashboard

WordPress security does not stop at WordPress.

That is the practical lesson from a critical vulnerability in libheif, a system library used to process HEIC and HEIF images on some web servers.

On September 18, 2026, Wordfence published its investigation into the libheif vulnerability. The research found that a crafted image could trigger a heap buffer overflow when an affected build decoded it. On one specific WordPress deployment, the researchers demonstrated protected file disclosure and code execution.

The upstream libheif project had already released version 1.23.3 as a security update on September 1. Its advisory marks versions 1.18.0 through 1.23.2 as affected and identifies 1.23.3 as the patched version. The maintainer rated the issue critical and advised users to upgrade.

This is not evidence that every WordPress site can be compromised by an image upload. Exposure depends on the server configuration, the installed libheif build and who can upload files.

It is still consequential for small and medium businesses because the vulnerable component may not appear anywhere in the WordPress dashboard. There is no ordinary plugin update that fixes it. The relevant update may need to come from a hosting provider, an operating system package or a rebuilt container image.

The business lesson is larger than one library.

A website care process that checks only WordPress core, themes and plugins can miss part of the system carrying the business.

What changed

WordPress does not decode every uploaded image by itself.

On some servers, WordPress passes an image to the PHP Imagick extension. Imagick uses ImageMagick, which can then use libheif to decode HEIC or HEIF files. That creates a chain from a WordPress upload form to a system library installed below the application.

The upstream security advisory describes a flaw in libheif's uncompressed image decoder. A specially constructed file can cause attacker controlled data to be written outside an allocated memory buffer. The researchers confirmed the underlying fault across different builds, then demonstrated file disclosure and command execution against one exact WordPress server configuration.

The limits matter.

Wordfence says the normal WordPress image processing path is exposed only when several conditions are present together:

• PHP is using Imagick;
• ImageMagick has HEIF support;
• libheif is within the affected version range;
• libheif was built with the vulnerable uncompressed codec enabled.

The attack also needs a route for the crafted file to reach image processing. On a standard WordPress installation, the Author role is the first built in role allowed to upload media. A plugin or custom form can create a lower privilege or public upload route, which changes the risk.

This is why a simple version check is not enough.

Two servers can report the same libheif version and have different exposure because their packages were built with different options. A Linux distribution may also keep an older package version while backporting the security fix. The correct question is not merely, "Which number is installed?" It is, "Is this exact package and configuration patched?"

Why this matters commercially

For many businesses, image uploads are ordinary operations.

Staff upload product photography, project images and article media. Customers attach photos to support forms, quote requests, warranty claims or marketplace listings. Agencies receive assets through client portals. Recruitment and membership sites may accept documents and profile images.

The technical path behind those uploads is usually invisible to the business.

That invisibility creates an ownership problem. A WordPress developer may maintain themes and plugins. A host may patch operating system packages. An agency may manage deployments. An internal employee may control forms and user roles. Each party can reasonably believe somebody else owns the layer where the risk sits.

When responsibility is unclear, an urgent security fix can turn into a chain of unanswered questions:

• Does this hosting account process HEIC files?
• Is the server package affected or patched by the vendor?
• Have PHP and web services restarted since the package update?
• Was a container rebuilt, or was the old image simply restarted?
• Which forms and user roles can send images into the processing path?
• Can the business disable HEIC uploads without disrupting a real workflow?

The commercial risk is not confined to a server.

A compromise can interrupt enquiries, sales, publishing or customer service. A rushed infrastructure change can also create downtime if nobody knows how the site is deployed. The useful response is therefore controlled verification, not alarm.

This is part of Website Growth & Care: understanding the live system, confirming ownership and keeping its application and infrastructure layers supportable.

Who is affected

The first group to review this is businesses whose WordPress sites accept HEIC or HEIF uploads from people they do not fully trust.

That can include customer support forms, quote request forms, property or vehicle listings, membership profiles, community publishing, recruitment workflows and ecommerce features that accept customer images.

The second group is sites with multiple authors, contributors or external content teams. The demonstrated WordPress scenario required upload capability, but it did not require full administrator access.

The third group is agencies and technical teams running WordPress in containers. Wordfence reported that the official WordPress Docker image configuration it tested was exposed. For container deployments, updating WordPress inside the running container does not replace a vulnerable system library in the base image. The image needs to be rebuilt from updated layers and redeployed.

Managed hosting customers are affected differently.

They may not have access to inspect or patch libheif directly. Their task is to get a clear answer from the provider and understand whether the provider has applied a fixed package, restarted the relevant services and checked the image processing configuration.

Sites that do not use Imagick, do not support HEIC processing or do not accept untrusted uploads may not be exposed through this WordPress path. That should be established through evidence rather than assumption.

What businesses should do

Start by identifying the upload surface.

List every place where staff, customers, members or partners can upload images. Include WordPress media, public forms, account areas, product submissions, support tools and custom integrations. Record which roles can use each route and whether uploaded files are processed into thumbnails or previews.

Then check whether WordPress reports HEIC support.

In the dashboard, go to Tools, then Site Health, then Info, then Media Handling. If HEIC is not listed among ImageMagick's supported formats, this particular WordPress Imagick path is not exposed. That check does not prove that no other software on the server uses libheif, but it narrows the WordPress question.

Then ask the infrastructure owner for verification.

For managed hosting, ask whether the environment uses an affected libheif build with the uncompressed codec enabled and whether the provider has applied its vendor's security fix. Ask when PHP and the relevant web services were restarted after the update.

For self managed servers, use the operating system vendor's security package rather than relying only on the upstream version number. Confirm whether the distribution has backported the fix.

For containers, pull an updated base image, rebuild without relying on a stale cached layer and redeploy. The official WordPress Docker documentation already advises regular rebuilds and redeployments so container based sites receive current security updates.

Then reduce exposure if patching cannot happen immediately.

If the business does not need HEIC or HEIF uploads, block those file types before they reach image processing. Wordfence identifies four WordPress upload extensions to consider: heic, heif, heics and heifs. That change should be tested against real forms and publishing workflows before production.

Finally, record the result.

Document who checked the host, what evidence was provided, whether HEIC processing is enabled, which upload routes exist, what was updated and whether any temporary restriction remains. The record is useful when the next system library advisory arrives or when the site moves to a new host.

Where technical judgement is required

The first judgement is deciding whether a site is actually exposed.

A scanner that sees an older libheif version may produce a false sense of certainty. The build option matters. Vendor backports matter. The path from an uploaded file to the vulnerable decoder matters. A good review connects all three instead of treating one version string as the answer.

The second judgement is deciding how to respond before a fix is confirmed.

Blocking HEIC may be easy for a brochure site that only needs JPEG, PNG and WebP. It may be disruptive for a field team or customer workflow built around iPhone photos. In that case, a temporary conversion service, a more isolated upload pipeline or a controlled alternative format may be more appropriate than silently rejecting customer files.

The third judgement is separating patching from incident response.

The published research demonstrates a credible impact, but it does not claim universal exploitation against every WordPress site. A business should not declare a compromise simply because the library was present. It should also not assume that applying the update proves nothing happened before the fix.

The need for log review, file inspection or deeper forensic work depends on the site's exposure, the sensitivity of its data, the upload routes available and any unusual activity. A focused Website Audit can help establish that scope without turning every advisory into an expensive incident.

The fourth judgement is architectural.

Sites that routinely process untrusted files deserve controls beyond one patch. Upload permissions should be narrow. File types should reflect a real business need. Uploaded files should not be able to execute as PHP. Image processing should run with limited permissions, and higher risk workflows may justify isolation from the main web application.

Those decisions sit across development, hosting and operations. A Fractional Technical Partner can help clarify who owns each layer and which controls are proportionate to the business, especially when several suppliers share responsibility.

The broader lesson

WordPress security conversations often centre on familiar objects: core, themes, plugins, users and passwords.

Those objects matter. They are not the whole system.

A WordPress site also depends on PHP, operating system packages, image libraries, databases, web servers, containers, CDNs and hosting controls. Some of those layers are visible to the website maintainer. Others are visible only to the host or infrastructure team.

The libheif issue crosses the editorial threshold because it exposes that boundary clearly. A normal image upload can reach code outside WordPress. The upstream fix exists, but the business may need someone other than its WordPress administrator to apply it. The vulnerable condition can depend on how a package was built, not only which version number appears on a screen.

Small businesses do not need to manage every system library themselves.

They do need to know who does.

A mature website care model should be able to answer four questions:

1. Which layers make up the live website?
2. Who monitors and patches each layer?
3. How is a fix verified rather than assumed?
4. What temporary control is available when the permanent fix is delayed?

That is the useful response to this vulnerability.

Update the affected library where required. Restrict unnecessary upload paths. Confirm the host's work. Then keep the ownership map, because the next consequential risk may also sit somewhere the WordPress dashboard cannot see.