phpBB 2.0.23 - From Variable Tampering to SQL Injection


In our 12th advent calendar gift, we would like to cover an exciting SQL injection in phpBB2. Although phpBB2 was replaced by its successor phpBB3, it is still one of the most popular bulletin boards. RIPS detected a less severe but very beautiful SQL injection vulnerability that bases on a PHP quirk we will examine in detail in this post.

RIPS Analysis

The forum phpBB2 consists of only ~50,000 lines of code and RIPS took only 19 seconds for its in-depth security analysis to complete. It found various PHP object injection vulnerabilities which are less severe due to missing gadget chains. Further, many SQL injections are reported due to insufficient sanitization with str_replace().

The truncated analysis results are available in our RIPS demo application. Please note that we limited the results to the issues described in this post since there are no fixes available.

Case Study

Variable Tampering

Among others, RIPS reported a variable tampering issue in the style configuration page for administrators. The GET parameter install_to is used as the name of a variable.


$install_to = isset($HTTP_GET_VARS['install_to']) ? urldecode($HTTP_GET_VARS['install_to']) : $HTTP_POST_VARS['install_to'];

$template_name = ${$install_to};

This issue enables an attacker to assign any variable to the $template_name variable. For example, the request admin_styles.php?install_to=rips will lead to the assignment $template_name = $rips;. Depending on the previously declared variables and the use of $template_name this can lead to other security vulnerabilities. RIPS automatically analyzes all possible combinations for exploitation and, as a result, reported a related SQL injection vulnerability.

SQL Injection

Now it gets interesting. The $template_name variable, which is in the attacker’s control, is used within two loops in order to build a SQL query starting in line 76 in order to install a new template from existing data.


$install_to = isset($HTTP_GET_VARS['install_to']) ? urldecode($HTTP_GET_VARS['install_to']) : $HTTP_POST_VARS['install_to'];
$style_name = isset($HTTP_GET_VARS['style']) ? urldecode($HTTP_GET_VARS['style']) : $HTTP_POST_VARS['style'];

$template_name = ${$install_to};
for($i = 0; $i < count($template_name) && !$found; $i++) {
   if( $template_name[$i]['style_name'] == $style_name ) {
        while(list($key, $val) = each($template_name[$i])) {
            $db_fields[] = $key;
            $db_values[] = str_replace("\'", "''" , $val);
$sql = "INSERT INTO " . THEMES_TABLE . " (";
for($i = 0; $i < count($db_fields); $i++) {
    $sql .= $db_fields[$i];
$sql .= ") VALUES (";
for($i = 0; $i < count($db_values); $i++) {
    $sql .= "'" . $db_values[$i] . "'";
$sql .= ")";

Apparently, the variable variable $template_name is expected to point to a nested array with template data in the first array level, and key/value pairs in the second array level. When a user-supplied style GET parameter matches the style_name of the template in line 77, $key and $val pairs are extracted from the template array by using the PHP built-in functions list() and each() in line 78. Then, these are stored in two separate arrays $db_fields and $db_values such that they can be used later as SQL field names and as the fields’ values in the SQL query. While the $db_values are escaped by a global filter and a call to str_replace() in line 80, the $db_fields are embedded unsanitized into the SQL query. However, the template data is always static and loaded from a .cfg file, and there are no other previously declared arrays with user-supplied data available.

But how can this complex code be exploited?

The trick is to point the variable variable $template_name that is used in the loops to another array that is controlled by the user: the superglobal $_GET or $_POST array. Since an attacker can control all of their key/value pairs, he is able to inject SQL commands via array keys that are used unsanitized as database fields in line 86. All that is left to do is to submit a nested array structure with one style_name key matching to the GET parameter style.


Time Line

The development of phpBB2 is abandoned and no patch is available. Please use the latest phpBB3 version.


In today’s calendar post, we described a less severe SQL injection issue in the administrator section of the phpBB2 forum. However, its complexity demonstrated clearly the challenges for a static code analysis tool. Only with the precise handling of variable variables, array structures, and PHP built-in functions such as each() and list(), a static code analysis tool can follow complex data flows beyond a straight-forward source-to-sink tainting and uncover complex security issues.

Follow us on Twitter to be notified when the next gift of our advent calendar is opened!

APAV Time Table

19 Feb 2019Simon ScannellWordPress 5.0.0 Remote Code Execution
29 Jan 2019Simon ScannellCTF Writeup: Complex Drupal POP Chain
15 Jan 2019Simon ScannellLearnings from WordPress Security Month
24 Dec 2016Johannes DahseWhat we learned from our Advent Calendar
23 Dec 2016Hendrik Buchwalde107 2.1.2: SQL Injection through Object Injection
22 Dec 2016Daniel PeerenSecurity Compliance with Static Code Analysis
21 Dec 2016Martin BednorzAbanteCart 1.2.8 - Multiple SQL Injections
20 Dec 2016Martin BednorzKliqqi From Cross-Site Request Forgery to Code Execution
19 Dec 2016Robin PeraglieosClass 3.6.1: Remote Code Execution via Image File
18 Dec 2016Daniel PeerenContinuous Integration - Jenkins at your service
17 Dec 2016Johannes DahseOpenConf 5.30 - Multi-Step Remote Command Execution
16 Dec 2016Robin PeraglieRedaxo 5.2.0: Remote Code Execution via CSRF
15 Dec 2016Dennis DeteringGuest Post: Vtiger 6.5.0 - SQL Injection
14 Dec 2016Hendrik BuchwaldThe State of Wordpress Security
13 Dec 2016Johannes DahsephpBB 2.0.23 - From Variable Tampering to SQL Injection
12 Dec 2016Martin BednorzTeampass Unauthenticated SQL Injection
11 Dec 2016Daniel PeerenRescanning Applications with RIPS
10 Dec 2016Hendrik BuchwaldNon-Exploitable Security Issues
9 Dec 2016Hendrik BuchwaldPrecurio 2.1: Remote Command Execution via Xinha Plugin
8 Dec 2016Martin BednorzPHPKit 1.6.6: Code Execution for Privileged Users
7 Dec 2016Hendrik BuchwaldSerendipity 2.0.3: From File Upload to Code Execution
6 Dec 2016Robin PeraglieRoundcube 1.2.2: Command Execution via Email
5 Dec 2016Hendrik BuchwaldExpression Engine 3.4.2: Code Reuse Attack
4 Dec 2016Johannes DahseIntroducing the RIPS analysis engine
3 Dec 2016Martin BednorzeFront 3.6.15: Steal your professors password
2 Dec 2016Martin BednorzCoppermine 1.5.42: Second-Order Command Execution
1 Dec 2016Hendrik BuchwaldFreePBX 13: From Cross-Site Scripting to Remote Command Execution
25 Nov 2016Martin BednorzAnnouncing the Advent of PHP Application Vulnerabilities

Disclaimer: The information provided here is for educational purposes only. It is your responsibility to obey all applicable local, state and federal laws. RIPS Technologies GmbH assumes no liability and is not responsible for any misuse or damages caused by direct or indirect use of the information provided.

Tags: johannes dahse, php, security, phpbb, sql injection, variable tampering,

Author: Dr. Johannes Dahse


Johannes exploits security vulnerabilities in PHP code for over 10 years. He is an active speaker at academic and industry conferences and a recognized expert in this field. He achieved his Ph.D. in IT security / static code analysis at the Ruhr-University Bochum, Germany. Previously, he worked as a security consultant for leading companies worldwide.

Is your application secure?  Scan Your Code

Related Posts


comments powered by Disqus