Applications that use a non-default option when verifying certificates may be vulnerable to an attack from…

CVE-2023-0465 is an OpenSSL certificate-validation logic flaw: if an application explicitly enables certificate policy processing, invalid policy OIDs in a leaf certificate can be ignored and the rest of policy checking for that certificate gets skipped. Affected upstream ranges are 3.1.0 to before 3.1.1, 3.0.0 to before 3.0.9, 1.1.1 to before 1.1.1u, and 1.0.2 to before 1.0.2zh; Debian and other distros may instead ship backported fixes under older-looking package versions.

Vendor/NVD MEDIUM overrates this in enterprise reality. OpenSSL itself classed it Low, and that matches operations better because certificate policy checks are disabled by default, OpenSSL says they are *not commonly used*, and the attacker also needs a malicious or compromised CA position rather than ordinary internet reachability. Date note: OpenSSL's vulnerability index lists this issue as published on 2023-03-23, while the advisory mail and NVD publication landed on 2023-03-28.

Why this verdict

• Start at vendor 5.3: on paper it is remotely reachable and affects certificate validation, so MEDIUM is the baseline.
• Down for attacker position: this is not "anyone on the internet"; it effectively requires a malicious, compromised, or otherwise trusted CA capable of issuing a chain the target accepts.
• Down again for exposure fraction: OpenSSL states certificate policy checks are disabled by default and not commonly used, so only a small subset of real deployments reach the vulnerable logic.
• Down for limited blast radius: even when hit, impact is a narrow trust-policy bypass, not RCE, not memory corruption, not broad service DoS.
• Not IGNORE because some PKI designs really use this: in environments that separate trust domains with policy OIDs, this can directly defeat that control and let the wrong cert authenticate.

Why not higher?

There is no code execution path, no common unauthenticated exploit chain, and no evidence of active abuse. The attacker must already occupy an unusually privileged trust position and then find an application that opted into a rarely used verification mode.

Why not lower?

It still undermines a security decision, not just a cosmetic check. If you built certificate-policy enforcement into an internal PKI or mTLS architecture, a bad cert may pass where it should fail, so documenting and testing for exposure is still warranted.

1. Inventory policy-check callers — Find applications that pass -policy, call X509_VERIFY_PARAM_set1_policies(), or explicitly set X509_V_FLAG_POLICY_CHECK. Because this is a LOW verdict, there is no mitigation SLA and no remediation SLA; do this during normal backlog hygiene so you can separate truly exposed apps from the much larger population that merely ships OpenSSL.
2. Constrain trust stores — Reduce accepted roots/intermediates for high-assurance services so a stray public or over-broad private CA cannot mint acceptable chains. For a LOW issue, fold this into the next PKI maintenance cycle rather than emergency change windows.
3. Use pinning or issuer allowlists on sensitive mTLS paths — Where service identity matters, pin the issuing CA or expected SPKI instead of depending solely on certificate policy OIDs. For this LOW case, deploy through routine config management and service hardening work.
4. Audit certificate issuance for unexpected policy OIDs — Review CA logs, CT telemetry where applicable, and internal issuance records for weird or invalid policy extensions. This is a good detective control when patching is deferred into normal maintenance because the issue hinges on malicious certificate issuance.

Run this on the target Linux host that provides the OpenSSL runtime, or over SSH via your fleet tool. Invoke it as bash check-cve-2023-0465.sh; no root is required, but package-manager queries work best with a normal shell on the host. It reports PATCHED if it sees a fixed upstream or known Debian backport, VULNERABLE if the installed OpenSSL version is in an affected upstream range, and UNKNOWN when distro backporting or package layout prevents a clean call.

#!/usr/bin/env bash
# check-cve-2023-0465.sh
# Detect likely exposure to CVE-2023-0465 on Linux hosts.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

say() {
  printf '%s\n' "$1"
}

have_cmd() {
  command -v "$1" >/dev/null 2>&1
}

ver_ge() {
  [ "$(printf '%s\n%s\n' "$1" "$2" | sort -V | tail -n1)" = "$1" ]
}

ver_lt() {
  [ "$1" != "$2" ] && ! ver_ge "$1" "$2"
}

is_affected_upstream() {
  local v="$1"
  if ver_ge "$v" "3.1.0" && ver_lt "$v" "3.1.1"; then return 0; fi
  if ver_ge "$v" "3.0.0" && ver_lt "$v" "3.0.9"; then return 0; fi
  if [[ "$v" =~ ^1\.1\.1[a-z]?$ ]] && ver_lt "$v" "1.1.1u"; then return 0; fi
  if [[ "$v" =~ ^1\.0\.2[a-z]?$ ]] && ver_lt "$v" "1.0.2zh"; then return 0; fi
  return 1
}

is_fixed_upstream() {
  local v="$1"
  if ver_ge "$v" "3.1.1"; then return 0; fi
  if ver_ge "$v" "3.0.9" && ver_lt "$v" "3.1.0"; then return 0; fi
  if [[ "$v" =~ ^1\.1\.1[a-z]?$ ]] && ver_ge "$v" "1.1.1u"; then return 0; fi
  if [[ "$v" =~ ^1\.0\.2[a-z]?$ ]] && ver_ge "$v" "1.0.2zh"; then return 0; fi
  return 1
}

check_debian_backport() {
  # Known fixed example from Debian bullseye advisory: 1.1.1n-0+deb11u5
  if have_cmd dpkg-query; then
    local pkgver
    pkgver=$(dpkg-query -W -f='${Version}' openssl 2>/dev/null || true)
    if [ -n "$pkgver" ]; then
      if dpkg --compare-versions "$pkgver" ge "1.1.1n-0+deb11u5"; then
        say "PATCHED: Debian/Ubuntu package version '$pkgver' is at or above Debian's known fixed bullseye backport level for CVE-2023-0465."
        exit 0
      fi
    fi
  fi
}

extract_openssl_ver() {
  if have_cmd openssl; then
    openssl version 2>/dev/null | awk '{print $2}' | sed 's/[[:space:]].*$//'
    return 0
  fi
  return 1
}

main() {
  check_debian_backport

  local v
  v=$(extract_openssl_ver || true)

  if [ -z "$v" ]; then
    say "UNKNOWN: 'openssl' binary not found. Inspect linked libssl/libcrypto packages directly or via SBOM/SCA tooling."
    exit 2
  fi

  # Strip possible suffixes such as '-fips' or distro annotations after the core version.
  v=$(printf '%s' "$v" | sed -E 's/^([0-9]+\.[0-9]+\.[0-9]+[a-z]?).*/\1/')

  if is_fixed_upstream "$v"; then
    say "PATCHED: Upstream OpenSSL version '$v' is at or above a fixed release for CVE-2023-0465."
    exit 0
  fi

  if is_affected_upstream "$v"; then
    say "VULNERABLE: OpenSSL version '$v' falls in an affected upstream range for CVE-2023-0465. Note: practical exploitability still depends on an application explicitly enabling certificate policy checks."
    exit 1
  fi

  say "UNKNOWN: OpenSSL version '$v' is not in a straightforward upstream-parseable state. This may be a vendor-backported build; verify with distro advisories and package metadata."
  exit 2
}

main "$@"

Sources

1. OpenSSL advisory
2. Official CVE JSON 5 record
3. NVD entry
4. OpenSSL vulnerability index
5. OpenSSL FIPS/CVE matrix
6. Debian security advisory
7. FIRST EPSS overview
8. CISA KEV catalog