Authorized SQL injection exploitation framework for CVE-2020-5504 in phpMyAdmin, featuring automated database enumeration, blind injection, proxy support, and structured reporting for penetration testing and security research.
Authorized security testing and research framework for identifying and validating CVE-2020-5504 in phpMyAdmin deployments
Overview · Features · Installation · Usage · Reports · Architecture · Contributing
Responsible-use notice: This project is intended only for systems that you own or are explicitly authorized to assess. Do not use it against public, third-party, or production systems without written permission and a defined testing scope.
| CLI Output | Usage |
|---|---|
 |  |
CVE-2020-5504 is a SQL injection vulnerability affecting the phpMyAdmin user accounts page. According to the official phpMyAdmin advisory, phpMyAdmin 4.x versions before 4.9.4 and phpMyAdmin 5.0.0 are affected; the advisory recommends upgrading to 4.9.4 or newer for the 4.x line and 5.0.1 or newer for the 5.x line.[1] The National Vulnerability Database records that exploitation requires a valid MySQL account to access the server.[2]
This project provides a structured workflow for authorized penetration testing, controlled validation, and security research. It is designed to help assessors fingerprint a target, verify whether the target appears affected, document evidence, and produce structured reports for remediation tracking.
The framework is organized around four goals:
Identify phpMyAdmin installations and collect version-related indicators.
Validate suspected exposure using controlled, non-destructive checks where possible.
Assess authorized targets using configurable limits, retry behavior, and optional proxying.
Report findings in formats that are easy to review, archive, and integrate into workflows.
This project is not a substitute for patching, vendor guidance, secure configuration, or a formal penetration-testing authorization process. It does not guarantee detection of every deployment, configuration, version, or network condition. All results should be manually reviewed and treated as assessment evidence rather than an automatic security verdict.
Only run this tool against an asset when you have clear authorization from the asset owner. Authorization should define the target, allowed test window, permitted techniques, source IPs, data-handling requirements, escalation contacts, and stop conditions.
Never test internet-facing systems merely because they are reachable. Reachability is not permission.
Assessment modes may produce information about databases, tables, columns, or records. Treat all output as potentially sensitive. Store reports using appropriate access controls, avoid placing secrets in shell history, encrypt reports when required by your engagement rules, and securely delete temporary data after the engagement.
Before starting an assessment, confirm that you have a known-good backup or recovery procedure, a communication channel with the system owner, and a documented rollback or stop plan. Prefer an isolated test environment whenever one is available. Use the least intrusive mode that answers the assessment question.
| Area | Capability | Description |
|---|---|---|
| Discovery | Automated fingerprinting | Identifies likely phpMyAdmin deployments and gathers version indicators. |
| Validation | Vulnerability verification | Performs controlled checks with confidence-oriented result handling. |
| Workflow | Multiple operating modes | Supports detection, verification, research, and dry-run workflows. |
| Session handling | CSRF token management | Extracts and manages CSRF-related values required by the application flow. |
| Authentication | Multi-signal validation | Uses multiple indicators to reduce false authentication results. |
| Assessment | Database enumeration | Supports authorized enumeration of databases, tables, columns, and selected data. |
| Injection research | Blind techniques | Supports boolean-based and time-based research workflows where enabled by the implementation. |
| Reporting | JSON, HTML, and TXT | Produces structured, styled, and plain-text output for different audiences. |
| Reliability | Retries and backoff | Retries transient requests with configurable behavior. |
| Integrations | Proxy support | Can be used with Burp Suite or another HTTP interception proxy. |
| Usability | Rich terminal interface | Provides color-coded output, progress indicators, and readable status messages. |
| Diagnostics | Verbose logging | Exposes additional diagnostic information for authorized troubleshooting. |
The recommended workflow is intentionally staged so that assessors can begin with the lowest-impact activity and increase scope only when authorized.
┌──────────────────┐
│ Define scope │ Confirm written authorization and test boundaries
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Detect │ Identify phpMyAdmin and collect version indicators
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Verify │ Perform controlled vulnerability checks
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Assess, if │ Continue only when explicitly authorized
│ approved │
└────────┬─────────┘
│
▼
┌──────────────────┐
│ Report │ Preserve evidence, limits, timestamps, and conclusions
└──────────────────┘
A positive result should be reviewed against the target version, authentication context, request evidence, and engagement scope. A negative result does not prove that the deployment is secure; it may reflect version differences, access controls, routing, application customization, rate limiting, or insufficient visibility.