GHSA-qr4w-53vh-m672

What it actually does

The vulnerable opencv-python wheels bundle an affected libwebp binary. Applications that use OpenCV to decode WebP images can trigger memory corruption, specifically a heap buffer overflow, when parsing a maliciously crafted WebP file. Depending on allocator behavior, process hardening, and how the application handles untrusted images, exploitation can result in application crashes, denial of service, or potentially arbitrary code execution in the context of the process performing image decoding.

Why it matters to the business

Systems that accept, ingest, transform, scan, or analyze user-supplied images with vulnerable opencv-python versions may be exposed to remote compromise or service disruption through a crafted image file. The risk is highest for internet-facing upload pipelines, media-processing services, AI/ML image workflows, document-processing systems, and batch processors that automatically decode untrusted WebP content. Although this advisory is not listed in CISA KEV and no exploit maturity was provided, the underlying libwebp issue is widely known and the advisory has been public for a long time, so remaining vulnerable deployments should be treated as avoidable technical debt with meaningful operational risk.

How an attack unfolds

An attacker identifies an application or workflow that accepts image input and uses opencv-python to decode or process it. The attacker prepares a malformed WebP file designed to exercise the vulnerable libwebp parsing path bundled inside the affected OpenCV Python wheel. The file is delivered through an upload form, API endpoint, message attachment, object-storage drop location, batch import, or any other image ingestion path. When the application calls OpenCV image decoding functionality, libwebp parses attacker-controlled image data and corrupts heap memory. In less sophisticated cases this causes the Python worker, web process, or batch job to crash. In a successful code-execution scenario, the attacker gains the privileges of the process performing image decoding, which may allow access to files, credentials, internal services, or downstream systems reachable from that process.

How to fix it

Upgrade opencv-python from PyPI to version 4.8.1.78 or later. Rebuild and redeploy any containers, virtual environments, serverless packages, model-serving images, or offline batch workers that vendor or cache Python wheels. Remove stale wheel caches and lockfile entries that pin vulnerable versions. If OpenCV-related variants are used in the same environment, such as headless or contrib builds, verify they are also updated to non-vulnerable builds that no longer bundle the affected libwebp. Where immediate upgrade is not possible, reduce exposure by blocking or quarantining WebP input from untrusted sources, validating image types before processing, routing image decoding through a sandboxed worker with low privileges, enforcing strict resource limits, and isolating image-processing workloads from sensitive credentials and internal networks.

How to confirm the fix worked

Confirm the installed package version with package inventory tooling, SBOMs, lockfiles, or commands such as `python -m pip show opencv-python` and `python -m pip freeze | grep opencv-python`. The deployed version should be 4.8.1.78 or later. Validate all runtime artifacts, not only source repositories: container images, virtual environments, CI build caches, serverless bundles, notebooks, ML pipelines, and batch-processing hosts can each carry their own wheel copy. After upgrading, restart long-running services so the patched binary extension is loaded. Confirm application behavior by processing benign WebP files through the same code paths and reviewing crash/error telemetry. If possible, use software composition analysis to verify the bundled libwebp exposure has been removed from packaged artifacts.

Typical attack path

1. Find an application, API, or processing pipeline that accepts image files or image-like content from untrusted sources.
2. Confirm or infer that the backend uses Python OpenCV/opencv-python to decode uploaded or imported images.
3. Create or obtain a malicious WebP file that triggers the vulnerable libwebp decoding path.
4. Deliver the file through an upload endpoint, attachment, object store, queue, or batch-processing input directory.
5. Wait for the application to decode the image using OpenCV functions such as image read, decode, resize, thumbnailing, metadata extraction, or ML preprocessing.
6. Cause heap memory corruption in the vulnerable libwebp library bundled with opencv-python.
7. Achieve denial of service through process crashes, or potentially execute code in the context of the image-processing process if exploitation is reliable in that environment.
8. Use any gained execution to access local files, secrets, network resources, or pivot to other systems available to the compromised process.

How to detect it

There are no reliable universal indicators proving exploitation because malicious WebP files may be delivered through normal upload or ingestion paths and memory corruption may leave limited traces. Review application, web, API gateway, object-storage, queue, and batch-processing logs for WebP uploads or downloads immediately preceding crashes, worker restarts, segmentation faults, abnormal exits, or unexplained high error rates. Correlate events where Python, OpenCV, media-processing workers, ML inference workers, or image-thumbnailing services handled files with `.webp` names, `image/webp` content type, or `RIFF....WEBP` file headers. On hosts, inspect core dumps, crash reports, EDR telemetry, and system logs for crashes in Python processes with stack traces or loaded modules referencing OpenCV, cv2, libwebp, WebPDecode, VP8L, or Huffman table decoding. Preserve suspicious WebP samples submitted near crash times and analyze them in an isolated environment. Treat a sequence of untrusted WebP input followed by a Python/OpenCV process crash as suspicious, especially if accompanied by unexpected child processes, outbound connections, file access, credential reads, or persistence attempts from the image-processing process.

• opencv-python==4.8.0.76
• opencv-python==4.7.0.72
• opencv-python==4.6.0.66
• opencv-python==4.5.5.64
• image/webp
• .webp
• RIFF
• WEBP
• libwebp
• WebPDecode
• VP8LDecodeImage
• ReadHuffmanCodes
• BuildHuffmanTable
• heap-buffer-overflow
• Segmentation fault
• SIGSEGV
• cv2.error
• cv2.imread
• cv2.imdecode
• python

What your security team should do

• Inventory all uses of opencv-python across source repositories, containers, notebooks, model-serving environments, and production image-processing services.
• Prioritize remediation for internet-facing or externally fed image upload, media-processing, AI/ML, document-processing, and batch-ingestion workflows.
• Upgrade opencv-python to 4.8.1.78 or later and rebuild all deployable artifacts from clean dependency caches.
• Add dependency policies to prevent vulnerable opencv-python versions from being reintroduced through lockfiles or transitive build artifacts.
• Temporarily restrict WebP processing from untrusted sources where patching cannot be completed quickly.
• Run image decoding workloads with least privilege, filesystem restrictions, sandboxing, and network egress controls to limit post-exploitation impact.
• Search historical logs and crash telemetry for WebP-triggered failures, especially around upload or ingestion events.
• Ensure SBOM and vulnerability scanners inspect Python wheels inside containers and packaged application artifacts, not only top-level dependency manifests.