OpenSSL FIPS selftest failure when importing cv2 on FIPS-enabled systems

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 here

The 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');"
success

Steps 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
Aborted

Issue 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)

I would like to solve the issue, please assign me

@vmiller987

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

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.

Mowing the issue to opencv-python repo as it's related to packages build, but not OpenCV itself.

@AdityaMishra3000

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

@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.

[vmiller@gluskap tmp]$ git clone https://github.com/opencv/opencv-python.git
[vmiller@gluskap tmp]$ cd opencv-python
[vmiller@gluskap tmp]$ git fetch origin pull/1190/head:pr-1190
[vmiller@gluskap tmp]$ git checkout pr-1190
[vmiller@gluskap tmp]$ cd ~/opencv-python

[vmiller@gluskap opencv-python]$ uv venv
Using CPython 3.13.7
Creating virtual environment at: .venv
Activate with: source .venv/bin/activate
[vmiller@gluskap opencv-python]$ venv
(opencv-python) [vmiller@gluskap opencv-python]$ uv pip install scikit-build
-core numpy setuptools wheel cmake
Resolved 7 packages in 272ms
Prepared 5 packages in 897ms
Installed 7 packages in 49ms
 + cmake==4.2.1
 + numpy==2.4.1
 + packaging==26.0
 + pathspec==1.0.3
 + scikit-build-core==0.11.6
 + setuptools==80.10.2
 + wheel==0.46.3
(opencv-python) [vmiller@gluskap opencv-python]$ uv pip install scikit-build 
pip wheel . --no-build-isolation
Resolved 5 packages in 278ms
Prepared 2 packages in 67ms
Installed 2 packages in 13ms
 + distro==1.9.0
 + scikit-build==0.18.1
Processing /home/vmiller/Work/tmp/opencv-python
  Preparing metadata (pyproject.toml) ... done
Collecting numpy>=2 (from opencv-python==4.13.0+dc2e895)
  Using cached numpy-2.4.1-cp313-cp313-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl.metadata (6.6 kB)
Downloading numpy-2.4.1-cp313-cp313-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl (16.4 MB)
   ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 16.4/16.4 MB 52.7 MB/s  0:00:00
Saved ./numpy-2.4.1-cp313-cp313-manylinux_2_27_x86_64.manylinux_2_28_x86_64.whl
Building wheels for collected packages: opencv-python
  Building wheel for opencv-python (pyproject.toml) ... done
  Created wheel for opencv-python: filename=opencv_python-4.13.0+dc2e895-cp313-cp313-linux_x86_64.whl size=32287285 sha256=1dca8d48ad9dfcd1886f553468f7446af1971fa427a37656006c2a36eb88e42f
  Stored in directory: /home/vmiller/.cache/pip/wheels/b0/ab/eb/b0d579fc4ff1cefcdef823871b057fac80ff9d14819a19707d
Successfully built opencv-python
(opencv-python) [vmiller@gluskap opencv-python]$ cd ~

(opencv-python) [vmiller@gluskap opencv-python]$ uv pip install ./opencv_python*.whl
Resolved 2 packages in 116ms
Prepared 1 package in 165ms
Installed 1 package in 4ms
 + opencv-python==4.13.0+dc2e895 (from file:///home/vmiller/Work/tmp/opencv-python/opencv_python-4.13.0+dc2e895-cp313-cp313-linux_x86_64.whl)

(opencv-python) [vmiller@gluskap opencv-python]$ cd ~
(opencv-python) [vmiller@gluskap ~]$ python -c "import cv2; print(cv2.__version__)"
4.13.0
(opencv-python) [vmiller@gluskap ~]$

@asmorkalov

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.

+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)

@asmorkalov

@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.

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:

OpenSSL was built without FIPS support
Or the FIPS checksum doesn't match the runtime OpenSSL

Potential fixes:

Rebuild with FIPS-enabled OpenSSL - Use OpenSSL built with enable-fips flag
Use system OpenSSL - Link against system OpenSSL instead of bundled
FIPS mode detection - Add detection and fallback in cv2/init.py

Observation: 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?

I apologize for late response, too many things are going on in parallel. It's time to bring more facts to make a decision.

OpenSSL is used primarily by FFmpeg. It's needed to handle https URLs like for web streams and RTSP cameras. We cannot drop the OpenSSL (or analog) dependency without significant functionality degradation. I'm very sure that OpenCV is actively used for network streaming and security cameras. The dependency was introduced here: Added OpenSSL & various protocol support to FFmpeg backend #229. readelf -d example for opencv-python 5.0.0:

libavformat-4762a711.so.62.12.101

