CVE-2026-79387: SQL-Injection im Benutzerverwaltungsmodul von PbootCMS V3.2.5

Übersicht

Feld	Detail
CVE-ID	CVE-2026-79387
Produkt	PbootCMS
Betroffene Versionen	3.2.0 – 3.2.5, und möglicherweise früher
Schwachstellentyp	SQL-Injection (CWE-89)
Angriffsvektor	Remote (Authentifiziert)
CVSS-Schweregrad	Hoch
Entdecker	JiahaoLi
Hersteller	https://www.pbootcms.com/

Beschreibung der Schwachstelle

Im Benutzerverwaltungsmodul von PbootCMS V3.2.5 existiert eine SQL-Injection-Schwachstelle. Die Schwachstelle befindet sich in der Methode mod() von /apps/admin/controller/system/UserController.php (Zeile 149) und in der Methode modUser() von /apps/admin/model/system/UserModel.php.

Der Parameter field ist vollständig vom Benutzer über eine GET-Anfrage kontrollierbar, ohne jegliche Whitelist-Validierung. Der Parameter value ist ebenso vom Benutzer kontrollierbar und wird direkt in die SQL-UPDATE-Anweisung eingefügt. Ein authentifizierter Angreifer kann eine beliebige Datenbankspalte als field angeben (z. B. password, username, status, role), was eine beliebige Datenmanipulation ermöglicht.

Ursache

// UserController.php - mod() method
if (($field = get('field', 'var')) && ! is_null($value = get('value', 'var'))) {
    if ($this->model->modUser($ucode, "$field='$value',update_user='" . session('username') . "'")) {
        location(- 1);
    }
}

$field und $value werden direkt aus der $_GET-Superglobalen entnommen und ohne Bereinigung, ohne Whitelist und ohne parametrisierte Abfrage in einen SQL-String konkateniert. Dieser String wird dann an UserModel::modUser() übergeben, das ihn an die Basis-Methode Model::update() weiterleitet. Da das Argument ein String ist (kein Array), umgeht es die Feldnamen-Validierung von checkKey() und wird wörtlich in die SET-Klausel eingebettet:

UPDATE ay_user SET <user-controlled>= '<user-controlled>', update_user='admin' WHERE ucode='<ucode>'

Aufrufkette

GET /admin.php?p=/User/mod&ucode=10002&field=password&value=<MD5>
  → UserController::mod()
    → UserModel::modUser($ucode, "password='<value>',update_user='admin'")
      → Model::table('ay_user')->where("ucode='$ucode'")->update($data_string)
        → SQL: UPDATE ay_user SET password='<value>',update_user='admin' WHERE ucode='10002'

Auswirkung

Ein authentifizierter Angreifer kann:

1. Das Passwort jedes Benutzers ändern — einschließlich des Superadministrators (außer dem integrierten Gründer ucode=10001).
2. Den Kontostatus ändern — beliebige Konten aktivieren oder deaktivieren.
3. Tiefergehendes SQL injizieren — der Parameter value erlaubt das Escapen von einfachen Anführungszeichen, was potenziell gestapelte oder tautologiebasierte Angriffe ermöglicht.

Dies führt zur Übernahme von Konten und zur vollständigen Kontrolle über das CMS-Backend.

Reproduktionsschritte

Voraussetzungen

• PbootCMS V3.2.5 lokal installiert (getestet auf 192.168.1.104, Apache/PHP 7.2.1/SQLite)
• Ein gültiges Backend-Administratorkonto

Schritt 1: Anmeldung am Admin-Panel

Rufen Sie das PbootCMS-Admin-Dashboard auf und melden Sie sich mit dem Standardkonto admin an.

Schritt 2: Einen Zielbenutzer erstellen

Navigieren Sie zu Systemverwaltung → Benutzerverwaltung → Benutzer hinzufügen. Erstellen Sie einen neuen Benutzer:

• Benutzername: admin2
• Passwort: admin
• Rolle: Systemadministrator

Schritt 3: Überprüfen, ob der Benutzer existiert

Die Benutzerliste bestätigt admin2 mit ucode=10002:

Schritt 4: Anfangspasswort bestätigen

Öffnen Sie ein neues Browserfenster. Versuchen Sie, sich als admin2 mit dem Passwort 123456 anzumelden — dies schlägt fehl, da das tatsächliche Passwort admin lautet:

Schritt 5: Den Payload erstellen und ausführen

Navigieren Sie mit dem bereits angemeldeten Admin-Browser zu:

http://192.168.1.104/PbootCMS/admin.php?p=/User/mod&ucode=10002&field=password&value=14e1b600b1fd579f47433b88e8d85291

14e1b600b1fd579f47433b88e8d85291 ist der MD5-Hash von 123456.

Die Methode mod() führt die Injection aus und leitet über location(-1) weiter:

Schritt 6: Passwortänderung überprüfen

Versuchen Sie nun, sich mit admin2 / 123456 anzumelden:

Das Passwort wurde erfolgreich über SQL-Injection geändert. Der Benutzer ist jetzt mit dem neuen Passwort angemeldet, was die vollständige Kontoübernahme bestätigt.

Quellcode-Analyse

Verwundbarer Code (UserController.php, Zeile ~149)

Datenbankschicht (Model.php - update-Methode)

Wenn update() ein String-Argument erhält, wird es unverändert in der SET-Klausel verwendet, ohne jegliche Escaping:

final public function update($data = null)
{
    if (is_array($data)) {
        // Array path: checkKey() validates field names
        ...
    } else {
        // String path: NO VALIDATION AT ALL
        $update_string = $data;
    }
    $this->sql['value'] = $update_string;
    $sql = $this->buildSql($this->updateSql);
    return $this->getDb()->amd($sql);  // Direct execution, no prepared statement
}

Behebung

1. Whitelist-Validierung des field-Parameters — nur bekannte Spaltennamen zulassen (status, username, realname, password).
2. Parametrisierte Abfragen — Prepared Statements anstelle von String-Verkettung verwenden.
3. Benutzereingaben escapen — mindestens $value bereinigen, um Quote-Breakout zu verhindern.
4. Passwort-Hashing erzwingen — wenn field gleich password ist, encrypt_string() auf den Wert vor der Speicherung anwenden.
5. Den Standalone-Modify-Pfad einschränken — der Zweig „single field modify" in mod() sollte ein gültiges CSRF-Token und eine rollenbasierte Autorisierungsprüfung erfordern.

Referenzen

• PbootCMS Offizielle Website
• PbootCMS Quellcode auf Gitee
• CVE-2026-79387

---