PHP 7

Tenable plugin 166901 fires on PHP 7.4.x before 7.4.33 and bundles two fixes from the November 3, 2022 PHP 7.4.33 security release: CVE-2022-31630 in gd imageloadfont() and CVE-2022-37454 in SHA-3 hash_update(). The first needs an application to accept an attacker-supplied font file and then use that font with imagechar(); the second needs the application to drive the SHA-3 code path with attacker-controlled data, with the public PHP reproducer using a 4,294,967,295-byte update call.

Vendor CRITICAL is technically anchored to the 9.8 score on CVE-2022-37454, but that score badly overstates fleet risk for ordinary PHP web hosting. On real estates, neither bug is 'send one HTTP request to any PHP site and get RCE'; both depend on uncommon app logic, and one of them was explicitly described by PHP maintainers as requiring obviously malicious invocation. For a 10,000-host patch queue, this belongs below remotely reachable edge RCEs and known-exploited flaws.

Why this verdict

• Requires specific app behavior: neither issue is exploitable just because TCP/80 or TCP/443 reaches a PHP site; the app must call imageloadfont() or SHA-3 hash_update() on attacker-controlled input.
• Population narrows hard at each step: imageloadfont() is niche, and SHA-3 streaming is uncommon in mainstream PHP web apps. That takes this from 'all PHP servers' to a much smaller subset.
• The vendor baseline is inflated by one component CVE: Tenable inherits the 9.8 score from CVE-2022-37454, but that score models theoretical impact, not the rarity of a remotely reachable vulnerable workflow in enterprise deployments.

Why not higher?

There is no credible evidence in the reviewed sources that attackers are broadly exploiting these bugs against typical internet-facing PHP sites. More importantly, the attack chain assumes either a rare font-loading feature or a very specific SHA-3 hashing path on untrusted input; those are compounding prerequisites that sharply reduce real exposure.

Why not lower?

These are still memory-safety bugs inside the interpreter, not harmless edge cases. If you run a bespoke app that accepts untrusted font files or hashes attacker-supplied large files with SHA-3, the impact can move from crash/disclosure into serious compromise territory.

1. Block untrusted font workflows — If any app uses GD custom fonts, stop accepting user-supplied font files or gate them behind strict allowlists and offline validation. This directly cuts off CVE-2022-31630; for a MEDIUM verdict there is no mitigation SLA, so fold it into normal engineering change control rather than emergency work.
2. Avoid SHA-3 on attacker-controlled bulk input — Review custom code that uses hash_init('sha3-*') and hash_update() on untrusted uploads, archives, or streams. Where possible, move that work out of request paths or replace the pattern during normal remediation planning; again, no mitigation SLA for a MEDIUM finding.
3. Enforce upload and request ceilings — Keep tight reverse-proxy body limits, PHP upload_max_filesize, post_max_size, memory_limit, and worker timeouts. These do not 'fix' the bugs, but they add practical friction against the large crafted inputs used in public SHA-3 reproductions and reduce crash surface.
4. Prefer supported distro backports or newer runtimes — If you cannot retire PHP 7.4 immediately, use a vendor-supported package stream with documented backports instead of frozen upstream tarballs. That reduces both this advisory and the much larger strategic risk of running an upstream-EOL runtime.

Run this on the target Linux host that executes PHP, not from an auditor workstation. Save as check_php_166901.sh, then run bash check_php_166901.sh /usr/bin/php or simply bash check_php_166901.sh to use php from PATH; no root is required, but the script needs permission to execute the local PHP binary and query package metadata if present.

#!/usr/bin/env bash
# check_php_166901.sh
# Purpose: assess exposure to Tenable plugin 166901 (PHP 7.4.x < 7.4.33)
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

PHP_BIN="${1:-php}"

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

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

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

if ! have_cmd "$PHP_BIN"; then
  echo "UNKNOWN"
  exit 2
fi

PHP_VERSION_RAW="$($PHP_BIN -r 'echo PHP_VERSION;' 2>/dev/null || true)"
if [ -z "$PHP_VERSION_RAW" ]; then
  echo "UNKNOWN"
  exit 2
fi

# Normalize versions like 7.4.33-1ubuntu1 to the leading semantic portion.
PHP_VERSION="$(printf '%s' "$PHP_VERSION_RAW" | sed -E 's/^([0-9]+\.[0-9]+\.[0-9]+).*/\1/')"
BRANCH="$(printf '%s' "$PHP_VERSION" | awk -F. '{print $1 "." $2}')"

# This script is scoped to plugin 166901 only.
if [ "$BRANCH" != "7.4" ]; then
  echo "UNKNOWN"
  exit 2
fi

# If the runtime itself reports 7.4.33+, this advisory is fixed.
if ver_ge "$PHP_VERSION" "7.4.33"; then
  echo "PATCHED"
  exit 0
fi

# Check whether this may be a distro backport situation.
PKG_HINT=""
if have_cmd dpkg-query; then
  PKG_HINT="$(dpkg-query -W -f='${Package} ${Version}\n' 'php7.4*' 2>/dev/null | head -n 5 || true)"
elif have_cmd rpm; then
  PKG_HINT="$(rpm -qa 2>/dev/null | grep -E '^php(|74|7\.4)(-|$)' | head -n 5 || true)"
fi

# If package metadata itself clearly contains 7.4.33, treat as patched backport/package.
if printf '%s' "$PKG_HINT" | grep -q '7\.4\.33'; then
  echo "PATCHED"
  exit 0
fi

# Otherwise a 7.4.0-7.4.32 runtime is vulnerable if not obviously backported.
# Because distros sometimes backport security fixes without changing the runtime version,
# package-managed installs with ambiguous metadata are marked UNKNOWN instead of VULNERABLE.
if [ -n "$PKG_HINT" ]; then
  echo "UNKNOWN"
  exit 2
fi

echo "VULNERABLE"
exit 1

Sources

1. Tenable plugin 166901
2. PHP 7.4.33 release announcement
3. PHP 7 changelog 7.4.33
4. NVD CVE-2022-37454
5. NVD CVE-2022-31630
6. PHP bug #81738 hash_update() overflow reproducer
7. Zend advisory for CVE-2022-31630
8. NIST paper on SHA-3 buffer overflow