CVE-2026-56288

What it actually does

GNU patch can dereference a NULL pointer while parsing a specially crafted unified diff. The flaw is triggered by malformed handling of consecutive end-of-file newline markers, which can corrupt internal hunk state and cause patch to pass a NULL pointer to fwrite(). The expected result is process termination, not code execution, data theft, or privilege escalation.

Why it matters to the business

Systems and workflows that automatically or routinely apply patch files can be disrupted if a malicious or malformed diff is processed. The most likely consequence is denial of service in build pipelines, packaging workflows, source-code maintenance jobs, CI/CD tasks, or administrative scripts that rely on GNU patch. Current public exploitation likelihood appears low based on the low EPSS score, lack of KEV listing, and no known mature exploit, but the issue should still be addressed where patch files are accepted from untrusted or semi-trusted sources.

How an attack unfolds

An attacker prepares a unified-diff patch file containing consecutive end-of-file newline marker patterns that trigger incorrect hunk handling inside GNU patch. The attacker then convinces a user or automated process to apply the patch, for example through a submitted source patch, package contribution, downloaded diff, email attachment, or CI job that applies external patches. When GNU patch processes the crafted file, internal hunk data becomes inconsistent and a NULL pointer is passed into fwrite(), causing the utility to crash. Exploitation requires local execution of patch against attacker-controlled input and user or automation interaction; it is primarily a reliability and availability issue.

How to fix it

Upgrade GNU patch to a version that includes upstream fix commit e6d6a4e021660679d7fc9150f981d4920f722313, or install the security update provided by the operating system or distribution vendor. Because fixed package versions were not provided in the input, use vendor advisories for exact package names and versions. As interim mitigation, avoid applying patch files from untrusted sources, validate patches before use, run patch application in isolated build environments, and ensure CI/CD jobs fail safely without disrupting broader operations.

How to confirm the fix worked

Confirm the installed GNU patch package includes the upstream fix commit e6d6a4e021660679d7fc9150f981d4920f722313 or a vendor backport for this issue. Check the installed version and package changelog using the platform package manager, then compare against the vendor security advisory. Validate that automated build, packaging, or source-management workflows use the updated binary. Where safe and authorized, test with a known malformed proof-of-concept diff in a non-production sandbox to confirm patch no longer crashes.

Typical attack path

1. Create a malicious unified-diff patch file with malformed consecutive end-of-file newline markers.
2. Deliver the file to a target workflow or user that applies external patch files.
3. Cause GNU patch to process the crafted diff using normal patch application commands.
4. Trigger corruption of internal hunk parsing state.
5. Crash the patch process through a NULL pointer dereference, interrupting the dependent workflow or job.

How to detect it

Look for evidence that GNU patch crashed while processing a unified-diff file, especially shortly after a newly submitted, downloaded, or emailed patch was applied. Useful sources include CI/CD job logs, build logs, package-maintainer automation logs, developer workstation shell history, systemd-coredump or apport crash records, kernel logs, endpoint detection process telemetry, and file-ingestion records for patch or diff files. Investigate repeated failures involving patch, segmentation faults, core dumps, or fwrite-related crashes. Correlate crash timing with recently received .patch or .diff files and repository events such as pull requests, package build submissions, or automated patch application jobs. Because the vulnerability does not provide a stable network indicator and exploitation is input-file based, detection is primarily host and workflow-log based.

• patch: Segmentation fault
• Segmentation fault (core dumped) patch
• segfault at 0 ip
• comm="patch"
• process name: patch
• executable: /usr/bin/patch
• systemd-coredump
• Process *patch* dumped core
• apport.*patch.*crash
• core.patch
• fwrite
• *.patch
• *.diff
• \ No newline at end of file

What your security team should do

• Inventory systems, build images, containers, developer workstations, and CI/CD runners that include GNU patch.
• Prioritize updates for systems that apply externally supplied patches or process source contributions automatically.
• Install distribution or vendor security updates containing upstream fix commit e6d6a4e021660679d7fc9150f981d4920f722313.
• Restrict automated application of untrusted patch files and require review or sandboxing before processing.
• Add monitoring for repeated patch process crashes in CI/CD, build, and packaging logs.
• Ensure build jobs and automation isolate patch failures so a single malformed diff cannot disrupt shared infrastructure.