Improper neutralization of CRLF sequences

The CRLF bug lives in pardus-update's privileged helper SystemSettingsWrite.py, which in vulnerable builds writes attacker-controlled values into /etc/pardus/pardus-update.conf without rejecting carriage returns. Primary-source code shows the affected range is 0.6.3 before 0.6.4, and the fix added integer validation before writing the lastupdate and lastupgrade fields. In practice, the injected \r can smuggle a new config key such as custom_sourcesd_path, which matters because other privileged update helpers later consume that config.

The vendor's HIGH 8.8 / AV:N framing does not match what the code path looks like in the real world. This is not a network daemon and not something Shodan is going to hand to an external attacker; it is a local GUI updater plus pkexec helper chain. Severity stays relevant because the same package also shipped permissive Polkit rules and an unsafe APT-source copy path, so on an affected Pardus host a local foothold can turn into root quickly, but that is still post-initial-access and materially narrower than the vendor baseline.

Why this verdict

• Vendor vector overstates reachability: the code path is a local pkexec helper chain, not an externally reachable web or auth service, so AV:N is not how defenders should triage it operationally.
• Requires prior foothold: the attacker needs local execution on a Pardus endpoint, which implies either a shared-user machine or an earlier compromise stage; that sharply reduces enterprise-wide exposure.
• Still root when the chain lines up: permissive Polkit rules plus CRLF config injection plus APT-source ingestion can end in full root on-host, so this is not backlog trivia.

Why not higher?

I am not scoring this HIGH because the reachable population is constrained twice: first by platform/package prevalence, then by the need for local execution before the bug matters. There is also no KEV signal, no confirmed active exploitation in the sources reviewed, and no evidence this is a broadly weaponized remote path.

Why not lower?

I am not pushing this to LOW because the exploit chain is straightforward on an affected box and ends in full administrative control of that host. On shared Linux desktops, labs, or any environment where an attacker can land a user shell, this is a clean privilege-escalation hop defenders should care about.

1. Harden the Polkit policy — Change the pardus-update Polkit actions away from permissive yes defaults so unprivileged users cannot launch the helper chain without admin approval. Because this verdict is MEDIUM, there is no mitigation SLA; use this as a risk reducer while you work inside the 365-day remediation window.
2. Watch the Pardus update config — Put file-integrity monitoring on /etc/pardus/pardus-update.conf and alert on unexpected keys such as custom_sourcesd_path or writes by unusual parent processes. There is no mitigation SLA here either, but this is cheap visibility to deploy during the remediation window.
3. Constrain APT source changes — Alert on or block unauthorized writes into /etc/apt/sources.list and /etc/apt/sources.list.d/, especially when the parent process is pkexec, python3, or AutoAptUpgrade.py. This breaks the most important privilege-escalation follow-on path.
4. Prioritize shared-user Linux estates — If you run teaching labs, kiosks, contractor workstations, jump boxes, or other multi-user Pardus endpoints, treat those as the real exposure subset because local-user-to-root matters most there. For MEDIUM, there is no mitigation SLA, but those systems deserve first attention inside the remediation window.

Run this on the target Pardus host as a normal user; no root is required for the version check, though root helps if your file permissions are unusually strict. Save it as check-pardus-cve-2026-5140.sh and run bash check-pardus-cve-2026-5140.sh.

#!/usr/bin/env bash
# check-pardus-cve-2026-5140.sh
# Detects whether pardus-update is vulnerable to CVE-2026-5140 based on package version
# and a secondary content check for the timestamp validation fix.
# Output: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -u

PKG="pardus-update"
FILE="/usr/share/pardus/pardus-update/src/SystemSettingsWrite.py"
VER=""

if ! command -v dpkg-query >/dev/null 2>&1; then
  echo "UNKNOWN: dpkg-query not found"
  exit 2
fi

if ! dpkg-query -W -f='${Version}' "$PKG" >/dev/null 2>&1; then
  echo "UNKNOWN: package '$PKG' is not installed or not queryable"
  exit 2
fi

VER="$(dpkg-query -W -f='${Version}' "$PKG" 2>/dev/null)"
if [ -z "$VER" ]; then
  echo "UNKNOWN: unable to determine package version"
  exit 2
fi

# Secondary signal: patched builds contain validate_timestamp().
HAS_FIX=0
if [ -r "$FILE" ] && grep -q 'def validate_timestamp' "$FILE" 2>/dev/null; then
  HAS_FIX=1
fi

# Affected range from primary-source advisory/NVD: 0.6.3 <= version < 0.6.4
if dpkg --compare-versions "$VER" ge 0.6.3 && dpkg --compare-versions "$VER" lt 0.6.4; then
  if [ "$HAS_FIX" -eq 1 ]; then
    echo "PATCHED: $PKG version $VER is in the nominal vulnerable range but the file contains the timestamp validation fix"
    exit 0
  else
    echo "VULNERABLE: $PKG version $VER is in the affected range and no fix marker was found"
    exit 1
  fi
fi

if dpkg --compare-versions "$VER" ge 0.6.4; then
  echo "PATCHED: $PKG version $VER is >= 0.6.4"
  exit 0
fi

if dpkg --compare-versions "$VER" lt 0.6.3; then
  echo "PATCHED: $PKG version $VER is below the affected range"
  exit 0
fi

echo "UNKNOWN: unable to classify $PKG version $VER"
exit 2

Sources

1. NVD CVE-2026-5140
2. Pardus Update upstream repository
3. Pardus Update changelog (raw)
4. Fix commit adding timestamp validation
5. Vulnerable SystemSettingsWrite.py (0.6.3 raw)
6. AutoAptUpgrade.py (0.6.3 raw)
7. Pardus Polkit policy file
8. Pardus 25.1 release notes