← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
tenable:162721 · CWE-326 · Disclosed 2022-07-05

OpenSSL 1

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a nick in a spare tire, not a blowout on the freeway

This finding maps to CVE-2022-2097, not a generic OpenSSL remote compromise. The bug is an AES-OCB partial encryption failure on 32-bit x86 when OpenSSL uses its AES-NI assembly-optimized path; under certain conditions, 16 bytes may remain effectively exposed. Affected upstream ranges are OpenSSL 1.1.1 through 1.1.1p and 3.0.0 through 3.0.4; the upstream fixes are 1.1.1q and 3.0.5. OpenSSL explicitly states that TLS and DTLS are unaffected.

Tenable's MEDIUM is defensible as a generic CVSS label, but it overstates enterprise urgency. Real-world exploitation requires a stacked set of prerequisites: 32-bit x86, AES-NI present, application code actually using AES-OCB, and a path where an attacker can observe or harvest the resulting ciphertext/plaintext leakage. For most 10,000-host fleets, that is a tiny subset of assets with a tightly bounded impact.

"Narrow edge-case crypto bug: real risk only if you run 32-bit x86, AES-NI, and AES-OCB outside TLS."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Land on an actually affected host

The attacker first needs a target running a vulnerable OpenSSL branch on 32-bit x86 with AES-NI available. Version-only tooling such as Nessus plugin 162721 can flag the library, but that does not prove the host hits the vulnerable execution path.
Conditions required:
  • OpenSSL version in an affected range
  • 32-bit x86 userspace or workload path
  • CPU exposes AES-NI
Where this breaks in practice:
  • Most enterprise server fleets are 64-bit, which drops out immediately
  • Many package versions are backported, so version-string hits can be false positives
  • A generic OpenSSL install is not enough; the vulnerable assembly path must be reachable
Detection/coverage: Good inventory coverage for package presence/version via scanners and SBOMs; poor coverage for the architecture/AES-NI/runtime-path combination.
STEP 02

Find application code that uses AES-OCB

Next, the attacker needs a service or application feature that invokes AES-OCB through OpenSSL, for example via EVP_aes_*_ocb() in custom code. This is the real choke point: OpenSSL says TLS/DTLS do not use the affected OCB cipher suites, so the normal internet-facing HTTPS path is off the table.
Conditions required:
  • The application uses OpenSSL for non-TLS encryption
  • AES-OCB mode is enabled in real production logic
  • Attacker can influence or observe traffic for that feature
Where this breaks in practice:
  • AES-OCB is niche in enterprise apps compared with GCM/CTR/CBC
  • Many affected hosts will never invoke OCB at all
  • WAF/edge controls are irrelevant if the vulnerable path is an internal or custom protocol feature
Detection/coverage: Requires code review, SAST, config review, or targeted telemetry; network scanners generally cannot infer OCB usage.
STEP 03

Trigger the flawed encryption path

With a suitable target, a custom client or harness repeatedly drives the vulnerable encryption path until the partial-encryption condition occurs. The OpenSSL patch diff is public, so the bug mechanics are not secret, but this is still a bespoke exploit-development problem rather than commodity one-click weaponization.
Conditions required:
  • Attacker can send or cause data to be encrypted
  • Data shape/operation reaches the buggy assembly logic
  • Attacker can collect the resulting output
Where this breaks in practice:
  • This is not a turnkey RCE chain
  • The leak is limited to a 16-byte block per event
  • Many deployments will not expose useful attacker-observable ciphertext at all
Detection/coverage: Runtime detection is weak; packet capture or application-specific testing is more useful than IDS signatures.
STEP 04

Extract limited plaintext or stale memory

If everything lines up, the attacker may recover 16 bytes of plaintext during in-place encryption or 16 bytes of preexisting memory content in other cases. That is a confidentiality problem, but it is not integrity loss, code execution, or a broad service outage.
Conditions required:
  • Leaked bytes are attacker-visible
  • Those bytes actually contain useful secrets
  • Repeated requests yield enough material to matter
