PHP 7

Tenable plugin 161971 rolls up two PHP flaws fixed in 7.4.30: CVE-2022-31625 in the PostgreSQL extension and CVE-2022-31626 in pdo_mysql with the mysqlnd driver. Affected upstream ranges are PHP 7.4.0-7.4.29, plus parallel 8.0/8.1 ranges. The first bug needs attacker-controlled input to code paths using pg_query_params(). The second needs an application pattern where an untrusted party can influence the MySQL host and password, often by pointing PHP at a rogue MySQL server and sending an abnormally long password.

The vendor/NVD story overstates fleet-wide urgency if you manage thousands of ordinary PHP web nodes. Yes, the technical impact can be RCE, and public exploit material exists. But this is not a broad unauthenticated internet-to-RCE bug against 'any PHP site'; it is extension-specific, workflow-specific, and often requires an already-dangerous app design such as self-service DB connection forms or admin tools like Adminer/phpMyAdmin. That friction pulls this down from HIGH to a solid MEDIUM for most enterprises.

Why this verdict

• Down from vendor HIGH: the worst bug (CVE-2022-31626) needs pdo_mysql with mysqlnd *and* an app flow where an attacker can influence DB host and password, which is uncommon in ordinary public web apps
• More friction: CVE-2022-31625 requires PostgreSQL extension usage and a narrower bad-parameter path into pg_query_params(), so many PHP deployments are unaffected in practice even if the version is old
• Still not LOW: public exploit material exists, the bugs can cross into real RCE territory, and exposed DB admin tooling or self-service connection workflows materially amplify risk

Why not higher?

This is not a broad unauthenticated internet exploit against vanilla PHP request handling. The attack path compounds multiple prerequisites: the right extension, the right application behavior, and often attacker influence over backend connection details or edge-case parameter types. That sharply narrows reachable population and keeps it out of HIGH for most 10,000-host environments.

Why not lower?

Calling it LOW would ignore two important facts: the impact can be full code execution in the PHP worker context, and exploit information is public enough to be operationalized against the small set of apps that expose the right workflow. If you run internet-reachable DB admin consoles or custom 'test connection' features, this can move from theoretical to very real.

1. Map extension usage — Identify which hosts actually load pdo_mysql, mysqlnd, pgsql, or pdo_pgsql, and which apps expose DB connection testing or self-service login workflows. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but do this discovery early so you can locally escalate the truly exposed subset.
2. Restrict DB admin tools — Put Adminer, phpMyAdmin, phpPgAdmin, install wizards, and 'test DB connection' pages behind VPN, SSO, or strict source-IP allowlists. This cuts off the most plausible external path to CVE-2022-31626; for this MEDIUM case there is no mitigation SLA, but apply during normal hardening rather than waiting for the patch window to expire.
3. Disable unused PHP extensions — If a host does not need PostgreSQL or pdo_mysql/mysqlnd, remove or disable those modules. That removes the vulnerable code path entirely and is often faster than waiting on app-owner patch cycles; again, no mitigation SLA — go straight to the 365-day remediation window for the software fix.
4. Constrain outbound DB egress — Block web tiers from making arbitrary outbound MySQL/PostgreSQL connections except to approved database destinations. This is especially effective against the rogue-MySQL-server setup needed for CVE-2022-31626; apply as routine segmentation, not emergency response.
5. Validate connection inputs — If you own custom code that accepts user-supplied DB connection values, cap password length and prohibit arbitrary host selection. That does not replace patching, but it directly addresses the exploit precondition the Ambionics report described.

Run this on the target Linux/PHP host, not your scanner. Invoke it as bash check_php_7430.sh /usr/bin/php or just bash check_php_7430.sh if php is in PATH; root is not required, but the account must be able to execute the PHP CLI and read module/package metadata.

