CVE-2026-11585 · CodeAstro Student Attendance Management System createClassArms.php…

01 · The Real Story

A back-office ledger left unlocked after the front door is closed

The vulnerability is an SQL injection in the classId parameter of /attendance-php/Admin/createClassArms.php in CodeAstro Student Attendance Management System 1.0. An authenticated low-privilege user can tamper with the parameter to inject SQL, potentially reading or modifying database records behind the application.

CodeAstro is a code-marketplace project commonly used for demos and coursework, not an enterprise attendance platform. The vendor MEDIUM severity of 6.3 overstates the realistic exposure: the bug requires valid application credentials and lands in a niche app with limited database impact. No active exploitation, KEV listing, or meaningful scanning has been observed.

"Authenticated SQLi in a niche school-attendance app: vendor MEDIUM is too high; treat as LOW backlog hygiene."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain a valid low-privilege account

The attacker needs to authenticate to the CodeAstro instance. This could be achieved via default credentials, self-registration if enabled, credential stuffing, or social engineering of a student/teacher account.

Conditions required:

Target instance is reachable over the network
Attacker can obtain or create a low-privilege account

Where this breaks in practice:

Typical deployments are internal-only and may not expose self-registration
Default credentials may be changed in production, though tutorials often leave them unchanged

Detection/coverage: Application auth logs may show anomalous logins or new account creation.

STEP 02

Reach the vulnerable Admin endpoint

The file /attendance-php/Admin/createClassArms.php is under an /Admin/ path. However, many CodeAstro tutorial apps do not enforce role checks consistently, or a low-privilege teacher account is allowed to create class arms. The attacker needs to reach this script with a valid session.

Conditions required:

Authenticated session exists
Endpoint is exposed and reachable

Where this breaks in practice:

If role enforcement is properly implemented, low-privilege users cannot access the Admin path
Server-side access controls may block direct script execution

Detection/coverage: Web server access logs show requests to createClassArms.php from unexpected users or IPs.

STEP 03

Inject SQL via the classId parameter

The attacker crafts a payload in the classId argument, such as 1' UNION SELECT ..., because the input is concatenated into a SQL query without parameterization. This can be exploited using error-based, UNION-based, or time-based blind SQL injection techniques.

Conditions required:

The classId parameter is not parameterized
The application reflects SQL errors or allows blind timing

Where this breaks in practice:

A WAF or input filter may block common SQLi patterns
Database user privileges may prevent certain injected operations

Detection/coverage: WAF rules, SQL error logs, or application logs may flag malformed classId values.

STEP 04

Extract or manipulate database records

With successful injection, the attacker can dump student records, alter attendance data, or potentially retrieve password hashes if stored in the same database. The impact is scoped to the application's own database and does not directly extend to the host or domain.

Conditions required:

Database user has read and possibly write access to relevant tables
Application connects to a database containing sensitive data

Where this breaks in practice:

Least-privilege DB accounts limit the tables and operations available
Network segmentation may restrict the database to the web server only

Detection/coverage: Database audit logs may show unusual query patterns or bulk SELECTs.

03 · Compensating Control

LOW 3.5→LOW 2.5

Remove public exposure and put the app behind VPN/SSO — Restrict access to /attendance-php/Admin to internal network or VPN. No mitigation SLA for LOW, but treat as backlog hygiene before the 365-day remediation window closes. This breaks the remote attack path for internet attackers.

LOW 3.5→IGNORE 0.0

SEVERITY REDUCED

Apply vendor patch or replace with a maintained attendance platform — No patched version is documented for CodeAstro 1.0; remediation should be replacement or decommission within 365 days if the app remains in use. This removes the vulnerable code entirely.

LOW 3.5→LOW 3.0

Enforce least-privilege database account — Ensure the web app's DB user lacks DDL/drop and can only access necessary tables; limits SQLi impact but does not stop injection. Use now as a hardening step.