Where this breaks in practice:
  • Blast radius is tightly capped
  • Useful secret recovery may require many observations and favorable placement of data
  • Application-layer context determines whether the leak is exploitable or just academic
Detection/coverage: Very little generic telemetry; validation usually comes from controlled repro tests against known OCB-using applications.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo evidence of active exploitation found in the sources reviewed, and this CVE is not listed in CISA KEV.
Proof-of-concept availabilityPublic patch diffs exist, which lowers reverse-engineering cost, but I did not find a widely adopted weaponized PoC in primary sources. Tenable later flipped Exploit Available to true, likely reflecting public research/derivative exploit code rather than real campaign use.
EPSSTenable currently surfaces EPSS 0.00533 (0.533%) for CVE-2022-2097; SentinelOne's page surfaces 0.407% / 60.58th percentile. Either way, this is low exploit likelihood, not a hot internet exploit.
KEV statusAbsent from CISA KEV as of this assessment.
CVSS vector reality checkVendor/NVD use CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N (5.3 / Medium), which assumes a network path to affected encryption. In practice, TLS/DTLS are unaffected, so the common OpenSSL network exposure story does not apply cleanly.
Affected versionsUpstream affected ranges are 1.1.1–1.1.1p and 3.0.0–3.0.4, but only when the workload is on 32-bit x86 and reaches the AES-NI OCB assembly path.
Fixed versionsUpstream fixes are 1.1.1q and 3.0.5. Distro backports exist, including Ubuntu 20.04 1.1.1f-1ubuntu2.16, Ubuntu 18.04 1.1.1-1ubuntu2.1~18.04.20, and Debian bullseye 1.1.1n-0+deb11u4 or later security builds.
Exposure and scanning realityThere is no meaningful Shodan/Censys-style fingerprint for this bug because it is a library implementation flaw, not a bannerable service issue. Version scanners can find candidate hosts; they cannot prove AES-OCB usage or 32-bit AES-NI execution.
Disclosure timelinePublicly disclosed 2022-07-05 in the OpenSSL advisory and NVD.
Researcher / reporterReported to OpenSSL by Alex Chernyakhovsky from Google; fix developed by Alex Chernyakhovsky, David Benjamin, and Alejandro Sedeño from Google.
04 · The Call

noisgate verdict.

Final Verdict
DOWNGRADED to LOW (2.4/10)

The decisive factor is compounded reachability friction: 32-bit x86 + AES-NI + actual AES-OCB usage, while TLS/DTLS are explicitly unaffected. That turns a nominal network disclosure bug into a narrow implementation flaw with limited blast radius and little evidence of real-world weaponization.

HIGH Platform and protocol gating materially reduce exposed population
HIGH Impact is limited to confidentiality leakage, capped at 16 bytes per trigger
MEDIUM Actual fleet exposure depends on whether your applications use AES-OCB at runtime

Why this verdict

  • TLS is out of scope: OpenSSL states TLS and DTLS are unaffected, removing the usual internet-facing OpenSSL attack surface that the network CVSS vector implies.
  • Platform filter: exploitation needs 32-bit x86 plus AES-NI. In a modern enterprise fleet, that is a minority edge case, not a broad horizontal risk.
  • Crypto-mode filter: the target application must actually use AES-OCB, which is uncommon compared with GCM and other mainstream modes. A host can carry the library and still be non-exploitable in practice.
  • Impact cap: the flaw leaks 16 bytes of plaintext or stale memory under specific conditions. That is real confidentiality loss, but it is far from RCE, auth bypass, or a reliable service-kill.

Why not higher?

This does not earn MEDIUM or HIGH in an enterprise prioritization model because the attack chain narrows at every step. You need a shrinking intersection of uncommon conditions before an attacker gets even a small confidentiality leak, and the dominant OpenSSL exposure surface—HTTPS/TLS—is not impacted.

Why not lower?

