CVE-2026-56289

What it actually does

GNU patch improperly validates line offsets in unified-diff hunk headers. A malicious patch can declare an extremely large target/source line number, causing patch to spend excessive time searching for that location and enter an effectively non-terminating CPU-bound loop. The impact is denial of service of the patch process and any parent automation that waits on it, such as build, packaging, update, or CI workflows. The flaw does not provide code execution, privilege escalation, or data disclosure by itself.

Why it matters to the business

Organizations that process untrusted or externally supplied patch files can experience stalled builds, blocked release pipelines, failed package maintenance jobs, and resource exhaustion on developer or build systems. Because the issue requires a patch file to be supplied and processed, exposure is highest in automated workflows that ingest patches from contributors, issue trackers, email, source repositories, or package build systems. EPSS is currently low and it is not listed in CISA KEV, so broad exploitation is not indicated, but remediation is still prudent for systems that automatically apply third-party diffs.

How an attack unfolds

An attacker prepares a unified-diff file with a hunk header that contains an extremely large line offset. The attacker then gets the file processed by GNU patch, either by sending it to a user, submitting it to a project workflow, attaching it to a bug report, or placing it where automated build or packaging tooling applies patches. When patch parses the hunk and attempts to locate the declared line position, insufficient validation allows the process to loop for an excessive period while consuming CPU. The immediate result is a hung patch invocation; dependent automation may remain blocked until the process is killed or the job times out.

How to fix it

Upgrade GNU patch to a release or vendor package that includes the fix for commit faba04ef4f2b410257f76c1b9dc85e350929c4b9. If no packaged fixed version is available, apply the upstream patch through the operating system or distribution vendor, or rebuild GNU patch from a trusted source that contains the fix. As interim mitigation, do not automatically apply untrusted patch files; enforce job-level timeouts around patch invocations; run patch processing in resource-limited sandboxes; cap CPU time with mechanisms such as ulimit, cgroups, containers, or CI job timeouts; and reject unusually large hunk offsets before invoking patch.

How to confirm the fix worked

Confirm the installed GNU patch package version is at or above the fixed vendor release, or verify the source package contains upstream commit faba04ef4f2b410257f76c1b9dc85e350929c4b9. Review SBOMs and build images for embedded GNU patch binaries. In controlled test environments only, validate that patch invocations against malformed unified diffs with extreme hunk line numbers terminate quickly or fail safely rather than consuming CPU indefinitely. Confirm CI, build, and packaging jobs have maximum runtime and CPU limits so a single patch process cannot block workers indefinitely.

Typical attack path

1. Identify a workflow, developer, or automation path that applies unified-diff patch files using GNU patch.
2. Craft a patch file whose hunk header specifies an extremely large line number or offset.
3. Deliver or submit the patch file through a channel likely to be processed, such as a source contribution, build recipe, package patch set, ticket attachment, or email.
4. Wait for a user or automated job to run GNU patch against the malicious file.
5. Cause the patch process to consume excessive CPU and fail to complete, delaying or blocking the parent workflow.

How to detect it

To assess prior exploitation, review process accounting, EDR telemetry, CI/build logs, package build logs, shell histories, and job orchestrator events for GNU patch processes that ran abnormally long, consumed high CPU, or were manually killed after processing a patch file. Correlate hung or timed-out jobs with recently introduced .patch or .diff files, contributor submissions, ticket attachments, package recipes, or source changes. Search patch artifacts for unified-diff hunk headers containing extremely large line numbers. Relevant evidence includes repeated or long-duration executions of the patch binary, build job timeouts during patch application, parent processes waiting on patch, termination events such as SIGKILL/SIGTERM, and newly added patch files with unusually large numeric hunk offsets. There are no known public threat actors or ransomware campaigns associated with this vulnerability based on the provided data.

• process_name=patch
• command_line contains "patch" and (".patch" or ".diff")
• @@ -[0-9]{10,}
• @@ -[0-9]+,[0-9]+ \+[0-9]{10,}
• @@ -[0-9]{10,},[0-9]+ \+[0-9]+
• SIGKILL patch
• SIGTERM patch
• timeout: failed to run command 'patch'
• Terminated patch
• Killed patch
• patch command timed out
• faba04ef4f2b410257f76c1b9dc85e350929c4b9

What your security team should do

• Inventory systems, build images, developer workstations, package build environments, and CI runners that include GNU patch.
• Prioritize remediation for any workflow that applies patches from external contributors, package sources, issue attachments, mailing lists, or other semi-trusted channels.
• Upgrade GNU patch through the operating system or distribution package manager when a fixed package is available; otherwise track and apply the upstream fix commit through trusted channels.
• Add resource limits and execution timeouts to automated patch application jobs to reduce operational impact from malformed inputs.
• Introduce pre-processing checks that reject unified-diff hunk headers containing unrealistic line numbers or offsets before invoking patch.
• Monitor build and CI telemetry for long-running or CPU-bound patch processes, especially following processing of newly submitted patch files.
• Because this is not currently KEV-listed and has low EPSS, treat it as a hygiene and pipeline-resilience issue unless untrusted patch ingestion is common or business-critical.