How I Found My First SQL Injection CVE — CVE-2026–37749

Introduction

My name is Varad AP Mene, an independent security researcher and bug hunter from India. Over the past few years I have been actively hunting vulnerabilities across the web and have successfully secured 100+ organizations including tech giants like NVIDIA, NASA, and many more through responsible disclosure.

Along with bug bounty hunting, I also research open source web applications for CVE discoveries. This is the story of how I discovered a critical SQL Injection vulnerability in CodeAstro Simple Attendance Management System 1.0, which was assigned CVE-2026–37749 by MITRE.

This vulnerability allows an unauthenticated attacker to completely bypass the login system and gain full admin access without any credentials. The CVE is now officially published on the CVE database at https://www.cve.org/CVERecord?id=CVE-2026-37749

If you are new to security research, I hope this writeup inspires you and shows that CVE hunting is achievable even as a beginner. Every expert was once a beginner. The key is consistency, curiosity, and responsible disclosure

What is a CVE?

A CVE (Common Vulnerabilities and Exposures) is a unique identifier assigned to a publicly known security vulnerability. CVEs are managed by MITRE and published on the National Vulnerability Database (NVD).

Having a CVE assigned to your name means you discovered a real, verified security vulnerability that affects real software used by real people. It is one of the most recognized achievements in the cybersecurity field.

The Target

CodeAstro is a website that publishes free PHP project source code for students and developers. Their projects are widely downloaded and used as learning resources in colleges and universities. This particular project is used to manage student attendance records in schools.

How I Found It

I was auditing open source PHP web applications looking for common vulnerabilities. I downloaded the Simple Attendance Management System and started reviewing the source code manually.

The first file I checked was index.php — the login form. This is always the most interesting file because authentication bypasses are high impact vulnerabilities.

On line 23, I found this code:

query="SELECT∗FROMadminWHEREusername=′query = "SELECT * FROM admin WHERE username=' query="SELECT∗FROMadminWHEREusername=′username' AND password='$password'"; result=mysqlquery(result = mysql_query( result=mysqlq​uery(query);

This is a classic SQL Injection vulnerability. The $username and $password variables come directly from $_POST without any sanitization or prepared statements.

Understanding the Vulnerability

To understand this vulnerability, we first need to understand how SQL queries work in login systems.

Normal Login Flow:

When a user enters username "admin" and password "admin123", the application builds this query:

SELECT * FROM admin WHERE username='admin' AND password='admin123'

MySQL checks the database. If a matching record exists, login succeeds. If not, login fails. This is the expected behavior.

What Goes Wrong:

The developer wrote this code:

$username = $_POST['username']; $password = $_POST['password']; query="SELECT∗FROMadminWHEREusername=′query = "SELECT * FROM admin WHERE username=' query="SELECT∗FROMadminWHEREusername=′username' AND password='$password'";

The problem is that $username and $password are taken directly from user input and placed inside the SQL query string without any cleaning or validation. This means whatever the user types becomes part of the SQL query itself.

The Attack:

An attacker enters this as the username:

admin' — -

Now the application builds this query:

SELECT * FROM admin WHERE username='admin' — -' AND password='anything'

Let us break this down character by character:

  • admin → the username we want to log in as
  • ' → closes the username string in SQL
  • — — → this is a SQL comment. MySQL ignores everything after this

So MySQL sees only this:

SELECT * FROM admin WHERE username='admin'

The password check is completely gone! MySQL finds the admin user and returns it. The application thinks login was successful and grants full access.

Why is This Critical?

This vulnerability is rated CVSSv3 9.8 Critical because:

  1. No authentication needed — anyone on the internet can exploit it
  2. No special tools needed — just a browser
  3. Full admin access — attacker gets complete control of the system
  4. No traces — looks like a normal login in server logs
  5. All data at risk — every student attendance record is exposed
  6. Data manipulation — attacker can modify or delete all records

OWASP Classification:

SQL Injection is ranked in the OWASP Top 10 — the most critical web application security risks. It has been exploited in some of the biggest data breaches in history including LinkedIn, Adobe, and Yahoo.

Setting Up the Lab

I set up a Docker lab to safely test the vulnerability. Never test on production systems — always use a local lab.

Confirming the Exploit

I opened the login page in my browser:

http://localhost:8084/index.php

And entered:

  • Username: admin' — -
  • Password: anything
  • Type: admin

The result: Full admin panel access without valid credentials! The system completely bypassed the password check and logged me in as admin.

Writing the PoC Script

I wrote a Python script to automate and demonstrate the exploit:

The full PoC script is available at: https://github.com/menevarad007/CVE-2026-37749

Reporting the Vulnerability — Responsible Disclosure

After confirming the vulnerability, I followed responsible disclosure process:

Step 1 — Submitted to MITRE via https://cveform.mitre.org

Step 2 — Received confirmation email with ticket number

Step 3 — Waited for CVE assignment — received CVE-2026–37749

Step 4 — Created public advisory on GitHub

Step 5 — Notified the vendor via CodeAstro contact form

Step 6 — Submitted exploit to Exploit-DB

Step 7 — Notified MITRE about publication

Step 8 — CVE published on https://www.cve.org

Responsible disclosure means giving the vendor time to fix the issue before making it public. This protects real users while still ensuring the vulnerability gets documented and fixed.

CVE Details

  • CVE ID: CVE-2026–37749
  • Type: SQL Injection → Authentication Bypass
  • Severity: Critical (CVSSv3: 9.8)
  • CWE: CWE-89 — Improper Neutralization of Special Elements in SQL Command
  • Affected Product: Simple Attendance Management System v1.0
  • Vendor: CodeAstro
  • CVE Record: https://www.cve.org/CVERecord?id=CVE-2026-37749
  1. Always check login forms first — they handle user input directly and authentication bypasses are high impact
  2. Raw SQL queries are dangerous — always use prepared statements or ORM
  3. Old PHP functions like mysql_query() are deprecated and unsafe — use MySQLi or PDO
  4. Setting up a local Docker lab is essential — never test on production systems
  5. Responsible disclosure protects everyone — always report before publishing
  6. Manual code review finds what automated scanners miss — read the code line by line

What's Next

I am continuing to research web application vulnerabilities and improving my skills every day. If you are interested in security research, start with:

References

Varad AP Mene — Independent Security Researcher

Email: menevarad007@gmail.com

GitHub: https://github.com/menevarad007

CVE Program Blog