This is not IGNORE because the vulnerability is real and can disclose sensitive data if an affected application genuinely uses AES-OCB on the vulnerable platform path. If you have legacy 32-bit systems or embedded/industrial workloads with custom crypto usage, the edge case can become operationally relevant.

05 · Compensating Control

What to do — in priority order.

  1. Hunt for AES-OCB usage — Search source, configs, and linked applications for EVP_aes_*_ocb or explicit OCB mode usage. For a LOW verdict there is no SLA beyond backlog hygiene, but this is the one control that separates theoretical exposure from real exposure.
  2. Cull 32-bit crypto workloads — Identify remaining 32-bit x86 hosts that still handle sensitive encryption tasks and retire or isolate them. Again, LOW means no formal mitigation SLA; treat this as hygiene work that reduces future long-tail crypto risk.
  3. Prefer distro-fixed builds over upstream string chasing — Verify whether your distro has backported the fix before launching emergency patch churn. For LOW, do this in the normal change pipeline, not as an incident response event.
What doesn't work
  • WAF rules do not help because this is not an HTTP parser or request-routing bug.
  • TLS hardening does not materially change exposure here because OpenSSL says TLS/DTLS are already unaffected.
  • Perimeter internet scanning will not tell you who is truly exposed, because the decisive factor is runtime AES-OCB usage, not a banner.
06 · Verification

Crowdsourced verification payload.

Run this on the target Linux host as a normal user; root helps if you want package-manager metadata and changelogs. Invoke it with bash check_cve_2022_2097.sh; it performs host triage, not proof that a specific application path uses AES-OCB at runtime.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2022_2097.sh
# Host-side triage for OpenSSL CVE-2022-2097
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

patched() { echo "PATCHED: $1"; exit 0; }
vulnerable() { echo "VULNERABLE: $1"; exit 1; }
unknown() { echo "UNKNOWN: $1"; exit 2; }

ver_lt() {
  # returns 0 if $1 < $2
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ] && [ "$1" != "$2" ]
}

ver_ge() {
  # returns 0 if $1 >= $2
  ! ver_lt "$1" "$2"
}

get_os_field() {
  local key="$1"
  [ -r /etc/os-release ] || return 1
  awk -F= -v k="$key" '$1==k {gsub(/^"|"$/, "", $2); print $2}' /etc/os-release
}

if ! command -v openssl >/dev/null 2>&1; then
  unknown "openssl binary not found"
fi

OPENSSL_VER_FULL="$(openssl version 2>/dev/null || true)"
OPENSSL_VER="$(printf '%s' "$OPENSSL_VER_FULL" | awk '{print $2}')"
[ -n "$OPENSSL_VER" ] || unknown "unable to parse OpenSSL version"

ARCH="$(uname -m 2>/dev/null || echo unknown)"
BITS="$(getconf LONG_BIT 2>/dev/null || echo unknown)"
CPU_AES="no"
if grep -Eq '(^flags|^Features).*\baes\b' /proc/cpuinfo 2>/dev/null; then
  CPU_AES="yes"
fi

# Distro backport checks first, to avoid false positives from older version strings.
OS_ID="$(get_os_field ID 2>/dev/null || true)"
OS_VER="$(get_os_field VERSION_ID 2>/dev/null || true)"
OS_CODE="$(get_os_field VERSION_CODENAME 2>/dev/null || true)"