LOW 3.5→LOW 2.8

Deploy a WAF rule blocking SQLi patterns on classId — A WAF can block common UNION/boolean/time-based SQLi payloads on the classId parameter. Not a permanent fix but will stop opportunist public exploit attempts.

What doesn't work

Generic OS/host patching does not fix application-layer SQLi.
Database encryption at rest does not prevent SQL injection extraction of plaintext query results.
MFA alone does not stop an attacker who already holds a valid low-privilege session.
Rate limiting/account lockout is ineffective against low-volume targeted SQLi.

04 · Intelligence Metadata

The supporting signals.

In-the-wild status	No known campaigns; not listed in CISA KEV; no mass exploitation or GreyNoise scanning observed.
Proof-of-concept availability	Public exploit disclosed per CVE description; check pocindex.io and GitHub repos named after the CVE ID for PoCs.
EPSS score	0.002 — 0.2% probability of exploitation in the next 30 days.
KEV status	Not listed in CISA Known Exploited Vulnerabilities catalog.
CVSS vector	`CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L` — network vector, low complexity, low privilege, no user interaction, low confidentiality/integrity/availability impact.
Affected version range	CodeAstro Student Attendance Management System 1.0.
Fixed version	None publicly documented; product likely unmaintained.
Scanning/exposure data	No known internet-wide scanning; CodeAstro apps typically appear in small numbers on Shodan/Censys, often on demo or lab hosts.
Disclosure date	2026-06-08
Reporting researcher/org	Not specified in official record.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to LOW (3.5/10)

Why this verdict

Role multiplier: CodeAstro Student Attendance Management System is a low-value LOB app; even successful SQLi stops at the app database — no domain, identity, fleet, or supply-chain blast radius.
Friction audit: Requires a valid low-privilege account and access to an Admin-path endpoint; many implementations are internal-only and not self-registering.
Deployment reality: CodeAstro scripts are tutorial/coursework code with a tiny install base, rarely internet-exposed; no high-value-role floor applies.
Exploit intel: Public exploit exists but EPSS 0.002, no KEV listing, and no observed mass exploitation.

Why not higher?

Not pre-auth, impact scoped to a single web app database, no high-value-role blast radius, and no active exploitation. The affected product is not enterprise infrastructure; a critical or high rating would overstate the real-world exposure.

Why not lower?

It is remote, low complexity, and has a public exploit, so it cannot be ignored. If the app is internet-facing with weak credentials, skilled attackers can dump student PII and modify attendance records.

06 · Verification

Crowdsourced verification payload.

Run from an auditor workstation with network access to the target; requires curl and no special privileges. Invoke as ./check_cve-2026-11585.sh http://<host>/attendance-php.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-11585 verification for CodeAstro Student Attendance Management System 1.0
# Usage: ./check_cve-2026-11585.sh <target_base_url>
# Example: ./check_cve-2026-11585.sh http://school.example.com/attendance-php
set -euo pipefail
TARGET="${1:-}"
if [ -z "$TARGET" ]; then
  echo "usage: $0 <target_base_url>"
  exit 2
fi
TARGET="${TARGET%/}"
URL="${TARGET}/Admin/createClassArms.php"
echo "[*] Checking ${URL}"
response=$(curl -sk -o /tmp/cve_2026_11585.out -w "%{http_code}" "${URL}")
if [ "$response" = "200" ]; then
  if grep -qi "classId" /tmp/cve_2026_11585.out; then
    echo "VULNERABLE: endpoint reachable and classId parameter present; patch or restrict access."
    exit 1
  else
    echo "UNKNOWN: endpoint reachable but classId parameter not found in response; investigate manually."
    exit 3
  fi
elif [ "$response" = "404" ] || [ "$response" = "403" ]; then
  echo "PATCHED: endpoint not accessible (HTTP ${response})."
  exit 0
else
  echo "UNKNOWN: HTTP ${response}; could not determine status."
  exit 3
fi