CVE-2019-25732: SQL Injection in PHP EI-Tube Script 3 Search Parameter
PHP EI-Tube Script 3 contains a flaw that allows attackers to inject malicious commands into the application's search function without needing any credentials. By crafting specially designed search queries, an attacker can trick the application into executing unauthorized database commands, potentially exposing usernames, passwords, and other sensitive information stored in the database.
Source data · NVD / CISA · public domain
- CVSS
- 3.1 · 8.2 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
- Weaknesses (CWE)
- CWE-89
- Affected products
- 0 configuration(s)
- Published / Modified
- 2026-06-04 / 2026-06-17
NVD description (verbatim)
PHP EI-Tube Script 3 contains an SQL injection vulnerability that allows unauthenticated attackers to execute arbitrary SQL queries by injecting malicious code through the search parameter. Attackers can send GET requests to the search endpoint with crafted SQL payloads in the query parameter to extract sensitive database information including usernames, passwords, and version details.
3 reference(s) · View on NVD →
SEC.co analysis · AI-assisted, reviewed against source
Technical summary
This vulnerability is a classic SQL injection flaw (CWE-89) in PHP EI-Tube Script 3. The search endpoint fails to properly sanitize or parameterize user input from the GET request parameter, allowing unauthenticated attackers to inject arbitrary SQL syntax. The vulnerability is network-accessible, requires no special privileges or user interaction, and directly impacts confidentiality and marginally impacts integrity. The CVSS 3.1 score of 8.2 (HIGH) reflects the ease of exploitation and the sensitivity of data at risk.
Business impact
Successful exploitation could lead to unauthorized disclosure of user credentials, application version information, and potentially other sensitive database records. An attacker gaining this information could pivot to further compromise the application, launch credential-stuffing attacks, or perform social engineering. For organizations relying on PHP EI-Tube Script 3, this represents a direct path to data breach and regulatory compliance violations (GDPR, HIPAA, PCI-DSS depending on data handled).
Affected systems
PHP EI-Tube Script 3 installations are affected. The vulnerability is unauthenticated and network-reachable, meaning any instance exposed to an attacker's network can be targeted. This includes on-premises deployments, cloud-hosted versions, and any configuration where the search endpoint is accessible.
Exploitability
Exploitability is high. The attack vector is network-based, requires no authentication, no special configuration, and no user interaction. An attacker can craft a malicious GET request in seconds using readily available tools or command-line utilities. No special privileges are required on the attacker side. The barrier to entry is low, and active exploitation is likely if the application is internet-facing.
Remediation
Apply security updates from the PHP EI-Tube Script 3 vendor immediately upon availability. If patches are not yet available, implement input validation and prepared statements (parameterized queries) to neutralize SQL injection vectors. Additionally, restrict network access to the search endpoint, implement Web Application Firewall (WAF) rules to block SQL injection patterns, and enforce database permissions to limit data exposure if injection occurs.
Patch guidance
Check the official PHP EI-Tube Script 3 vendor advisory for patched version numbers and deployment instructions. Verify that patches address SQL injection in the search parameter specifically. Test patches in a non-production environment before rolling out. Ensure database credentials are rotated post-patching, as compromise cannot be ruled out in exploited systems.
Detection guidance
Monitor web server access logs for GET requests to the search endpoint containing SQL keywords (SELECT, UNION, OR, AND) or SQL comment syntax (-- , /* */). Configure intrusion detection rules to flag payloads with encoded SQL syntax variations. Query database transaction logs for unusual query patterns or access to system tables. Use database activity monitoring tools to detect anomalous SQL execution. Search for indicators of credential extraction attempts (SELECT from user/password tables).
Why prioritize this
HIGH priority due to unauthenticated network access, high likelihood of exploitation, direct credential exposure risk, and absence from active exploitation lists (KEV). Organizations must assume this will be actively targeted if public disclosure details emerge. Any internet-facing instance should be treated as critical.
Risk score, explained
The CVSS 3.1 score of 8.2 (HIGH) is justified by: (1) Network Attack Vector—remotely exploitable with no authentication required; (2) Low Attack Complexity—no special setup needed; (3) High Confidentiality Impact—sensitive user data and credentials directly exposed; (4) Low Integrity Impact—attacker can modify data but the primary concern is extraction; (5) No Availability Impact—service remains running but compromised.
Frequently asked questions
Can this vulnerability be exploited without sending traffic through a proxy?
Yes. This is a straightforward SQL injection via GET parameters, exploitable with standard browser requests, curl commands, or any HTTP client. No special tools or proxies are required, though they are commonly used for testing.
If we've already been running this version in production, should we assume the database has been compromised?
You should assume compromise is possible if the system was internet-facing or accessible to untrusted networks during the vulnerability window. Conduct forensic analysis of database access logs, implement credential rotation immediately, and monitor for lateral movement or data exfiltration.
Does this vulnerability require the attacker to know specific table or column names?
Standard SQL injection techniques allow attackers to enumerate database schema through error-based or blind SQL injection methods. Over multiple requests, an attacker can discover table names, columns, and eventually extract full datasets without prior knowledge.
What is the difference between this vulnerability and prepared statements?
This vulnerability exists because user input is concatenated directly into SQL queries. Prepared statements separate SQL structure from user input at the database driver level, making injection impossible. Parameterized queries are the industry standard fix for SQL injection.
This analysis is provided for informational purposes only and does not constitute professional security advice. Verify all technical details, patch availability, and compatibility against official vendor advisories before implementation. SEC.co makes no warranty regarding the completeness or accuracy of this vulnerability intelligence. Organizations are responsible for assessing risk in their own environments and engaging qualified security professionals for remediation. Source: NVD (public-domain), retrieved 2026-07-07. Analysis generated by SEC.co (claude-haiku-4-5).
Weaknesses (CWE)
Related vulnerabilities
- CVE-2018-25382HIGHZechat 1.5 SQL Injection Vulnerability – Unauthenticated Database Access
- CVE-2018-25385HIGHUnauthenticated SQL Injection in E-Registrasi Pencak Silat 18.10
- CVE-2018-25386HIGHSQL Injection in HaPe PKH 1.1 Admin Interface
- CVE-2018-25389HIGHSQL Injection in HaPe PKH 1.1 Database Extraction
- CVE-2018-25390HIGHUnauthenticated SQL Injection in HaPe PKH 1.1
- CVE-2018-25392HIGHSQL Injection in MaxOn ERP Software 8.x-9.x
- CVE-2018-25394HIGHSQL Injection in Kados R10 GreenBee Unauthenticated Remote Database Access
- CVE-2018-25395HIGHKados R10 GreenBee SQL Injection Vulnerability – Unauthenticated Database Access