Roundcube Webmail 1

CVE-2026-48844 is a server-side code injection flaw in Roundcube Webmail's LDAP address book handling. In vulnerable releases, add_autovalues() in rcube_ldap.php could eval() expressions from the LDAP autovalues configuration when a contact record was created, which is why Roundcube removed code-evaluation support entirely in 1.6.16 and 1.7.1. The affected range is Roundcube Webmail 1.6.x before 1.6.16 and 1.7.x before 1.7.1, disclosed on 2026-05-25.

The vendor's 7.5/HIGH score is technically defensible if you assume an attacker already has a valid Roundcube account and the target actually uses a writable LDAP address book with autovalues logic reachable in production. In real enterprises, those are serious friction points: many Roundcube deployments use LDAP read-only for lookup, not contact creation, and many users never touch LDAP-backed address book creation at all. So this is not an unauthenticated edge-service RCE; it's a niche, post-login path on a public-facing product.

Why this verdict

• Downgrade for attacker position: the vendor baseline starts at 7.5, but PR:L is not cosmetic here; it means the attacker already has a valid Roundcube session on a public-facing mail system.
• Downgrade for exposure population: the vulnerable path appears tied to LDAP-backed address book creation with autovalues, which is a much smaller subset than 'all Roundcube on the internet.'
• Downgrade for operational friction: many enterprises use LDAP/AD as a read-only directory source, and modern controls like SSO, MFA, EDR, and web telemetry should catch or constrain the chain before it becomes server-side code execution.

Why not higher?

This is not unauthenticated remote exploitation, and it is not a default-path request smuggling issue that every internet scanner can hit in minutes. The chain is feature- and configuration-dependent, and every prerequisite compounds downward pressure: valid account, LDAP write capability, and a vulnerable autovalues setup.

Why not lower?

Once the chain is present, the impact is still serious because the sink is server-side code execution in a public-facing webmail application. Roundcube is widely exposed, and any authenticated foothold on external mail infrastructure deserves respect even when the vulnerable subfeature is narrow.

1. Disable writable LDAP address books where you can — If the business does not require LDAP contact creation, set those sources read-only or remove them. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this is the cleanest risk reduction if patching is delayed.
2. Remove or avoid LDAP autovalues expressions — The vulnerable behavior lives in the old code-evaluation support for autovalues; strip those templates from local config if they exist. There is no mitigation SLA for this severity bucket, so treat it as an optional hardening measure while you plan the vendor upgrade.
3. Tighten mailbox auth paths — Enforce MFA/SSO, monitor suspicious Roundcube logins, and review service accounts or shared mailboxes. The most reliable break in this chain is before the attacker ever becomes an authenticated user.
4. Watch for web-to-shell behavior on the Roundcube host — Tune EDR to alert when the PHP/web server account spawns shells, downloaders, archive tools, or interpreters. That does not remove the bug, but it sharply reduces dwell time if someone reaches the eval() sink.

Run this on the Roundcube host as a user that can read the install directory and config, typically root or the webapp admin account. Invoke it as bash rc_check_cve_2026_48844.sh /var/www/roundcube; it needs only local read access and prints VULNERABLE, PATCHED, or UNKNOWN.

#!/usr/bin/env bash
# Check Roundcube for CVE-2026-48844
# Usage: bash rc_check_cve_2026_48844.sh /path/to/roundcube
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN, 3=usage/error

set -u

RC_PATH="${1:-}"
if [[ -z "$RC_PATH" || ! -d "$RC_PATH" ]]; then
  echo "UNKNOWN: provide Roundcube install path, e.g. /var/www/roundcube" >&2
  exit 3
fi

VERSION=""
if [[ -f "$RC_PATH/program/lib/Roundcube/bootstrap.php" ]]; then
  VERSION=$(grep -Eo "'\s*[0-9]+\.[0-9]+\.[0-9]+'" "$RC_PATH/program/lib/Roundcube/bootstrap.php" 2>/dev/null | head -n1 | tr -d "' " )
fi
if [[ -z "$VERSION" && -f "$RC_PATH/index.php" ]]; then
  VERSION=$(grep -Eo "[0-9]+\.[0-9]+\.[0-9]+" "$RC_PATH/index.php" 2>/dev/null | head -n1)
fi
if [[ -z "$VERSION" && -f "$RC_PATH/composer.json" ]]; then
  VERSION=$(grep -Eo '"version"\s*:\s*"[0-9]+\.[0-9]+\.[0-9]+"' "$RC_PATH/composer.json" 2>/dev/null | head -n1 | grep -Eo '[0-9]+\.[0-9]+\.[0-9]+')
fi

vuln_version=0
if [[ -n "$VERSION" ]]; then
  if [[ "$VERSION" =~ ^1\.6\. ]]; then
    if [[ "$(printf '%s\n' "$VERSION" "1.6.16" | sort -V | head -n1)" != "1.6.16" ]]; then
      vuln_version=1
    fi
  elif [[ "$VERSION" =~ ^1\.7\. ]]; then
    if [[ "$(printf '%s\n' "$VERSION" "1.7.1" | sort -V | head -n1)" != "1.7.1" ]]; then
      vuln_version=1
    fi
  fi
fi

LDAP_FILE="$RC_PATH/program/lib/Roundcube/rcube_ldap.php"
if [[ ! -f "$LDAP_FILE" ]]; then
  echo "UNKNOWN: rcube_ldap.php not found" >&2
  exit 2
fi

has_eval=0
if grep -Fq 'eval("return ($code);")' "$LDAP_FILE" 2>/dev/null; then
  has_eval=1
fi

cfg_autovalues=0
cfg_writable=0
shopt -s nullglob
for f in "$RC_PATH"/config/*.php "$RC_PATH"/*.inc.php; do
  [[ -f "$f" ]] || continue
  if grep -Eq "['\"]autovalues['\"]\s*=>" "$f" 2>/dev/null; then
    cfg_autovalues=1
  fi
  if grep -Eq "['\"]writable['\"]\s*=>\s*true" "$f" 2>/dev/null; then
    cfg_writable=1
  fi
done
shopt -u nullglob

if [[ $vuln_version -eq 0 && $has_eval -eq 0 ]]; then
  echo "PATCHED: installed code does not show the vulnerable eval path"
  exit 0
fi

if [[ $has_eval -eq 1 && $vuln_version -eq 1 && $cfg_autovalues -eq 1 && $cfg_writable -eq 1 ]]; then
  echo "VULNERABLE: vulnerable version/code path present and local config suggests writable LDAP autovalues are enabled"
  exit 1
fi

if [[ $has_eval -eq 1 && $vuln_version -eq 1 ]]; then
  echo "UNKNOWN: vulnerable version/code path present, but local config did not clearly confirm writable LDAP autovalues"
  exit 2
fi

if [[ $has_eval -eq 1 && -z "$VERSION" ]]; then
  echo "UNKNOWN: vulnerable eval path present but version could not be determined"
  exit 2
fi

echo "UNKNOWN: inconclusive result"
exit 2

Sources

1. Roundcube security updates 1.6.16 and 1.7.1
2. Roundcube fix commit removing LDAP autovalues eval
3. Roundcube 1.6.16 release
4. Roundcube 1.7.1 release
5. Roundcube LDAP address books configuration wiki
6. Roundcube plugin hooks wiki
7. CERT-FR Roundcube advisory
8. Censys Roundcube exposure baseline advisory