if command -v dpkg-query >/dev/null 2>&1; then
  PKG_VER="$(dpkg-query -W -f='${Version}' openssl 2>/dev/null || true)"
  if [ -n "$PKG_VER" ]; then
    if [ "$OS_ID" = "ubuntu" ]; then
      case "$OS_VER" in
        18.04)
          dpkg --compare-versions "$PKG_VER" ge '1.1.1-1ubuntu2.1~18.04.20' && patched "Ubuntu 18.04 package version includes fix ($PKG_VER)"
          ;;
        20.04)
          dpkg --compare-versions "$PKG_VER" ge '1.1.1f-1ubuntu2.16' && patched "Ubuntu 20.04 package version includes fix ($PKG_VER)"
          ;;
        21.10)
          dpkg --compare-versions "$PKG_VER" ge '1.1.1l-1ubuntu1.6' && patched "Ubuntu 21.10 package version includes fix ($PKG_VER)"
          ;;
        22.04)
          dpkg --compare-versions "$PKG_VER" ge '3.0.2-0ubuntu1.6' && patched "Ubuntu 22.04 package version includes fix ($PKG_VER)"
          ;;
      esac
    fi

    if [ "$OS_ID" = "debian" ] || [ "$OS_CODE" = "bullseye" ]; then
      dpkg --compare-versions "$PKG_VER" ge '1.1.1n-0+deb11u4' && patched "Debian bullseye package version includes fix ($PKG_VER)"
    fi
  fi
fi

if command -v rpm >/dev/null 2>&1 && rpm -q openssl >/dev/null 2>&1; then
  if rpm -q --changelog openssl 2>/dev/null | grep -q 'CVE-2022-2097'; then
    patched "RPM changelog indicates CVE-2022-2097 backport"
  fi
fi

# Architecture gates. This CVE needs 32-bit x86 + AES-NI.
case "$ARCH" in
  i386|i486|i586|i686) : ;;
  *) patched "host architecture is $ARCH, not 32-bit x86" ;;
esac

[ "$BITS" = "32" ] || patched "userspace is $BITS-bit, not 32-bit"
[ "$CPU_AES" = "yes" ] || patched "CPU AES-NI flag not present"

# Upstream version checks after distro backport checks.
case "$OPENSSL_VER" in
  1.1.1*)
    if ver_lt "$OPENSSL_VER" '1.1.1q'; then
      # If this is an RPM-based distro with an older-looking version string, we may still be backported.
      if command -v rpm >/dev/null 2>&1 && rpm -q openssl >/dev/null 2>&1; then
        unknown "older 1.1.1 version string ($OPENSSL_VER) on RPM system; verify vendor backport status manually"
      fi
      vulnerable "affected upstream 1.1.1 branch ($OPENSSL_VER) on 32-bit x86 with AES-NI; actual exploitability still requires AES-OCB usage"
    else
      patched "OpenSSL upstream version is $OPENSSL_VER (>= 1.1.1q)"
    fi
    ;;
  3.0.*)
    if ver_lt "$OPENSSL_VER" '3.0.5'; then
      if command -v rpm >/dev/null 2>&1 && rpm -q openssl >/dev/null 2>&1; then
        unknown "older 3.0.x version string ($OPENSSL_VER) on RPM system; verify vendor backport status manually"
      fi
      vulnerable "affected upstream 3.0.x branch ($OPENSSL_VER) on 32-bit x86 with AES-NI; actual exploitability still requires AES-OCB usage"
    else
      patched "OpenSSL upstream version is $OPENSSL_VER (>= 3.0.5)"
    fi
    ;;
  *)
    patched "OpenSSL version $OPENSSL_VER is outside the affected upstream branches for CVE-2022-2097"
    ;;
esac
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, do not treat tenable:162721 like a fleet-wide fire drill. First, identify whether any affected hosts are actually 32-bit x86 and whether the applications on them use AES-OCB; for a LOW verdict there is no noisgate mitigation SLA and no noisgate remediation SLA—this is backlog hygiene, not emergency change. If you do find a real OCB-using legacy workload, fold the vendor fix or distro backport validation into the next normal patch cycle and close the finding with architecture/runtime evidence instead of chasing every version-string match blindly.

Sources

  1. Tenable plugin 162721
  2. OpenSSL Security Advisory 2022-07-05
  3. NVD CVE-2022-2097
  4. Tenable CVE page for CVE-2022-2097
  5. Ubuntu USN-5502-1
  6. Debian DSA-5343-1
  7. CISA Known Exploited Vulnerabilities Catalog
  8. SentinelOne CVE-2022-2097 page
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.