#!/usr/bin/env bash
# check_php_7430.sh
# Verify exposure to PHP 7.4.x < 7.4.30 issues covered by Tenable 161971
# Outputs one of: 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() { [ "$(printf '%s\n' "$2" "$1" | sort -V | head -n1)" = "$2" ]; }
ver_lt() { [ "$1" != "$2" ] && [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ]; }

if ! have_cmd "$PHP_BIN"; then
  echo "UNKNOWN - php binary not found: $PHP_BIN"
  exit 2
fi

PHP_VER="$($PHP_BIN -r 'echo PHP_MAJOR_VERSION,".",PHP_MINOR_VERSION,".",PHP_RELEASE_VERSION;' 2>/dev/null)"
if [ -z "$PHP_VER" ]; then
  echo "UNKNOWN - unable to query PHP version"
  exit 2
fi

MODULES="$($PHP_BIN -m 2>/dev/null | tr '[:upper:]' '[:lower:]')"
PHPINFO_LINE="$($PHP_BIN -i 2>/dev/null | grep -i '^client api version => mysqlnd' | head -n1)"

has_pdo_mysql=0
has_mysqlnd=0
has_pgsql=0
has_pdo_pgsql=0

echo "$MODULES" | grep -qx 'pdo_mysql' && has_pdo_mysql=1
echo "$MODULES" | grep -qx 'mysqlnd' && has_mysqlnd=1
echo "$MODULES" | grep -qx 'pgsql' && has_pgsql=1
echo "$MODULES" | grep -qx 'pdo_pgsql' && has_pdo_pgsql=1
[ -n "$PHPINFO_LINE" ] && has_mysqlnd=1

PKG_NOTE=""
if have_cmd dpkg-query; then
  PKG_NOTE="$(dpkg-query -W -f='${Package} ${Version}\n' 'php7.4*' 2>/dev/null | paste -sd ';' -)"
elif have_cmd rpm; then
  PKG_NOTE="$(rpm -qa 2>/dev/null | grep -Ei '^php(|74|7\.4|74-)' | paste -sd ';' -)"
fi

# This plugin is specifically for 7.4.x < 7.4.30.
# Same CVEs also affect 8.0/8.1, but those belong to different checks/advisories.
if [[ ! "$PHP_VER" =~ ^7\.4\. ]]; then
  echo "UNKNOWN - installed PHP is $PHP_VER; Tenable 161971 specifically targets PHP 7.4.x < 7.4.30. Packages: ${PKG_NOTE:-none}"
  exit 2
fi

if ver_ge "$PHP_VER" "7.4.30"; then
  echo "PATCHED - PHP version is $PHP_VER (>= 7.4.30). Packages: ${PKG_NOTE:-none}"
  exit 0
fi

# Version is vulnerable upstream. Now assess whether the relevant extensions are present.
if [ $has_pdo_mysql -eq 1 ] && [ $has_mysqlnd -eq 1 ]; then
  echo "VULNERABLE - PHP $PHP_VER with pdo_mysql + mysqlnd loaded; matches CVE-2022-31626 exposure preconditions. Packages: ${PKG_NOTE:-none}"
  exit 1
fi

if [ $has_pgsql -eq 1 ] || [ $has_pdo_pgsql -eq 1 ]; then
  echo "VULNERABLE - PHP $PHP_VER with PostgreSQL extension loaded; matches CVE-2022-31625 exposure preconditions. Packages: ${PKG_NOTE:-none}"
  exit 1
fi

echo "UNKNOWN - PHP $PHP_VER is below 7.4.30, but the relevant extensions were not detected in this CLI context. Re-check the exact FPM/Apache SAPI config. Packages: ${PKG_NOTE:-none}"
exit 2

Sources

1. Tenable Nessus Plugin 161971
2. PHP 7.4.30 Release Announcement
3. PHP bug 81719 / CVE-2022-31626
4. PHP bug 81720 / CVE-2022-31625
5. NVD CVE-2022-31626
6. NVD CVE-2022-31625
7. Debian DSA-5179-1 php7.4 security update
8. Gentoo GLSA 202209-20