Commit 184d1d5f for libheif
commit 184d1d5f1ba84462dbef2583dd7a8268017748f3
Author: Dirk Farin <dirk.farin@gmail.com>
Date: Tue Aug 25 20:06:53 2026 +0200
add SECURITY.md and funding.json
diff --git a/.github/FUNDING.yml b/.github/FUNDING.yml
index f12d8c89..1d6fc157 100644
--- a/.github/FUNDING.yml
+++ b/.github/FUNDING.yml
@@ -10,4 +10,4 @@ liberapay: # Replace with a single Liberapay username
issuehunt: # Replace with a single IssueHunt username
otechie: # Replace with a single Otechie username
lfx_crowdfunding: # Replace with a single LFX Crowdfunding project-name e.g., cloud-foundry
-custom: # Replace with up to 4 custom sponsorship URLs e.g., ['link1', 'link2']
+custom: ['https://github.com/strukturag/libheif#commercial-support']
diff --git a/README.md b/README.md
index 36bf02d8..a6dc98ea 100644
--- a/README.md
+++ b/README.md
@@ -15,6 +15,11 @@ For AVIF, libaom, dav1d, svt-av1, or rav1e are used as codecs.
libheif can be built with a subset of the supported codecs to keep the size and the number of dependencies low.
Alternatively, the libheif codecs can also be built as separate plugins that can be installed and loaded dynamically when used.
+> **Project status (August 2026).** libheif and libde265 are maintained by a single independent developer with almost
+> no recurring funding, while 37 security advisories had to be investigated, fixed and released in 2026 alone.
+> If libheif is part of your product or service, please read [Funding](#funding) and [Commercial support](#commercial-support).
+> Security issues are reported as described in [SECURITY.md](SECURITY.md).
+
## Supported features
libheif has support for:
@@ -313,6 +318,13 @@ When using `heif-dec`, there is the option to switch off security limits with `-
In case a third-party software is using libheif, but does not give you a way to switch off the limits, you can set an environment variable `LIBHEIF_SECURITY_LIMITS=off` to switch it off globally.
Clearly, only do this if you know what you are doing and you are sure not to process malicious files.
+### Reporting security issues
+
+Please report vulnerabilities through
+[GitHub private vulnerability reporting](https://github.com/strukturag/libheif/security/advisories/new),
+not in public issues. [SECURITY.md](SECURITY.md) describes what a report must contain, what is in scope,
+which versions receive fixes, and how fixes are released.
+
## Encoder benchmark
A current benchmark of the AVIF encoders (as of 14 Oct 2022) can be found on the Wiki page
@@ -388,14 +400,20 @@ to update the gdk-pixbuf loader database.
## Software using libheif
+libheif is the HEIF/AVIF implementation behind most open-source image software. Because ImageMagick, libvips,
+GDAL and the desktop image loaders depend on it, it is also used indirectly by a large number of web services,
+content management systems and image processing pipelines built on these libraries.
+
* [GIMP](https://www.gimp.org/)
* [Krita](https://krita.org)
* [ImageMagick](https://imagemagick.org/)
* [GraphicsMagick](http://www.graphicsmagick.org/)
* [darktable](https://www.darktable.org)
* [digiKam 7.0.0](https://www.digikam.org/)
-* [libvips](https://github.com/libvips/libvips)
+* [libvips](https://github.com/libvips/libvips) and [sharp](https://sharp.pixelplumbing.com/) (Node.js)
+* [pillow-heif](https://pypi.org/project/pillow-heif/) (Python / Pillow)
* [kImageFormats](https://api.kde.org/frameworks/kimageformats/html/index.html)
+* GNOME desktop (through the gdk-pixbuf loader included in libheif)
* [libGD](https://libgd.github.io/)
* [Kodi HEIF image decoder plugin](https://kodi.wiki/view/Add-on:HEIF_image_decoder)
* [bimg](https://github.com/h2non/bimg)
@@ -407,12 +425,56 @@ to update the gdk-pixbuf loader database.
[](https://repology.org/project/libheif/versions)
-## Sponsors
+## Funding
+
+libheif and libde265 are developed and maintained by me, Dirk Farin, as an independent developer.
+The libraries are used by practically every open-source application and service that handles HEIC or AVIF
+files (see [Software using libheif](#software-using-libheif)), but the maintenance work is almost entirely unfunded.
+
+From January to August 2026, 37 security advisories were published for libheif, most of them found with
+automated tools by organizations that use libheif in their products, and six releases were made mainly to ship
+security fixes. Each fix means reproducing, fixing, testing, fuzzing and releasing, currently done in evenings and
+on weekends. Details are in [SECURITY.md](SECURITY.md).
+
+This is not a temporary situation. HEIF is built on a very flexible container format with wide value ranges and many
+loosely specified features, so the space of feature combinations that has to be validated is huge, and improved automated
+vulnerability discovery keeps finding new corners of it.
+[SECURITY.md](SECURITY.md#why-heif-files-are-hard-to-parse-safely) explains this in more detail.
+
+Recurring funding is what allows this work to happen during regular working hours.
+If libheif is part of your product or service, please consider one of these options:
+
+* **[GitHub Sponsors](https://github.com/sponsors/farindk)**, monthly or one-time. There are tiers for individuals,
+ small companies and larger commercial users. Organizations can pay by invoice through GitHub.
+* **[Commercial support](#commercial-support)** if you need pre-notification of security advisories, a direct contact,
+ or dedicated engineering time.
+* **Funding specific work.** New features, hardening of a subsystem your product relies on, or codec integrations can be
+ sponsored as scoped one-time projects. Several features of libheif were developed this way.
+
+A machine-readable description of the funding needs is in [funding.json](funding.json).
+
+### Commercial support
+
+For organizations that depend on libheif or libde265, commercial support is available directly from the author.
+Invoicing and vendor onboarding are possible. A support agreement can include:
+
+* pre-release notification of embargoed security advisories,
+* a direct contact for security and integration questions,
+* an agreed number of engineering hours per month (triage of your reports, review of your patches,
+ backports to the version you ship, integration help),
+* scoped projects (hardening, fuzzing, features, performance work).
+
+Contact: Dirk Farin <dirk.farin@gmail.com>
+
+Sponsorship through GitHub Sponsors funds the project as a whole and does not include these services.
+
+### Sponsors
-Since I work as an independent developer, I need your support to be able to allocate time for libheif.
-You can [sponsor](https://github.com/sponsors/farindk) the development using the link in the right hand column.
+As of August 2026, the recurring sponsorship for libheif and libde265 amounts to **$41 per month**, against a goal of
+$5,000 per month, which would fund about two days per week of maintenance (see [funding.json](funding.json)).
+Thank you to everyone who sponsors the project.
-A big thank you goes to these major sponsors for supporting the development of libheif:
+Thank you also to these organizations, which funded the development of specific features in the past:
* AOMedia
* OGC (Open Geospatial Consortium)
diff --git a/SECURITY.md b/SECURITY.md
new file mode 100644
index 00000000..132f3d6f
--- /dev/null
+++ b/SECURITY.md
@@ -0,0 +1,152 @@
+# Security Policy
+
+libheif parses untrusted input files. Memory-safety bugs in the decoder are treated as
+security vulnerabilities and are fixed with priority. This document describes how to report
+them, what a useful report contains, and what you can expect from a project that is maintained
+by a single, largely unpaid developer.
+
+## Why HEIF files are hard to parse safely
+
+HEIF is built on the ISO base media file format (ISOBMFF), a generic container that is
+exceptionally hard to implement securely:
+
+* **Flexibility.** A file is a graph of boxes and items that reference each other: derived images
+ (grids, overlays, identity transforms), auxiliary images (alpha, depth), thumbnails, tiles,
+ metadata, sequences with sample tables, and properties attached to any of them. Almost every
+ feature can be combined with almost every other feature, references can be nested and shared,
+ and the decoder has to detect cycles, duplicated references and amplification through
+ reference chains, none of which the specification forbids explicitly.
+* **Wide value ranges.** Sizes, offsets, counts and dimensions are 32- or 64-bit fields with no
+ meaningful upper bounds in the specification. Every field has to be checked not only against
+ the file, but against every other field it must be consistent with: declared image size versus
+ coded size, transformations (`clap`, `irot`, `imir`) versus tile grids, sample tables (`stsz`,
+ `stsc`, `stts`, `stco`) versus each other and versus the file length, and so on. An integer
+ overflow in any of these consistency checks becomes a memory-safety bug.
+* **Vaguely defined features.** Many features are only loosely specified, or specify what a
+ valid file contains but not what a reader should do with an inconsistent one. Files produced
+ by real cameras and phones deviate from the specification in practice, so a decoder has to be
+ lenient enough to be useful and strict enough to be safe. The uncompressed codec
+ (ISO/IEC 23001-17) alone allows nearly arbitrary component layouts, interleaving modes, bit
+ depths, tilings and compression schemes.
+* **Multiple codecs behind one container.** The container makes claims (dimensions, chroma
+ format, bit depth, color information) that the embedded HEVC, AV1, JPEG, JPEG 2000 or VVC
+ bitstream may contradict. libheif has to reconcile both before any pixel buffer is touched.
+
+libheif validates all of this, is fuzzed continuously, and uses configurable security limits
+to bound memory and CPU use. Still, the number of feature combinations is large, and as
+automated vulnerability discovery has improved, the number of reports has grown accordingly
+(see [Maintenance capacity](#maintenance-capacity)).
+
+## Reporting a vulnerability
+
+Please do **not** open a public issue for security bugs.
+
+* Preferred: [GitHub private vulnerability reporting](https://github.com/strukturag/libheif/security/advisories/new).
+ This creates a private advisory in which the issue can be discussed and through which a CVE
+ is assigned when the fix is published.
+* Alternative: email dirk.farin@gmail.com with "libheif security" in the subject line.
+
+You will normally receive an acknowledgement within a few business days. Reports are handled
+in the evenings and on weekends, see [Maintenance capacity](#maintenance-capacity).
+
+Vulnerabilities in [libde265](https://github.com/strukturag/libde265) are reported the same way
+in the libde265 repository. Bugs in other codec libraries (libaom, dav1d, x265, OpenJPEG, ...)
+should be reported to those projects.
+
+## What a report must contain
+
+Reports are only actionable when they can be reproduced. Please include:
+
+1. **A reproducer file**: the crafted HEIF/AVIF file, or a minimal program that triggers the
+ bug through the public API. A description of a suspected bug without a reproducer is
+ treated as a normal bug report, not as a security report.
+2. **The libheif version** (release tag or commit hash) and the build configuration
+ (CMake preset, codecs, and whether the security limits were changed).
+3. **The sanitizer output** (ASan/UBSan/MSan trace) or a debugger backtrace.
+4. **Your assessment of the impact**: crash only, out-of-bounds read, out-of-bounds write,
+ information disclosure, or resource exhaustion.
+5. One report per bug. If you believe that several bugs share a root cause, say so.
+
+Please check the [published advisories](https://github.com/strukturag/libheif/security/advisories)
+and test against the **latest release** before reporting.
+
+### Reports produced with AI tools
+
+Most reports received today are found with automated or AI-assisted tools. This is welcome,
+but these tools produce many false positives and duplicates, and every report costs real time
+to evaluate. Therefore:
+
+* A human must have verified the finding, reproduced it against the current release, and
+ written the report. Do not forward raw tool output.
+* The requirements above (reproducer file, version, sanitizer trace) apply strictly. Reports
+ without a working reproducer are closed without further investigation.
+* If your organization runs such tools against libheif at scale, please read
+ [Maintenance capacity](#maintenance-capacity) first.
+
+## Scope
+
+**In scope**: memory-safety violations, disclosure of uninitialized memory, and unbounded
+resource consumption that can be triggered by decoding or inspecting a crafted input file
+through the public API with the **default security limits**. This includes the image, sequence,
+metadata, region and uncompressed-codec (`unci`) code paths.
+
+**Handled as regular bugs** (lower priority, usually without an advisory):
+
+* Issues that only occur when the security limits have been disabled or raised
+ (`LIBHEIF_SECURITY_LIMITS=off`, `heif_security_limits`, `--disable-limits`). Disabling the
+ limits is documented as unsafe for untrusted input.
+* Issues that require the caller to violate the documented API contract, for example passing
+ inconsistent plane sizes to the encoder. These are still fixed, because libheif tries to
+ validate its inputs, but they are not vulnerabilities in libheif.
+* Issues in the example programs (`heif-enc`, `heif-dec`, `heif-info`, ...) that are not in the
+ library itself, for example in the JPEG/PNG/TIFF/Y4M input readers.
+* Issues in APIs that are only available with `ENABLE_EXPERIMENTAL_FEATURES=ON`. These APIs
+ are documented as unstable and must not be enabled in production builds.
+* High but bounded memory or CPU use for very large valid images. Use the security limits to
+ constrain this to what your application needs.
+
+libheif is continuously fuzzed on [OSS-Fuzz](https://google.github.io/oss-fuzz/). Crashes found
+by OSS-Fuzz are already known to the maintainer and do not need to be reported again.
+
+## Supported versions
+
+Only the latest release receives security fixes. There are no maintained long-term branches.
+Distributions that ship older versions have to backport fixes themselves. Advisories reference
+the fixing commits to make this easier.
+
+## Fix and disclosure process
+
+The following are targets, not commitments (see [Maintenance capacity](#maintenance-capacity)):
+
+| Severity | Typical handling |
+|----------|------------------|
+| Critical: out-of-bounds write or other likely code execution, reachable from a crafted file | Fix and release as soon as possible, usually within days. |
+| High: out-of-bounds read with information disclosure, unbounded memory or CPU consumption | Fix on the main branch promptly; released together with other pending fixes, usually within a few weeks. |
+| Medium / Low: crash, assertion failure, bounded denial of service | Fix on the main branch; included in the next regular release. |
+
+* Advisories are published on GitHub when the fixed release is available. CVE IDs are requested
+ through GitHub.
+* The default embargo is 90 days from the report, or shorter when the fix is released earlier.
+ Reporters are credited in the advisory unless they ask not to be.
+* Pre-release notification of embargoed advisories is available on request to downstream
+ distributors and to commercial support customers.
+* libheif does not run a bug bounty program and does not pay for reports.
+* Priority is decided by severity, not by who reports.
+
+## Maintenance capacity
+
+libheif and libde265 are maintained by one independent developer, largely in unpaid evenings
+and weekends. There is no security team.
+
+To make the workload concrete: from January to August 2026, 37 security advisories were
+published for libheif (3 rated critical, 13 high), and six releases were made mainly to ship
+security fixes. Most of the 2026 reports were found with automated or AI-assisted tools,
+often run by organizations that use libheif in their products.
+Reproducing, fixing, testing, fuzzing and releasing each fix takes hours to days.
+
+The response times above are therefore best-effort. If your organization depends on libheif and
+needs response-time commitments, advisory pre-notification, or dedicated engineering time,
+please fund this work:
+
+* [GitHub Sponsors](https://github.com/sponsors/farindk) (organizations can pay by invoice), or
+* a commercial support agreement, see [Commercial support](README.md#commercial-support) in the README.
diff --git a/funding.json b/funding.json
new file mode 100644
index 00000000..d958235a
--- /dev/null
+++ b/funding.json
@@ -0,0 +1,101 @@
+{
+ "$schema": "https://fundingjson.org/schema/v1.0.0/funding.schema.json",
+ "version": "v1.0.0",
+ "entity": {
+ "type": "individual",
+ "role": "maintainer",
+ "name": "Dirk Farin",
+ "email": "dirk.farin@gmail.com",
+ "phone": "",
+ "description": "Author and sole maintainer of libheif (HEIF/AVIF file format library) and libde265 (H.265/HEVC decoder). These libraries are used by practically all open-source software that reads or writes HEIC and AVIF images, including ImageMagick, GIMP, libvips/sharp, Pillow, darktable, digiKam, GDAL and the GNOME and KDE desktops, and through these by a large number of web services and image pipelines. The work is currently almost entirely unfunded: in 2026 alone, 37 security advisories had to be investigated, fixed and released in unpaid evenings and weekends.",
+ "webpageUrl": {
+ "url": "https://github.com/farindk"
+ }
+ },
+ "projects": [
+ {
+ "guid": "libheif",
+ "name": "libheif",
+ "description": "ISO/IEC 23008-12 HEIF and AVIF file format decoder and encoder. Supports HEIC, AVIF, VVC, AVC, JPEG, JPEG 2000 and uncompressed (ISO/IEC 23001-17) codecs, image sequences, tiling, HDR, metadata and region annotations. Continuously fuzzed on OSS-Fuzz.",
+ "webpageUrl": {
+ "url": "https://github.com/strukturag/libheif"
+ },
+ "repositoryUrl": {
+ "url": "https://github.com/strukturag/libheif"
+ },
+ "licenses": ["spdx:LGPL-3.0-or-later"],
+ "tags": ["heif", "heic", "avif", "image", "codec", "c", "cpp", "security", "multimedia"]
+ },
+ {
+ "guid": "libde265",
+ "name": "libde265",
+ "description": "Open source H.265/HEVC video decoder, used by libheif as the default HEIC decoder.",
+ "webpageUrl": {
+ "url": "https://github.com/strukturag/libde265"
+ },
+ "repositoryUrl": {
+ "url": "https://github.com/strukturag/libde265"
+ },
+ "licenses": ["spdx:LGPL-3.0-or-later"],
+ "tags": ["hevc", "h265", "video", "codec", "c", "cpp", "multimedia"]
+ }
+ ],
+ "funding": {
+ "channels": [
+ {
+ "guid": "github-sponsors",
+ "type": "payment-provider",
+ "address": "https://github.com/sponsors/farindk",
+ "description": "GitHub Sponsors, monthly or one-time. Organizations can pay by invoice through GitHub."
+ },
+ {
+ "guid": "invoice",
+ "type": "bank",
+ "address": "",
+ "description": "Bank transfer against an invoice for commercial support agreements, sponsored features and grants. Contact dirk.farin@gmail.com."
+ }
+ ],
+ "plans": [
+ {
+ "guid": "maintenance",
+ "status": "active",
+ "name": "Sustained maintenance and security response",
+ "description": "Funds about two days per week of maintenance for libheif and libde265: triage and fixing of security reports, fuzzing, security releases, keeping up with the ISO/IEC 23008-12 specification, and platform/compiler support. This is the amount that would move security work from weekends into regular working hours.",
+ "amount": 5000,
+ "currency": "USD",
+ "frequency": "monthly",
+ "channels": ["github-sponsors", "invoice"]
+ },
+ {
+ "guid": "hardening-sprint",
+ "status": "active",
+ "name": "Security hardening sprint",
+ "description": "A scoped, one-time project: systematic hardening of one subsystem (box parser, image sequences, uncompressed codec, derived images), extension of the fuzzing corpus and harnesses, and a security release. Deliverables and scope are agreed in advance.",
+ "amount": 25000,
+ "currency": "USD",
+ "frequency": "one-time",
+ "channels": ["invoice", "github-sponsors"]
+ },
+ {
+ "guid": "feature",
+ "status": "active",
+ "name": "Sponsored feature development",
+ "description": "Development of a specific feature or codec integration that your product needs (for example hardware-accelerated codecs, new ISO/IEC 23008-12 amendments, GIMI/geospatial extensions). Priced per project.",
+ "amount": 0,
+ "currency": "USD",
+ "frequency": "other",
+ "channels": ["invoice"]
+ },
+ {
+ "guid": "any",
+ "status": "active",
+ "name": "Any amount",
+ "description": "Any recurring or one-time contribution helps to keep libheif and libde265 maintained.",
+ "amount": 0,
+ "currency": "USD",
+ "frequency": "other",
+ "channels": ["github-sponsors"]
+ }
+ ]
+ }
+}