This is a spare key hidden under a doormat that only exists if your developers put it there
CVE-2006-1014 is not a generic 'PHP is remotely exploitable' issue. It is an *argument injection* flaw in mb_send_mail() on old PHP 4.x/5.x builds when the application passes attacker-controlled data into the additional_parameters argument and PHP is configured to invoke a local sendmail-style binary. In that narrow case, an attacker can smuggle sendmail flags like -C and -X to read or create files. Upstream and distro evidence points to fixes in the old branch lineage such as PHP 4.4.2 / 5.1.4, with distro backports and package-specific fixed builds later than that.
paragraphs
3 steps from start to impact.
Find a mail-sending endpoint that exposes the 5th argument
mb_send_mail() and forwards user input into additional_parameters. In practice this is a *code-pattern bug* in the application, not a generic network-reachable PHP daemon flaw. Typical tooling is just curl or Burp Suite to exercise the form.- A web application on the host actually uses
mb_send_mail() - User-controlled input reaches the
additional_parametersargument - The vulnerable PHP runtime is old enough to still honor the unsafe behavior
- Most applications never expose the 5th argument to user input
- Many modern apps use SMTP libraries or mail APIs instead of
mb_send_mail() - A version-only scanner cannot prove the vulnerable code path exists
17716 is banner/version-based and flags the runtime, not the presence of a reachable unsafe mb_send_mail(..., ..., ..., ..., $user_input) call.Inject extra sendmail flags
-C and -X so PHP passes them to the local mail transport. The offensive 'tool' here is still just the application's own mail-sending path plus sendmail semantics.- PHP is configured to use a local
sendmail-compatible binary - The application does not sanitize or hardcode
additional_parameters
- Hosts using SMTP relays, API mailers, or wrappers that ignore these flags break the chain
- Quoting, escaping, or app-side validation commonly kills payload reliability
mb_send_mail usage; perimeter scanners generally cannot validate exploitability without a live vulnerable form.Abuse sendmail to create or read files
- Filesystem paths are writable/readable by the effective PHP/sendmail user
- The mail transport accepts the attacker-supplied flags as intended
- Impact is bounded by local file permissions
- Many deployments will only allow low-privilege writes, not system takeover
- Operational noise from broken mail delivery can reveal testing
sendmail invocations, unexpected -X usage, weird mail logs, and file creation under web/mail service accounts.The supporting signals.
| In-the-wild status | No evidence of current mass exploitation found; not listed in CISA KEV. |
|---|---|
| Proof-of-concept availability | Public advisory details have existed since 2006, including Bugtraq/Secunia-era references cited by NVD and Tenable. That means the technique is *well understood*, even if modern weaponization interest is low. |
| EPSS | Observed in public trackers as roughly 0.02326 (2.326%); low-to-middling probabilistic interest, but that overstates enterprise urgency because exploitability depends on an app-specific coding mistake. |
| KEV status | Not in KEV as of the current CISA catalog page reviewed. |
| CVSS vector | AV:L/AC:L/Au:S/C:P/I:P/A:N in CVSS v2 / Tenable. That old vector already hints this is *not* a clean unauthenticated remote infrastructure bug. |
| Affected versions | NVD describes certain PHP 4.x and 5.x applications; Tenable keys off remote PHP versioning, while the real precondition is unsafe mb_send_mail() usage with sendmail. |
| Fixed versions | Upstream/package evidence points to fixes in the old train around PHP 4.4.2 / 5.1.4, with distro/package backports such as Ubuntu 5.1.6-1ubuntu2.6 and 5.2.1-0ubuntu1.4, and Debian php5 5.1.4-0.1. |
| Scanning and exposure reality | This is not Shodan-friendly exposure. Internet scans can find old PHP banners; they cannot determine whether the application forwards attacker input into additional_parameters, so exposure counts materially overstate risk. |
| Disclosure date | 2006-03-07 public CVE publication; Tenable lists vulnerability publication on 2006-02-28. |
| Researcher / reporting | Original public reporting traces back to the 2006 Bugtraq thread referenced by NVD/Tenable; modern records do not cleanly preserve a single authoritative researcher attribution. |
noisgate verdict.
The decisive downgrade pressure is that exploitation requires a *second bug*: an application must pass attacker-controlled input into mb_send_mail()'s additional_parameters field. Without that code smell, a legacy PHP version banner alone is not a practical attack path, so this does not behave like a remotely exploitable platform flaw at enterprise scale.
Why this verdict
- Requires vulnerable application logic: the attacker does *not* win by reaching PHP alone; they need a reachable code path that forwards untrusted data into the 5th
mb_send_mail()parameter. That sharply narrows real-world exposure compared with a normal remote service bug. - Requires a specific mail transport model: the chain depends on PHP invoking a local
sendmail-compatible binary and honoring injected flags. Environments using SMTP libraries, API mailers, or hardened wrappers fall out of scope immediately. - Impact is bounded: the described outcome is arbitrary file read/create in the context of the web/mail service account, not turnkey unauthenticated RCE. That keeps blast radius and operator urgency down.
Why not higher?
This is not a broad pre-auth network exploit against the PHP runtime. It is a conditional abuse path that assumes old PHP, vulnerable app code, and a specific mail transport arrangement all line up; each prerequisite compounds downward pressure on severity.
Why not lower?
It is still a real weakness when those conditions exist, and legacy PHP estates do exist. If an internet-facing form really forwards user input into additional_parameters, an external attacker can tamper with local files without prior host access, so fully ignoring the issue would be too generous.
What to do — in priority order.
- Grep for risky
mb_send_mailusage — Search application code formb_send_mail(calls that populate the 5th argument from variables or request data. For a LOW finding, there is no SLA (treat as backlog hygiene), but this is the fastest way to separate noise from a genuinely exposed legacy app. - Hardcode or remove
additional_parameters— If the application still usesmb_send_mail(), make the 5th argument a constant safe value or remove it entirely. Do this in the normal backlog flow because the LOW bucket has no formal mitigation SLA. - Prefer SMTP libraries or mail APIs — Move mail delivery to libraries that do not shell out to local
sendmailwith caller-controlled arguments. That permanently breaks the exploit chain and fits standard modernization work for a LOW issue. - Retire legacy PHP runtimes — Any host old enough for this CVE is likely carrying many worse problems than this one. Fold it into legacy runtime retirement and package refresh as backlog hygiene under the LOW remediation posture.
WAF-onlyprotection is weak here because the dangerous behavior is an internal application-to-mailer call pattern, not a stable single HTTP signature.Version-based exception closurewithout code review does not prove safety if the app has custom mail wrappers or backported packages; you need to verify runtime plus code path.MFAis irrelevant because this is not an identity attack path.
Crowdsourced verification payload.
Run this on the target Linux host as a user that can execute php and read the relevant application directories; root is helpful but not strictly required. Invoke it as bash verify_cve_2006_1014.sh /var/www /srv/www to scan likely web roots; it will print VULNERABLE, PATCHED, or UNKNOWN based on PHP version, mail transport, and whether it finds suspicious mb_send_mail() usage.
#!/usr/bin/env bash
# verify_cve_2006_1014.sh
# Check likely exposure to CVE-2006-1014 / Tenable plugin 17716
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -u
if ! command -v php >/dev/null 2>&1; then
echo "UNKNOWN: php CLI not found"
exit 2
fi
PHP_VERSION_RAW="$(php -r 'echo PHP_VERSION;' 2>/dev/null)"
if [ -z "$PHP_VERSION_RAW" ]; then
echo "UNKNOWN: unable to determine PHP version"
exit 2
fi
SENDMAIL_PATH="$(php -r 'echo (string) ini_get("sendmail_path");' 2>/dev/null)"
if [ -z "$SENDMAIL_PATH" ]; then
SENDMAIL_PATH="(empty)"
fi
# Very old upstream fixed points commonly referenced for this issue.
# Note: distro backports may make version-only checks pessimistic.
php -r '
$v = PHP_VERSION;
function lt($a,$b){ return version_compare($a,$b,"<"); }
if (preg_match("/^4\./", $v)) {
exit(lt($v,"4.4.2") ? 10 : 0);
}
if (preg_match("/^5\./", $v)) {
exit(lt($v,"5.1.4") ? 10 : 0);
}
exit(0);
' >/dev/null 2>&1
VER_RC=$?
VERSION_STATE="patched-or-newer"
if [ "$VER_RC" -eq 10 ]; then
VERSION_STATE="legacy-vulnerable-range"
fi
SEARCH_DIRS="$*"
if [ -z "$SEARCH_DIRS" ]; then
for d in /var/www /srv/www /usr/share/nginx/html /opt /home; do
[ -d "$d" ] && SEARCH_DIRS="$SEARCH_DIRS $d"
done
fi
FOUND_CALLS=0
FOUND_RISKY=0
TMP_OUT="$(mktemp 2>/dev/null || echo /tmp/cve_2006_1014.$$)"
: > "$TMP_OUT"
for d in $SEARCH_DIRS; do
[ -d "$d" ] || continue
grep -RInE --include='*.php' 'mb_send_mail\s*\(' "$d" 2>/dev/null >> "$TMP_OUT" || true
grep -RInE --include='*.php' 'mb_send_mail\s*\([^\)]*,[^\)]*,[^\)]*,[^\)]*,\s*\$' "$d" 2>/dev/null >> "$TMP_OUT.risky" || true
grep -RInE --include='*.php' 'mb_send_mail\s*\([^\)]*,[^\)]*,[^\)]*,[^\)]*,\s*(\$_GET|\$_POST|\$_REQUEST|\$_COOKIE|\$_SERVER)' "$d" 2>/dev/null >> "$TMP_OUT.risky" || true
done
if [ -s "$TMP_OUT" ]; then
FOUND_CALLS=1
fi
if [ -s "$TMP_OUT.risky" ]; then
FOUND_RISKY=1
fi
USES_SENDMAIL=0
case "$SENDMAIL_PATH" in
*sendmail*|*postfix*|*exim*|*msmtp*) USES_SENDMAIL=1 ;;
esac
if [ "$VERSION_STATE" = "legacy-vulnerable-range" ] && [ "$USES_SENDMAIL" -eq 1 ] && [ "$FOUND_RISKY" -eq 1 ]; then
echo "VULNERABLE: PHP $PHP_VERSION_RAW in legacy range, sendmail_path='$SENDMAIL_PATH', risky mb_send_mail() usage found"
rm -f "$TMP_OUT" "$TMP_OUT.risky"
exit 1
fi
if [ "$VERSION_STATE" = "patched-or-newer" ] && [ "$FOUND_RISKY" -eq 0 ]; then
echo "PATCHED: PHP $PHP_VERSION_RAW is outside common vulnerable upstream range and no risky mb_send_mail() usage was found"
rm -f "$TMP_OUT" "$TMP_OUT.risky"
exit 0
fi
if [ "$VERSION_STATE" = "legacy-vulnerable-range" ] && [ "$FOUND_CALLS" -eq 0 ]; then
echo "UNKNOWN: PHP $PHP_VERSION_RAW is in a legacy range, but no mb_send_mail() calls were found in scanned paths; check other code locations and package backports"
rm -f "$TMP_OUT" "$TMP_OUT.risky"
exit 2
fi
if [ "$VERSION_STATE" = "legacy-vulnerable-range" ] && [ "$USES_SENDMAIL" -eq 0 ]; then
echo "UNKNOWN: legacy PHP version detected, but sendmail_path='$SENDMAIL_PATH' does not clearly indicate a vulnerable local sendmail-style transport"
rm -f "$TMP_OUT" "$TMP_OUT.risky"
exit 2
fi
if [ "$FOUND_RISKY" -eq 1 ]; then
echo "UNKNOWN: risky mb_send_mail() pattern found, but runtime/package state needs manual validation (backports possible)"
rm -f "$TMP_OUT" "$TMP_OUT.risky"
exit 2
fi
echo "UNKNOWN: partial evidence only; PHP=$PHP_VERSION_RAW sendmail_path='$SENDMAIL_PATH' mb_send_mail_calls=$FOUND_CALLS risky_calls=$FOUND_RISKY"
rm -f "$TMP_OUT" "$TMP_OUT.risky"
exit 2
If you remember one thing.
17716. First, have app owners or SAST confirm whether any internet-facing legacy PHP app passes user input into mb_send_mail()'s 5th argument; if none do, document the exception and close it as low-priority noise. For a LOW verdict, the noisgate mitigation SLA is no SLA (treat as backlog hygiene), and the noisgate remediation SLA is likewise backlog hygiene—so fold actual fixes into normal legacy-PHP retirement and package-refresh work rather than incident-style patching.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.