A booby-trapped GIMP save-file that only detonates when a designer double-clicks it
CVE-2025-48798 is a use-after-free in xcf_load_image() inside app/xcf/xcf-load.c, the loader for GIMP's native XCF file format. A malformed XCF can free an object and then have GIMP dereference the stale pointer, giving the attacker a shot at arbitrary code execution in the context of the user running GIMP. It affects GIMP 2.10.x through 2.10.38 and was fixed in 2.10.40 upstream, with backports in Debian bookworm (2.10.34-1+deb12u3), Debian bullseye LTS (2.10.22-4+deb11u3), SUSE (2.10.30-150400.3.20.1), and Mageia.
The vendor HIGH (7.3) rating is technically defensible per the CVSS vector (AV:L/AC:L/PR:L/UI:R) but overstates operational risk. XCF is a proprietary GIMP-only container; users almost never receive .xcf files from untrusted sources the way they do PDFs, Office docs, or PNGs. Delivery friction is high, the blast radius is a single desktop user account, and there is no server-side or headless GIMP footprint in a typical enterprise. This is a MEDIUM for practical purposes.
4 steps from start to impact.
Craft a malicious XCF
xcf_load_image, using techniques similar to the ZDI-disclosed GIMP XCF fuzz corpus. Heap grooming is required to convert the UAF into a controllable primitive. Reliable RCE on modern glibc with ASLR/relro is non-trivial but demonstrated by multiple prior GIMP XCF bugs.- knowledge of GIMP heap layout on target build
- target running vulnerable 2.10.x
- ASLR + full RELRO on most modern Linux builds
- distro hardening flags (
-D_FORTIFY_SOURCE=2, stack canaries)
Deliver the file to a GIMP user
.xcf extension is unusual outside creative/design teams, so credible pretexts require targeting: game studios, VFX shops, marketing/design departments, open-source contributors.- target has GIMP installed and used regularly
- attacker knows the user handles XCF assets
.xcfis not a routine attachment — high suspicion- secure email gateways (Proofpoint, Mimecast) may not detonate but will flag unusual attachment types
- browser download warnings on unknown MIME
User opens the XCF in GIMP
UI:R is a hard requirement. Preview handlers do not invoke the full XCF parser. There is no auto-open, drive-by, or headless server pathway in a default enterprise environment.- user actively opens the file in GIMP
- Users rarely open unsolicited XCFs
- no thumbnailer RCE path in the referenced sink
gimp opening a file from Downloads/ or a mail-quarantine path.UAF → code execution as the desktop user
~/.aws), or C2 beacon.- successful heap primitive → RIP control
- no MAC policy (SELinux/AppArmor) confining GIMP
- SELinux
user_home_ton RHEL/Fedora limits post-exploit reach - EDR behavioral rules on
gimpspawning shells - no default AppArmor profile on Debian/Ubuntu limits this friction
bash, curl, python, or making outbound C2 — high-confidence detection.The supporting signals.
| In-the-wild exploitation | None observed. No public campaigns, no incident-response reporting. |
|---|---|
| KEV listed | No. |
| EPSS | 0.0017 (~0.17%, well below action threshold) |
| Public PoC | No weaponized PoC public as of assessment; ZDI-style crash corpuses exist for prior GIMP XCF bugs and could be adapted. |
| CVSS vector | CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H — Local, User Interaction Required, low-priv attacker |
| CWE | CWE-416 Use-After-Free in xcf_load_image (app/xcf/xcf-load.c) |
| Affected versions | GIMP 2.10.x ≤ 2.10.38; GIMP 3.0 branch also patched via parallel commits |
| Fixed versions | Upstream 2.10.40; Debian bookworm 2.10.34-1+deb12u3; Debian bullseye LTS 2.10.22-4+deb11u3; SUSE 2.10.30-150400.3.20.1; Mageia MGASA-2026-0012; RHEL via access.redhat.com/security/cve/cve-2025-48798 |
| Disclosure | 2025-05-27, credited via ZDI/Trend Micro pipeline (bundled with sibling XCF UAF/double-free CVEs) |
| Exposure population | No internet-facing exposure — desktop app. Enterprise install base concentrated in design, marketing, open-source contributor endpoints. Not on servers. |
noisgate verdict.
This is a client-side file-format parser bug in a desktop-only application, requiring the victim to explicitly open a proprietary GIMP-native XCF file — a format that virtually never arrives from untrusted sources in normal workflows. The single most decisive factor is delivery friction against a niche file type combined with blast radius capped at one non-privileged desktop user; there is no server, service, or fleet-scale role GIMP plays.
Why this verdict
- Local + UI:R gate: The CVSS vector itself concedes this needs a user to double-click a hand-crafted XCF. No wormability, no drive-by, no server component.
- Proprietary file format: XCF is GIMP-only. Users don't routinely email XCFs — unlike PDFs or Office docs, an unsolicited
.xcfattachment is inherently suspicious and easy to policy-block at the mail gateway. - Blast radius = one user account: Code executes as the invoking user, no service/daemon context. Role multiplier: GIMP is 100% workstation software — there is no domain controller, CI runner, hypervisor, or identity-provider role for this component. The role floor is (a) low-value desktop, so no HIGH/CRITICAL role floor applies.
- No KEV, EPSS 0.0017: Zero real-world exploitation signal seven months post-disclosure.
- Modern mitigations bite hard: ASLR, RELRO, FORTIFY_SOURCE, EDR behavioral detection on
gimp → shellall substantially raise exploit cost. - Patch is trivial: Distro package update, no downtime, no dependency risk — the 365-day remediation window is more than adequate.
Why not higher?
HIGH would imply a chain that either bypasses user interaction, hits a server role, or has active exploitation. None of those apply: UI:R is mandatory, GIMP has no server surface, EPSS is near-zero, and KEV does not list it. The vendor's 7.3 mechanically follows CVSS scoring but ignores that XCF is not a plausible delivery vector at enterprise scale.
Why not lower?
LOW/IGNORE is wrong because this is a remote-code-execution primitive on a still-widely-installed desktop tool. Targeted actors going after design shops, game studios, or high-value open-source contributors have a credible use case for this. Backlog-only treatment (LOW) would ignore the credential-theft-from-workstation follow-on.
What to do — in priority order.
- Block
.xcfattachments at the email gateway — XCF has no legitimate business use in email for 95%+ of organizations. Add.xcfto Proofpoint/Mimecast/M365 mail-flow attachment blocklists. No mitigation SLA at MEDIUM — implement opportunistically within the 365-day remediation window. - Push GIMP patch via existing endpoint software management — Roll upstream 2.10.40 or the distro-backported package (Debian
2.10.34-1+deb12u3, SUSE2.10.30-150400.3.20.1) through Intune/Jamf/Ansible/unattended-upgrades. Standard 365-day remediation SLA — bundle with next quarterly workstation image refresh. - EDR rule: alert on
gimpspawning shells or network utilities — Detect post-exploitation with a behavioral rule that fires when thegimpprocess creates a childbash,sh,powershell,curl,wget,nc,python. This catches this CVE and any future GIMP parser bug. - Restrict GIMP install to roles that need it — Design, marketing, and engineering-artwork users typically. Remove GIMP from finance/HR/exec workstations via app-inventory tooling — you don't need to patch what isn't installed.
- Perimeter firewalls / WAF: No network-facing service — irrelevant.
- MFA: Post-file-open, MFA offers no help against local code execution.
- Disabling macros: XCF is not an Office format; there is no macro toggle.
- Antivirus signature scanning: Weaponized XCFs will trivially evade signature detection; behavioral EDR is the only useful layer.
Crowdsourced verification payload.
Run on each Linux/macOS workstation (or push via your config-management tool) as any user. Invoke: bash check-gimp-cve-2025-48798.sh. No root required — reads GIMP version from the binary and compares against the fixed threshold.
#!/usr/bin/env bash
# check-gimp-cve-2025-48798.sh
# Detects vulnerable GIMP installations for CVE-2025-48798 (XCF UAF)
# Exit codes: 0 PATCHED, 1 VULNERABLE, 2 UNKNOWN
set -u
FIXED_UPSTREAM="2.10.40"
FIXED_DEB12="2.10.34-1+deb12u3"
FIXED_DEB11="2.10.22-4+deb11u3"
ver_ge() {
# returns 0 if $1 >= $2 using dpkg --compare-versions if available, else sort -V
if command -v dpkg >/dev/null 2>&1; then
dpkg --compare-versions "$1" ge "$2"
return $?
fi
[ "$(printf '%s\n%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]
}
GIMP_BIN="$(command -v gimp || command -v gimp-2.10 || true)"
if [ -z "$GIMP_BIN" ]; then
echo "PATCHED: GIMP not installed"
exit 0
fi
# Prefer distro package version when available (captures backports)
PKG_VER=""
if command -v dpkg-query >/dev/null 2>&1; then
PKG_VER="$(dpkg-query -W -f='${Version}' gimp 2>/dev/null || true)"
elif command -v rpm >/dev/null 2>&1; then
PKG_VER="$(rpm -q --qf '%{VERSION}-%{RELEASE}' gimp 2>/dev/null || true)"
fi
UPSTREAM_VER="$($GIMP_BIN --version 2>/dev/null | awk '{print $NF}')"
if [ -z "$UPSTREAM_VER" ]; then
echo "UNKNOWN: could not determine GIMP version"
exit 2
fi
echo "Detected GIMP upstream version: $UPSTREAM_VER"
[ -n "$PKG_VER" ] && echo "Detected distro package version: $PKG_VER"
# Backport check for Debian bookworm / bullseye
if [ -n "$PKG_VER" ] && command -v dpkg >/dev/null 2>&1; then
if dpkg --compare-versions "$PKG_VER" ge "$FIXED_DEB12" 2>/dev/null; then
echo "PATCHED: distro-backport $PKG_VER >= $FIXED_DEB12"
exit 0
fi
if dpkg --compare-versions "$PKG_VER" ge "$FIXED_DEB11" 2>/dev/null; then
echo "PATCHED: distro-backport $PKG_VER >= $FIXED_DEB11"
exit 0
fi
fi
if ver_ge "$UPSTREAM_VER" "$FIXED_UPSTREAM"; then
echo "PATCHED: upstream $UPSTREAM_VER >= $FIXED_UPSTREAM"
exit 0
fi
echo "VULNERABLE: GIMP $UPSTREAM_VER is below fixed upstream $FIXED_UPSTREAM and no recognized backport detected"
exit 1
If you remember one thing.
.xcf to your email attachment blocklist and add an EDR rule for gimp spawning shells/network tools — since this is MEDIUM, per the noisgate mitigation SLA there is no formal mitigation deadline, so treat these as opportunistic wins to complete within the next patch cycle; (2) schedule the GIMP package update (upstream 2.10.40 or your distro backport) into the standard workstation patch train under the noisgate remediation SLA of ≤365 days — bundle it with the next quarterly base-image refresh. Do not rearrange this week's queue for this CVE unless you have design/VFX teams handling untrusted XCF assets, in which case bring them forward as a targeted 30-day rollout.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.