Incorrect MAC key used in the RC4-MD5 ciphersuite

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

5.9 · CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

EPSS

• CVE-2022-1434: 1.23% estimated exploitation activity in the next 30 days; percentile 68.92 (FIRST EPSS, 2026-11-03). This is a model estimate, not proof of exploitation or customer exposure.

As published by the source; long descriptions are shortened.

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…

Published by the source

4 May 2022, 00:00 UTC

Last modified by the source

14 Feb 2023, 17:07 UTC

Source last checked

26 Oct 2026, 15:33 UTC

1. Revision 1 · created · 26 Oct 2026

   Published from ghsa record GHSA-638m-m8mh-7gw2

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: CVE-2022-1434

Advisory: Incorrect MAC key used in the RC4-MD5 ciphersuite
IDs: CVE-2022-1434, GHSA-638m-m8mh-7gw2
Record: https://patchnext.com/advisories/cve-2022-1434 (revision 1, source checked 26 Oct 2026, 15:33 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Medium (CVSS 5.9)
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor fix available; fixed versions by package: openssl-src 300.0.6. A vendor fix does not mean a deployment is fixed.

## Affected components
- crates.io openssl-src: affected >= 300.0.0, < 300.0.6; fixed in 300.0.6

## Suggested inspection (read-only)
- crates.io openssl-src: check the installed version with your package manager.

## Supported action
Upgrade each affected component to a fixed version on its release line. For a transitive dependency, upgrade the parent package or add an override or constraint, then regenerate the lockfile. Redeploy every environment that ran an affected version.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on openssl-src.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://github.com/advisories/GHSA-638m-m8mh-7gw2 (GitHub-reviewed advisory GHSA-638m-m8mh-7gw2 lists affected ranges: crates.io openssl-src >=300.0.0 <300.0.6)

Commands are suggestions: review each one before running it.