CVE-2023-6258 is a High severity (CVSS 8.1) flaw in pkcs11-provider, the OpenSSL 3 provider for PKCS#11 hardware tokens. PKCS#1 1.5 decryption can leak information through a Bleichenbacher style side channel. Red Hat's tracker lists the fix in pkcs11-provider 0.2, so upgrade to that release or later.
What's affected
The record and Red Hat's tracking bug supply the facts.
- Affected: pkcs11-provider 0.1. The record lists version 0.1 as the product version.
- Fixed: Red Hat's Bugzilla entry lists "Fixed In Version: pkcs11-provider-0.2". The fix is a merged pull request, number 308, titled "Side-channel proofing PKCS#1 1.5 paths", merged on 28 November 2023.
- Severity: 8.1 High. Red Hat's own tracker lists medium priority and severity, so the two sources differ. The NVD score reflects the cryptographic impact; Red Hat weighs how hard the attack is in practice.
The project calls the problem Marvin in the pull request. It concerns RSA decryption using the older PKCS#1 version 1.5 padding when the private key lives in a hardware token reached through this provider.
How to check if you're exposed
Find out whether the provider is installed and which version.
rpm -q pkcs11-provider
dpkg -l | grep -i pkcs11-provider
openssl list -providers
The last command shows the providers OpenSSL has loaded in the current configuration. Look in your OpenSSL configuration for a pkcs11 provider section to see whether it is used on purpose.
Then ask a harder question: does any service accept RSA PKCS#1 1.5 encrypted data that it decrypts through a token? TLS servers that use RSA key exchange and applications that decrypt with RSA keys held in an HSM are the usual cases. The free in-browser dependency scan and an SBOM inventory can find the package across your fleet.
What to do now
- Update pkcs11-provider to 0.2 or later, or install your distribution's patched package.
- Restart services that load the provider so they pick up the new library.
- Prefer RSA OAEP and modern key exchange over PKCS#1 1.5 where you control both sides.
- Limit who can send repeated decryption requests to a service backed by a token, and rate limit where practical.
- Add the provider to your software inventory with its version so it shows up in future scans.
Why it matters
The weaknesses are CWE-203, observable discrepancy, and CWE-1300, improper protection of physical side channels. Bleichenbacher style attacks work by observing small differences in how a system responds to malformed padded messages. If valid and invalid padding take different paths or different amounts of time, repeated queries can reveal the plaintext or allow a signature to be forged.
The fix makes the PKCS#1 1.5 code paths behave the same way whatever the input. This is hard to do correctly. Exploitation needs many queries and a decryption oracle, so it is not a casual attack. The kev flag is false, and neither source reports use in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect OpenSSL itself?
The record is about pkcs11-provider, a separate project that plugs into OpenSSL 3. OpenSSL's own code is not the subject of this entry.
What fixes it?
Red Hat's tracker lists pkcs11-provider 0.2 as the fixed version.
Sources
Last reviewed: 19 October 2026.
