CVE-2025-69458 – Movie Rating System 1.0 - SQL Injection to RCE (Unauthenticated)
Wed Jan 21 2026 · 3 min read
Category: Security Research
Introduction
In this report, we will examine a critical SQL Injection vulnerability detected in the "Movie Rating System 1.0" application and how this vulnerability can be escalated to a Remote Code Execution (RCE) attack. This attack allows an unauthenticated attacker to gain full control over the server.
Vulnerability Analysis
SQL Injection Point
Upon examining the movie_details.php file, which displays movie details, we see that the id parameter is included directly in the SQL query without sufficient security measures.
// Vulnerable Code in movie_details.php
if(isset($_GET['id'])){
$qry = $conn->query("SELECT * FROM `movie_list` where id = '{$_GET['id']}'");
// ...
}

In the code above, the $_GET['id'] variable is added to the query without any sanitization or use of prepared statements. This allows an attacker to manipulate the SQL query and perform unauthorized operations on the database.
Exploit Development
The exploit (exploit.py) I developed to escalate this vulnerability to an RCE attack follows these steps:
-
Target and Page Detection: The exploit takes the target URL, finds the "Movies" page, and reaches a valid movie detail page (
movie_details.php?id=...). -
Path Disclosure:
The attacker adds a single quote (') character to theidparameter to generate an SQL syntax error. If error messages are enabled on the server (display_errors = On), PHP returns a warning message containing the full physical path of the file on the server (e.g.,C:\xampp\htdocs\movie\movie_details.php). The exploit parses this error to obtain the web root directory (C:/xampp/htdocs/movie/). -
SQL to RCE (INTO OUTFILE):
After obtaining the file path, MySQL'sINTO OUTFILEfeature is used to write a malicious PHP file to the server.Payload Logic Used:
-1881' OR 1881=1881 LIMIT 0,1 INTO OUTFILE 'C:/xampp/htdocs/movie/shell.php' LINES TERMINATED BY 0x3c3f70687020... -- -Here, the
LINES TERMINATED BYclause is critical. Normally, while the query result is written to the file, the hex-encoded PHP shell code (<?php ... system($cmd); ... ?>) determined by the attacker is added to the end of the lines. Thus, the created file becomes an executable PHP file by the server.Note: For this attack to be successful, the database user must have the
FILEprivilege, and thesecure_file_privsetting must allow file writing. -
Code Execution:
After the file is successfully created, the exploit sends an HTTP request to theshell.phpfile and executes thewhoamicommand to verify its authority on the system.
Remediation
To fix this critical vulnerability, the following steps must be applied:
1. Use Prepared Statements:
Instead of directly concatenating user inputs in SQL queries, Prepared Statements must be used.
Secure Code Example:
$stmt = $conn->prepare("SELECT * FROM `movie_list` where id = ?");
$stmt->bind_param("s", $_GET['id']);
$stmt->execute();
$qry = $stmt->get_result();
2. Hide Error Messages:
Displaying PHP error messages to the user in the production environment should be prevented. display_errors should be set to Off in the php.ini file.
3. Restrict Database Privileges:
The database user used by the web application should not be granted high privileges such as FILE. Only necessary privileges like SELECT, INSERT, UPDATE, DELETE should be defined.
4. secure_file_priv Setting:
In the MySQL configuration, the secure_file_priv setting should be directed to a secure directory outside the web root or set to NULL to restrict file operations.
CVE ID: CVE-2025-69458
Original public disclosure: December 22, 2021
Researcher: Tağmaç "Tagoletta"
Canonical reference: https://www.exploit-db.com/exploits/50622
Github Repository: https://github.com/Tagoletta/CVE-2025-69458
Introduction
In this report, we will examine a critical SQL Injection vulnerability detected in the "Movie Rating System 1.0" application and how this vulnerability can be escalated to a Remote Code Execution (RCE) attack. This attack allows an unauthenticated attacker to gain full control over the server.
Vulnerability Analysis
SQL Injection Point
Upon examining the movie_details.php file, which displays movie details, we see that the id parameter is included directly in the SQL query without sufficient security measures.
// Vulnerable Code in movie_details.php
if(isset($_GET['id'])){
$qry = $conn->query("SELECT * FROM `movie_list` where id = '{$_GET['id']}'");
// ...
}

In the code above, the $_GET['id'] variable is added to the query without any sanitization or use of prepared statements. This allows an attacker to manipulate the SQL query and perform unauthorized operations on the database.
Exploit Development
The exploit (exploit.py) I developed to escalate this vulnerability to an RCE attack follows these steps:
-
Target and Page Detection: The exploit takes the target URL, finds the "Movies" page, and reaches a valid movie detail page (
movie_details.php?id=...). -
Path Disclosure:
The attacker adds a single quote (') character to theidparameter to generate an SQL syntax error. If error messages are enabled on the server (display_errors = On), PHP returns a warning message containing the full physical path of the file on the server (e.g.,C:\xampp\htdocs\movie\movie_details.php). The exploit parses this error to obtain the web root directory (C:/xampp/htdocs/movie/). -
SQL to RCE (INTO OUTFILE):
After obtaining the file path, MySQL'sINTO OUTFILEfeature is used to write a malicious PHP file to the server.Payload Logic Used:
-1881' OR 1881=1881 LIMIT 0,1 INTO OUTFILE 'C:/xampp/htdocs/movie/shell.php' LINES TERMINATED BY 0x3c3f70687020... -- -Here, the
LINES TERMINATED BYclause is critical. Normally, while the query result is written to the file, the hex-encoded PHP shell code (<?php ... system($cmd); ... ?>) determined by the attacker is added to the end of the lines. Thus, the created file becomes an executable PHP file by the server.Note: For this attack to be successful, the database user must have the
FILEprivilege, and thesecure_file_privsetting must allow file writing. -
Code Execution:
After the file is successfully created, the exploit sends an HTTP request to theshell.phpfile and executes thewhoamicommand to verify its authority on the system.
Remediation
To fix this critical vulnerability, the following steps must be applied:
1. Use Prepared Statements:
Instead of directly concatenating user inputs in SQL queries, Prepared Statements must be used.
Secure Code Example:
$stmt = $conn->prepare("SELECT * FROM `movie_list` where id = ?");
$stmt->bind_param("s", $_GET['id']);
$stmt->execute();
$qry = $stmt->get_result();
2. Hide Error Messages:
Displaying PHP error messages to the user in the production environment should be prevented. display_errors should be set to Off in the php.ini file.
3. Restrict Database Privileges:
The database user used by the web application should not be granted high privileges such as FILE. Only necessary privileges like SELECT, INSERT, UPDATE, DELETE should be defined.
4. secure_file_priv Setting:
In the MySQL configuration, the secure_file_priv setting should be directed to a secure directory outside the web root or set to NULL to restrict file operations.
CVE ID: CVE-2025-69458
Original public disclosure: December 22, 2021
Researcher: Tağmaç "Tagoletta"
Canonical reference: https://www.exploit-db.com/exploits/50622
Github Repository: https://github.com/Tagoletta/CVE-2025-69458
Giriş
Bu raporda, "Movie Rating System 1.0" uygulamasında tespit edilen kritik bir SQL Enjeksiyonu (SQL Injection) zafiyetini ve bu zafiyetin Uzaktan Kod Yürütme (RCE) saldırısına nasıl dönüştürülebileceğini inceleyeceğiz. Bu saldırı, kimliği doğrulanmamış bir saldırganın sunucu üzerinde tam kontrol sağlamasına olanak tanır.
Zafiyet Analizi
SQL Enjeksiyonu Noktası
Uygulamanın film detaylarını gösteren movie_details.php dosyasını incelediğimizde, id parametresinin yeterli güvenlik önlemleri alınmadan doğrudan SQL sorgusuna dahil edildiğini görüyoruz.
// movie_details.php içindeki Zafiyetli Kod
if(isset($_GET['id'])){
$qry = $conn->query("SELECT * FROM `movie_list` where id = '{$_GET['id']}'");
// ...
}

Yukarıdaki kodda, $_GET['id'] değişkeni herhangi bir temizleme işleminden geçirilmeden veya hazırlanmış ifadeler (prepared statements) kullanılmadan sorguya eklenmektedir. Bu durum, saldırganın SQL sorgusunu manipüle etmesine ve veritabanı üzerinde yetkisiz işlemler yapmasına olanak tanır.
Exploit Geliştirme
Bu zafiyeti bir RCE saldırısına dönüştürmek için geliştirdiğim exploit (exploit.py) şu adımları izlemektedir:
-
Hedef ve Sayfa Tespiti: Exploit, hedef URL'yi alır ve "Movies" sayfasını bularak geçerli bir film detay sayfasına (
movie_details.php?id=...) ulaşır. -
Yol İfşası (Path Disclosure):
Saldırgan,idparametresine tek tırnak (') karakteri ekleyerek bir SQL sözdizimi hatası oluşturur. Eğer sunucuda hata mesajları açıksa (display_errors = On), PHP bir uyarı mesajı döndürür ve bu mesaj dosyanın sunucu üzerindeki tam fiziksel yolunu (örn.C:\xampp\htdocs\movie\movie_details.php) içerir. Exploit, bu hatayı ayrıştırarak web kök dizinini (C:/xampp/htdocs/movie/) elde eder. -
SQL'den RCE'ye (INTO OUTFILE):
Dosya yolunu elde ettikten sonra, MySQL'inINTO OUTFILEözelliği kullanılarak sunucuya kötü amaçlı bir PHP dosyası yazılır.Kullanılan Payload Mantığı:
-1881' OR 1881=1881 LIMIT 0,1 INTO OUTFILE 'C:/xampp/htdocs/movie/shell.php' LINES TERMINATED BY 0x3c3f70687020... -- -Burada
LINES TERMINATED BYifadesi kritik öneme sahiptir. Normalde sorgu sonucu dosyaya yazılırken, satır sonlarına saldırganın belirlediği hex kodlanmış PHP shell kodu (<?php ... system($cmd); ... ?>) eklenir. Böylece oluşturulan dosya, sunucu tarafından çalıştırılabilir bir PHP dosyası haline gelir.Not: Bu saldırının başarılı olabilmesi için veritabanı kullanıcısının
FILEyetkisine sahip olması vesecure_file_privayarının dosya yazmaya izin vermesi gerekmektedir. -
Kod Yürütme:
Dosya başarıyla oluşturulduktan sonra, exploitshell.phpdosyasına bir HTTP isteği gönderir vewhoamikomutunu çalıştırarak sistem üzerindeki yetkisini doğrular.
Çözüm ve Kapatma
Bu kritik zafiyeti gidermek için aşağıdaki adımlar uygulanmalıdır:
1. Prepared Statements Kullanımı:
SQL sorgularında kullanıcı girdilerini doğrudan birleştirmek yerine, mutlaka Hazırlanmış İfadeler (Prepared Statements) kullanılmalıdır.
Güvenli Kod Örneği:
$stmt = $conn->prepare("SELECT * FROM `movie_list` where id = ?");
$stmt->bind_param("s", $_GET['id']);
$stmt->execute();
$qry = $stmt->get_result();
2. Hata Mesajlarını Gizleme:
Canlı ortamda (production) PHP hata mesajlarının kullanıcıya gösterilmesi engellenmelidir. php.ini dosyasında display_errors = Off olarak ayarlanmalıdır.
3. Veritabanı Yetkilerini Kısıtlama:
Web uygulamasının kullandığı veritabanı kullanıcısına FILE gibi yüksek yetkiler verilmemelidir. Sadece gerekli olan SELECT, INSERT, UPDATE, DELETE yetkileri tanımlanmalıdır.
4. secure_file_priv Ayarı:
MySQL yapılandırmasında secure_file_priv ayarı, web kök dizini dışında güvenli bir dizine yönlendirilmeli veya NULL olarak ayarlanarak dosya işlemleri kısıtlanmalıdır.
CVE ID: CVE-2025-69458
İlk Yayın Tarihi: 22 Aralık 2021
Araştırmacı: Tağmaç "Tagoletta"
Canonical reference: https://www.exploit-db.com/exploits/50622
Github Repository: https://github.com/Tagoletta/CVE-2025-69458
Frequently Asked Questions
What is CVE-2025-69458?
An unauthenticated SQL Injection that chains to Remote Code Execution in Movie Rating System 1.0, discovered as a zero-day by Tağmaç 'Tagoletta'.
How is the SQL injection escalated to RCE?
The injection point allows writing attacker-controlled content to the web root (for example via SELECT ... INTO OUTFILE), planting a PHP webshell that is then executed for full command execution.
Is authentication required to exploit it?
No. The vulnerability is reachable pre-authentication, so any remote attacker who can reach the application can exploit it.
How do you remediate CVE-2025-69458?
Use parameterized queries/prepared statements, remove the database FILE privilege, place the app behind a WAF, restrict web-root write permissions, and upgrade if the vendor releases a patched version.
Where is the PoC exploit writeup for CVE-2025-69458?
The full proof-of-concept exploit code and step-by-step writeup are published on this site — see the companion exploit page for the ready-to-run PoC that automates the SQL injection to RCE chain.