From SAST to CVE-2025-46337

From the start of my career in cybersecurity, I have always worked as a black box pentester. Since I believe that learning new topics is always a good use of my time and that I should increase my knowledge of white box pen testing, I decided to explore the Static Analysis Security Testing (SAST) topic.

I started my journey into SAST using the well-known tool SonarQube. To practice with the tool and to become familiar with the GUI and the mechanisms that are behind it, I decided to analyze the code of a few known projects.

I chose two projects to analyze. The first one is "Moodle", a very well-known open-source project whose main purpose is to create websites for universities. The second is VtigerCRM, a familiar project on which I discovered several CVEs last summer.

I started the SAST first against the source code of Moodle and then against the source code of VtigerCRM. Surprisingly, SonarQube found an SQL Injection on both projects!

Since the source code I had SonarQube analyze is often reviewed, that was quite a surprise. So I started my journey by writing down the method pointed out by SonarQube, planning to search where they were used in the source code.

Vulnerable method:

• pg_insert_id-->(1 sink, 2 projects) 

Snippet from VtigerCRM

Snippet from Moodle

After spending some time searching for them, I found out that they were never used in the main code. I suspected I had either misread or misunderstood SonarQube’s explanations. The only reasonable option that came to my mind was to re-inspect those.

While manually re-analyzing the snippet prompted by SonarQube, I noticed two relevant pieces of information. First, the vulnerable function was in two files under the "adodb" folder. Second, the code in the code snippet was equal. Provided that I was unaware of what adodb is really. Since the presence of identical functions in two different projects suggests that the issue was in a library. I did some quick research to find out what adodb really is. Through my research, I discovered that ADOdb is not just a PHP library; it's an abstraction layer for interacting with various well-known databases.

So after retrieving all this information, I decided to update my Notes:

Vulnerable Sink:

• drivers/adodb-postgres64.inc.php
• pg_insert_id(1 sink)

Manual Analysis

After learning about ADOdb’s nature, I decided to run SAST on its source code. Strangely, SonarQube didn’t find any issues at all.

Provided that the vulnerable method wasn't used either in Moodle's main code or in VtigerCRM's main code, and because I'm working with an abstraction layer, I decided to make a script that calls the vulnerable functions and to exploit it either manually or using automated tools. This led to making a Proof of Concept (PoC).

This little side project helped me obtain a CVE, improved my knowledge in installing and managing both MySQL and PostgreSQL databases, and forced me to write some code in PHP.

In conclusion, we can see how the white-box approach works together with the black-box approach and how they enhance each other.

The Fix

Regarding the patch of the vulnerability, I have to thank Dregad for his professionalism and for how he managed the processes of  publishing the advisory

Github Advisory