NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🦀
🦀 crates.io
Not in CISA KEV
MEDIUM severity

Incorrect MAC key used in the RC4-MD5 ciphersuiteGHSA-638m-m8mh-7gw2

MEDIUM

GHSA-638m-m8mh-7gw2 is a medium-severity (CVSS 5.9) Broken Cryptographic Algorithm vulnerability in openssl-src. A fix is available for openssl-src — see the affected versions and patch details below.

Also known asCVE-2022-1434RUSTSEC-2022-0026
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

EPSS Exploitation Probability

via FIRST.org ↗
1.2%probability of exploitation in next 30 days
Lower Risk+0.17%
Lower risk than most CVEs69th percentile — riskier than 69% of all scored CVEsHighest risk
0.00%0.58%1.15%1.73%0.1%1.2%Apr 26Aug 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

1 pkg affected
🦀openssl-src

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

The OpenSSL 3.0 implementation of the RC4-MD5 ciphersuite incorrectly uses the AAD data as the MAC key. This makes the MAC key trivially predictable. An attacker could exploit this issue by performing a man-in-the-middle attack to modify data being sent from one endpoint to an OpenSSL 3.0 recipient such that the modified data would still pass the MAC integrity check. Note that data sent from an OpenSSL 3.0 endpoint to a non-OpenSSL 3.0 endpoint will always be rejected by the recipient and the connection will fail at that point. Many application protocols require data to be sent from the client to the server first. Therefore, in such a case, only an OpenSSL 3.0 server would be impacted when talking to a non-OpenSSL 3.0 client. If both endpoints are OpenSSL 3.0 then the attacker could modify data being sent in both directions. In this case both clients and servers could be affected, regardless of the application protocol. Note that in the absence of an attacker this bug means that an OpenSSL 3.0 endpoint communicating with a non-OpenSSL 3.0 endpoint will fail to complete the handshake when using this ciphersuite. The confidentiality of data is not impacted by this issue, i.e. an attacker cannot decrypt data that has been encrypted using this ciphersuite - they can only modify it. In order for this attack to work both endpoints must legitimately negotiate the RC4-MD5 ciphersuite. This ciphersuite is not compiled by default in OpenSSL 3.0, and is not available within the default provider or the default ciphersuite list. This ciphersuite will never be used if TLSv1.3 has been negotiated. In order for an OpenSSL 3.0 endpoint to use this ciphersuite the following must have occurred: 1) OpenSSL must have been compiled with the (non-default) compile time option enable-weak-ssl-ciphers 2) OpenSSL must have had the legacy provider explicitly loaded (either through application code or via configuration) 3) The ciphersuite must have been explicitly added to the ciphersuite list 4) The libssl security level must have been set to 0 (default is 1) 5) A version of SSL/TLS below TLSv1.3 must have been negotiated 6) Both endpoints must negotiate the RC4-MD5 ciphersuite in preference to any others that both endpoints have in common Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2).

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.ioopenssl-src≥ 300.0.0&&< 300.0.6300.0.6cargo update -p openssl-src --precise 300.0.6

Affected Products

26 products · 26 configurations
OS
a250 firmwarenetapp
all
OS
a700s firmwarenetapp
all
Application
active iq unified managernetapp
all
OS
aff 500f firmwarenetapp
all
OS
aff 8300 firmwarenetapp
all
OS
aff 8700 firmwarenetapp
all

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openssl-src, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update openssl-src to 300.0.6 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-638m-m8mh-7gw2 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

Fixing This On Your OS

If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.

UbuntuMEDIUM

Frequently Asked Questions

The OpenSSL 3.0 implementation of the RC4-MD5 ciphersuite incorrectly uses the AAD data as the MAC key. This makes the MAC key trivially predictable. An attacker could exploit this issue by performing a man-in-the-middle attack to modify data being sent from one endpoint to an OpenSSL 3.0 recipient such that the modified data would still pass the MAC integrity check. Note that data sent from an OpenSSL 3.0 endpoint to a non-OpenSSL 3.0 endpoint will always be rejected by the recipient and the connection will fail at that point. Many application protocols require data to be sent from the client
O3 Security · Impact-Aware SCA

Is GHSA-638m-m8mh-7gw2 in your dependencies?

Find it across crates.io, including transitive dependencies.

Incorrect MAC key used in the RC4-MD5 ciphersuite