CVE-2017-1000376

What it actually does

libffi prior to 3.1 on 32-bit x86 requests an executable stack, allowing local attackers to more easily achieve arbitrary code execution via stack-based memory corruption.

Why it matters to the business

Applications or systems that depend on affected libffi versions face elevated risk of local code execution leading to full host compromise, with downstream impact on any packages or workloads that transitively rely on libffi.

How an attack unfolds

An attacker with local access identifies an application using a vulnerable libffi build, crafts input that triggers a stack overflow, and leverages the executable stack to directly execute injected shellcode without needing additional memory protections to be bypassed.

How to fix it

Upgrade libffi to a fixed version (commit 67c0c0705318d2e567fd48e680d63dca3619a235 or equivalent 3.1+), and apply the corresponding fixed package versions for dependent products such as wordpress/wordpress (434f196b42c457318342d4f3664fd6b0fccfeded), dynamic-localpv-provisioner (4.0.0-r1 on both Chainguard and Wolfi). Rebuild and redeploy any statically linked consumers.

How to confirm the fix worked

Confirm that running processes or libraries report libffi version 3.1 or newer (or the listed fixed commits), and verify that the executable stack permission is no longer requested on 32-bit x86 builds via tools such as readelf or hardening checks.

Typical attack path

1. Gain local user access on a 32-bit x86 system running an affected libffi build
2. Identify a target process that links against the vulnerable libffi
3. Supply malicious input that overflows a stack buffer within libffi usage
4. Overwrite the stack with attacker-controlled code and redirect execution into it
5. Achieve arbitrary code execution and escalate privileges or persist

How to detect it

Examine package inventories, container image manifests, and build logs for references to libffi versions prior to 3.1; review process memory mappings or core dumps on 32-bit x86 systems for unexpected executable stack segments.

What your security team should do

• Prioritize patching libffi and all listed dependent packages within standard change windows
• Scan build pipelines and container images for references to libffi versions older than the fixed commits
• Update vulnerability scanners and SBOM tools with the corrected affected version range
• Review any 32-bit x86 workloads for residual exposure after remediation