GHSA-jh2j-j4j9-crg3

What it actually does

opencv-python-headless PyPI wheels shipped bundled libwebp binaries that contain a heap buffer overflow in WebP Huffman-table construction. Decoding a malicious WebP through OpenCV native image APIs can overwrite adjacent heap memory in the host Python process, causing process crash or arbitrary code execution at the privileges of the application.

Why it matters to the business

Any computer-vision, media, or ML pipeline that installs opencv-python-headless and processes untrusted images can be taken over, disrupting services and exposing models, data, and connected systems. About 43 downstream dependents can inherit the vulnerable wheel, amplifying blast radius across products that never pinned libwebp themselves. The advisory is not in CISA KEV and has no documented public exploit against these wheels, but the underlying decoder class of flaw has been used in real-world attacks elsewhere, so unpatched image-ingest services remain a high operational risk until upgraded to 4.8.1.78 or later.

How an attack unfolds

An attacker prepares a WebP file that triggers the overflow in the bundled libwebp, then places it on any path the application already uses to load images (upload, URL fetch, dataset ingest, message attachment, or object-store event). When application code calls OpenCV decode or read APIs, the vulnerable native library parses the file, corrupts the heap, and the attacker can hijack the Python worker and run follow-on actions with that process’s privileges. No public exploit targeting these OpenCV wheels is recorded, so successful abuse depends on reaching a live decode path that still uses a pre-fix wheel.

How to fix it

Upgrade opencv-python-headless on PyPI to 4.8.1.78 or later, which replaces the bundled libwebp with a patched build. Refresh lockfiles and container images (requirements.txt, poetry.lock, Pipfile.lock, uv.lock) so transitive pins cannot pull an older wheel. Rebuild and redeploy all runtime images rather than hot-patching site-packages. Until the upgrade lands, refuse or transcode WebP before it reaches OpenCV and run image workers with least privilege in an isolated sandbox.

How to confirm the fix worked

Run package inventory (pip show opencv-python-headless, pip freeze, or SBOM) and confirm every environment reports 4.8.1.78 or newer. Rebuild images from a clean cache and re-scan so old wheels are not left in layers. Exercise production image-decode paths with benign WebP and confirm workers stay stable. Dependency scanners should no longer report GHSA-jh2j-j4j9-crg3 after the upgrade.

Typical attack path

1. Locate a service that depends on opencv-python-headless and accepts or fetches images
2. Confirm the installed wheel is older than 4.8.1.78 and still bundles the vulnerable libwebp
3. Submit or plant a crafted WebP on an image-ingest path (upload, URL, queue, or storage event)
4. Wait for application code to decode the file via OpenCV native APIs
5. Trigger heap corruption in the Python process and take control of the worker
6. Use the compromised process to steal data, move laterally, or implant persistence

How to detect it

Hunt historical Python/OpenCV worker crashes, segfaults, and rapid restarts that coincide with WebP uploads or fetches. Review application and reverse-proxy logs for .webp ingest followed by 5xx, worker death, or native exceptions. Inspect core dumps and crash reporters for frames in bundled libwebp or cv2 native code during Huffman/WebP decode. Check package-install and container-layer history for opencv-python-headless wheels older than 4.8.1.78 that were present at the time of the event. There are no public exploit signatures specific to these wheels; treat unexplained heap crashes during WebP decode on unpatched hosts as suspicious.

• opencv-python-headless==4.8.0
• opencv-python-headless==4.7
• opencv-python-headless-4.8.0
• opencv-python-headless-4.7
• site-packages/cv2/
• libwebp
• cv2.imread
• cv2.imdecode
• Content-Type: image/webp
• .webp
• RIFF....WEBP
• BuildHuffmanTable
• heap-buffer-overflow

What your security team should do

• Inventory all runtimes, containers, and lockfiles for opencv-python-headless older than 4.8.1.78, including transitive and cached wheels
• Upgrade to opencv-python-headless 4.8.1.78 or later and rebuild/redeploy artifacts immediately given CVSS 8.8 and 43 downstream dependents
• Map every untrusted image-ingest path that can reach OpenCV decode APIs and restrict WebP until those paths are patched
• Run computer-vision workers as non-root, network-constrained processes with no unnecessary credentials
• Alert on native crashes, worker restarts, and sudden decode failures involving WebP in Python/OpenCV processes