Dynamic section at offset 0x2d3000 contains 37 entries:
  Tag        Type                         Name/Value
 0x000000000000000f (RPATH)              Library rpath: [$ORIGIN]
 0x0000000000000001 (NEEDED)             Shared library: [libavcodec-c4204469.so.62.28.101]
 0x0000000000000001 (NEEDED)             Shared library: [libavutil-befbbc48.so.60.26.101]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libssl-81259c47.so.1.1.1k]
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto-5409cd36.so.1.1.1k]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libavformat-4762a711.so.62.12.101]
 0x0000000000000010 (SYMBOLIC)           0x0
 0x000000000000000c (INIT)               0x3e000
 0x000000000000000d (FINI)               0x21205c
 0x0000000000000019 (INIT_ARRAY)         0x299610
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x299618
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x2d0028
 0x0000000000000005 (STRTAB)             0x2d8000
 0x0000000000000006 (SYMTAB)             0x770
 0x000000000000000a (STRSZ)              13874 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x2cdfe8
 0x0000000000000002 (PLTRELSZ)           14544 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x39bc8
 0x0000000000000007 (RELA)               0x8ce0
 0x0000000000000008 (RELASZ)             200424 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffc (VERDEF)             0x8b38
 0x000000006ffffffd (VERDEFNUM)          2
 0x000000000000001e (FLAGS)              SYMBOLIC
 0x000000006ffffffe (VERNEED)            0x8b70
 0x000000006fffffff (VERNEEDNUM)         8
 0x000000006ffffff0 (VERSYM)             0x8530
 0x000000006ffffff9 (RELACOUNT)          8203
 0x0000000000000000 (NULL)               0x0

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.

@asmorkalov

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 the OpenSSL 1.1.1w 11 Sep 2023 build until 4.12.0.88 and acquired the FIPS support in it.

You can see the same in your listing

 0x0000000000000001 (NEEDED)             Shared library: [libssl-81259c47.so.1.1.1k]
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto-5409cd36.so.1.1.1k]

~~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.~~

*[Update: I must have mixed up some files. opencv_python_headless-4.14.0.94-cp37-abi3-manylinux_2_28_x86_64.whl has OpenSSL 1.1.1k FIPS 25 Mar 2021 while opencv_python_headless-4.14.0.94-cp37-abi3-manylinux2014_x86_64.manylinux_2_17_x86_64.whl has OpenSSL 1.1.1w 11 Sep 2023]

(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.)

do we have any workaround for this?

Use trusted publishing

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:

No need to install twine by yourself
No need for secrets
It would create attestations to prove the wheel origin in this repo and release workflow

I believe this kind of change would solve this issue.

Use trusted publishing

@asmorkalov

@asmorkalov

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:

This is actually currently not true for manylinux_2_28:

https://github.com/opencv/opencv-python/blob/90/docker/manylinux_2_28/Dockerfile_x86_64#L18

Unlike manylinux2014 (where things happen exactly as you say), manylinux_2_28 installs system OpenSSL and does not build its own vanilla version.

If you copy the relevant OpenSSL download/build section from manylinux2014 to manylinux_2_28, it should properly fix the FIPS issue.

PR with the fix: #1281

If you copy the relevant OpenSSL download/build section from manylinux2014 to manylinux_2_28, it should properly fix the FIPS issue.

Seems I must must have mixed up files in my earlier comment. On PyPi opencv_python_headless-4.14.0.94-cp37-abi3-manylinux_2_28_x86_64.whl has OpenSSL 1.1.1k FIPS 25 Mar 2021 while opencv_python_headless-4.14.0.94-cp37-abi3-manylinux2014_x86_64.manylinux_2_17_x86_64.whl has OpenSSL 1.1.1w 11 Sep 2023. The OpenSSL 1.1.1k FIPS 25 Mar 2021 seems to be on quay.io/pypa/manylinux_2_28_x86_64 and comes from the openssl-libs package.

So yes, this patch could be the fix.

Pin opencv-python-headless below 4.13 on Linux, so Cellpose starts on…

This could be another small motivation for

Provide wheel without FFmpeg (non-LGPL wheel) #353

Users who don't need FFmpeg capabilties could use a more minimal wheel without this and the transitive dependency on:

import cv2
  → bundled FFmpeg libavformat
    → bundled libcrypto-5409cd36.so.1.1.1k

libcrypto: OpenSSL 1.1.1k  FIPS 25 Mar 2021

Link OpenSSL statically into FFmpeg on manylinux_2_28

Update FFmpeg to 9.0.2, build own OpenSSL on manylinux_2_28, Docker i…

Navigation Menu

Repository navigation

OpenSSL FIPS selftest failure when importing cv2 on FIPS-enabled systems #1191

System Information

Detailed description

Steps to reproduce

Issue submission checklist

5 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

OpenSSL FIPS selftest failure when importing cv2 on FIPS-enabled systems #1191

Description

System Information

Detailed description

Steps to reproduce

Issue submission checklist

Activity

aviralgarg05 commented on Jan 24, 2026

AdityaMishra3000 commented on Jan 24, 2026

asmorkalov commented on Jan 26, 2026

asmorkalov commented on Jan 26, 2026

vmiller987 commented on Jan 26, 2026

AdityaMishra3000 commented on Jan 26, 2026

jayteaftw commented on Feb 4, 2026

c-schoenherr commented on May 4, 2026

mulhamfetna commented on May 6, 2026

5 remaining items

asmorkalov commented on Aug 20, 2026

kohtala commented on Aug 21, 2026

vivek-koul commented on Aug 22, 2026

kohtala commented on Aug 23, 2026

tvasenin commented on Oct 26, 2026

kohtala commented on Oct 27, 2026

johnthagen commented on Nov 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions