Repository navigation
OpenSSL FIPS selftest failure when importing cv2 on FIPS-enabled systems #1191
Description
System Information
- OS: RHEL 9.7 with FIPS enabled
- Python 3.13.7
- opencv-python==4.13.0.90
Detailed description
Importing cv2 crashes with FATAL FIPS SELFTEST FAILURE on systems with FIPS mode enabled.
The crash occurs when loading the native cv2 binary extension in cv2/__init__.py:
py_module = sys.modules.pop("cv2")
native_module = importlib.import_module("cv2") # <-- crashes hereThe cv2 binary appears to be linked against the OpenSSL in a way that fails FIPS validation on FIPS-enabled systems.
Reverting to the previous release currently provides a workaround.
[vmiller@gluskap tmp]$ uv venv
Using CPython 3.13.7
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
[vmiller@gluskap tmp]$ venv
(tmp) [vmiller@gluskap tmp]$ uv pip install "opencv-python<4.13.0.90"
Resolved 2 packages in 135ms
Prepared 2 packages in 10.33s
Installed 2 packages in 20ms
+ numpy==2.2.6
+ opencv-python==4.12.0.88
(tmp) [vmiller@gluskap tmp]$ python -c "import cv2; print('success');"
successSteps to reproduce
On a machine installed with fips=1:
[vmiller@gluskap tmp]$ uv venv
Using CPython 3.13.7
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
[vmiller@gluskap tmp]$ venv
(tmp) [vmiller@gluskap tmp]$ uv pip install opencv-python
Resolved 2 packages in 402ms
Prepared 2 packages in 1.83s
Installed 2 packages in 19ms
+ numpy==2.4.1
+ opencv-python==4.13.0.90
(tmp) [vmiller@gluskap tmp]$ python -c "import cv2"
crypto/fips/fips.c:154: OpenSSL internal error: FATAL FIPS SELFTEST FAILURE
AbortedIssue submission checklist
- I report the issue, it's not a question
- I checked the problem with documentation, FAQ, open issues, forum.opencv.org, Stack Overflow, etc and have not found any solution
- I updated to the latest OpenCV version and the issue is still there
- There is reproducer code and related data files (videos, images, onnx, etc)
Activity
aviralgarg05 commentedon Jan 24, 2026
I would like to solve the issue, please assign me
AdityaMishra3000 commentedon Jan 24, 2026
I opened a PR that addresses this issue by removing bundled OpenSSL from the
manylinux build and relying on system OpenSSL instead.
PR:#1190
@vmiller987 Let me know if this is satisfactory
asmorkalov commentedon Jan 26, 2026
OpenCV does not use OpenSSL and does not contain any crypto related code. The SSL is 3rdparty dependency for one or several OpenCV 3rdparty dependencies, e.g. FFmpeg, QT, image IO libraries.
asmorkalov commentedon Jan 26, 2026
Mowing the issue to opencv-python repo as it's related to packages build, but not OpenCV itself.
vmiller987 commentedon Jan 26, 2026
@AdityaMishra3000 , @asmorkalov , thank you for the fast responses. I am not used to this.
The #1190 PR would appear to resolve my issue.
I pulled your branch, built the wheel, and installed it.
AdityaMishra3000 commentedon Jan 26, 2026
Hello @asmorkalov , I am new to these procedures. Thanks for the clarification.
I agree this is not OpenCV core but a 3rdparty issue. Let me know if you’d like me to adjust anything
in the PR or if there’s a preferred direction for handling this.
jayteaftw commentedon Feb 4, 2026
+1 Anything we can do to get #1190 pushed? FIPS Compliant machine are currently running with a critical vulnerability until this is addressed: GHSA-4r2x-xpjr-7cvv
Fix FIPS selftest crash by pinning opencv-python-headless to 4.12.0.88
Fix FIPS selftest crash by pinning opencv-python-headless (#96)
c-schoenherr commentedon May 4, 2026
@asmorkalov a review of #1190 would be greatly appreciated, it looks like someone approved the PR who is not an actual maintainer of the project.
mulhamfetna commentedon May 6, 2026
This is a security-critical issue affecting FIPS-compliant systems (government/enterprise).
Root cause: OpenCV's bundled OpenSSL is linked in a way that triggers FIPS selftest failure. This is likely because:
Potential fixes:
enable-fipsflagObservation: Downgrading to 4.12.0.88 works. This suggests a change between those versions affecting OpenSSL linkage.
Related: This issue is similar to CVE concerns - I noticed issue #1186 about bundled libpng CVE. Security build configurations may need review.
I have experience debugging OpenCV build issues. What build configuration changed between 4.12 and 4.13 that could affect OpenSSL?
mulhamfetna commentedon May 8, 2026
I've worked on compatibility issues in opencv-python (PR #1222).
Technical Analysis:
FIPS (Federal Information Processing Standards) requires cryptographic modules to perform self-tests before use. OpenCV's bundled OpenSSL may not be FIPS-certified, causing the selftest failure.
Root Cause:
When OpenCV links against OpenSSL 3.0.x without FIPS mode enabled in the library itself, importing cv2 on a FIPS-enabled system triggers the error.
Solution Options:
The simplest approach is likely option 3 - add initialization code to handle FIPS systems gracefully.
Related:
Happy to implement a fix for this security/compatibility issue.
mulhamfetna commentedon May 9, 2026
I've created a PR to fix this FIPS selftest failure issue:
PR: #1224
Summary of Fix
The issue is caused by the bundled OpenSSL 1.1.1w in the manylinux build, which triggers FIPS self-test failure on FIPS-enabled systems.
Solution: Remove the vendored OpenSSL and configure FFmpeg to use system OpenSSL via pkg-config. System OpenSSL on FIPS-enabled systems is FIPS-compliant, preventing the self-test failure.
Changes Made
docker/manylinux2014/Dockerfile_x86_64This approach is the same as PR #1190 by @AdityaMishra3000, which was also verified working by the original issue reporter.
marcreichman-pfi commentedon Jun 11, 2026
Hello @asmorkalov - is there any way this can proceed? Our project is pinned to the latest OpenCV 4.12 because of this in Python. Aside from building our own dedicated modules, we can work with the environment variables to bypass issues in OpenCV 4.12, but with 4.13 those seem to be broken. This is in a FIPS mode Rocky 8-10 host, with Ubuntu 24.04 docker containers.
marcreichman-pfi commentedon Jul 2, 2026
Still no dice. Rocky FIPS host, Ubuntu 24.04 Docker.
Dockerfile:
Test:
hammondr commentedon Jul 30, 2026
@asmorkalov , I'm sorry to be a pest but there are several downstream projects that could really use this review + merge. We are dependent upon opencv on systems that are required to run in FIPS mode. I see there are now some merge conflicts with the PR. Once those are resolved, is there anything else we can provide or adjust in the PR to facilitate merging? Thanks!
asmorkalov commentedon Aug 20, 2026
I apologize for late response, too many things are going on in parallel. It's time to bring more facts to make a decision.
readelf -dexample for opencv-python 5.0.0:Even manylinux 2014 does not include OpenSSL into list of guarantied system libraries: proof. It means that OpenSSL have to be included into distributed wheel and will be a subject of FIPS anyway.
OpenCV environment for python packages build does not use OpenSSL provided by system package manager. It's too old and we are not sure about security issues there. OpenCV built own instance of latest OpenSSL library during docker image build: https://github.com/opencv/opencv-python/blob/2ba8bf62f2f1215ab620416b041c9659005fa25c/docker/manylinux2014/Dockerfile_x86_64#L64OpenSSL security concerns from OpenCV-Python users: There is a vulnerability in the library that Opencv-python depends on. #614, Vulnerable shared libraries might make opencv-python vulnerable. Can you help upgrade to patch versions? #646.
kohtala commentedon Aug 21, 2026
Thanks for taking a look @asmorkalov .
The OpenSSL build in the openssl-python and -headless wheels at PyPi since 4.13.0.90 is
OpenSSL 1.1.1k FIPS 25 Mar 2021. It has got downgraded from theOpenSSL 1.1.1w 11 Sep 2023build until 4.12.0.88 and acquired the FIPS support in it.You can see the same in your listing
The wheel on PyPi is not the same as built here on this repository.
For example the opencv_python_headless-4.14.0.94-cp37-abi3-manylinux2014_x86_64.manylinux_2_17_x86_64.whl on PyPi is not the same as built on the build #141. The whl artifact on this build 141 contains OpenSSL build
OpenSSL 1.1.1w 11 Sep 2023, which would be what we are expecting and would not have this issue since it has no FIPS compiled in it.To get this fixed, you need to find out where the wheels on PyPi are built and why they use an even older openssl. It is not built from the sources and versions in this repository.
(Another issue then is that the OpenSSL 1.1.1w being targeted went EOL in 2023 and unless there is paid extended support, there is none. If someone is concerned about vulnerabilities, it should be upgraded to a version that is still supported.)
vivek-koul commentedon Aug 22, 2026
do we have any workaround for this?
Use trusted publishing
Use trusted publishing
kohtala commentedon Aug 23, 2026
I drafted a change PR #1264 to migrate to PyPi Trusted Publishing. Your workflows seem to now use long lived secrets. They also fail to release installing twine.
Using pypa/gh-action-pypi-publish would come a number of improvements:
I believe this kind of change would solve this issue.
Use trusted publishing
Use trusted publishing