OctoSQL & Vulnerability Data

As an avid daily reader of TLDR Information Security I benefit twofold. First, I gain interesting insights and recommendations regarding launches and tools, where I first learned about OctoSQL. Second, concerning vulnerability details inevitably land in my inbox on a near daily basis. Aside from my recommendation to join the TLDR InfoSec mailing list, toolsmith readers also benefit twofold as, herein, I share the use of OctoSQL as a fast CLI interface to vulnerability data aggregated via CVE-Vulnerability-Information-Downloader. If ever you’ve wanted to join vulnerability data (CVE, CVSS, EPSS, etc) from disparate data sources and file types, this is the toolsmith for you.

The 03 JUN 2025 edition of TLDR InfoSec brought us details on Qualcomm’s three patched zero-day vulnerabilities in its Adreno GPU driver that are being actively exploited in targeted attacks. Per the TLDR InfoSec issue, CVE-2025-21479 and CVE-2025-21480 cause memory corruption through unauthorized GPU command execution while CVE-2025-27038 is a use-after-free vulnerability in Chrome’s graphics rendering. “Google’s Threat Analysis Group (TAG) confirmed these vulnerabilities are under limited, targeted exploitation, and Qualcomm provided patches to device manufacturers in May with urgent deployment recommendations.” There has been a pattern of Qualcomm chipset vulnerabilities being exploited by threat actors, including a previous zero-day used adversially with Cellebrite software to unlock activists’ and journalists’ Android devices.[1]
While this reference was an effective summary of the issues, it did not contain vulnerabilty stats with which to assess severity and exploitability.
One of my favorite raw data source aggregators for such details is the CVE-Vulnerability-Information-Downloader. With updated a data and OctoSQL in hand, a few useful SQL queries later, we’ll know everything we need. Yes, you can also search web sources, but you may have production scenarios with limited egress access coupled with the need an for easily extensible full-blown dataflow engine which can be used to add a SQL interface to your own applications.

Be sure Docker or the like (Rancher Desktop) are available, and acquire a NVD API key if you don’t already have one. In your preferred data or tools directory:

git clone https://github.com/trinitor/CVE-Vulnerability-Information-Downloader.git
cd CVE-Vulnerability-Information-Downloader
cp env_example .env

Edit the .env file and add your NVD API key, then run:

docker compose up -d  
docker exec -it vulnerability-tables-cron bash /opt/scripts/download.sh

Note that the docker exec download process can take up to twenty minutes to finish. Be patient, don’t panic. ;-)
This will populate the CVE-Vulnerability-Information-Downloader/data/vulnerability-tables-cron/output directory of your installation CSV and JSON versions of CISA Known Exploited Vulnerabilities (KEV) catalog, CVE, CVSS, and EPSS files. This nicely sets up our situation, albeit arbitrary, where we’d like to query these disparate data file types and join key elements such as known exploitation and EPSS score for specific CVEs.
Here’s where OctoSQL provides capably. I installed OctoSQL on Ubuntu 25.04 with brew:

brew install cube2222/octosql/octosql

The OctoSQL binary is available via any path after installing via brew, it’s my preferred one-shot approach.
Just cd to CVE-Vulnerability-Information-Downloader/data/vulnerability-tables-cron/output and you’re ready to go.
I first crafted a query to return all the Qualcomm CVEs in CISA’s KEV (CISA_known_exploited.csv) catalog to validate the assertion that there has been a pattern of Qualcomm chipset vulnerabilities being exploited by threat actors.

octosql "SELECT vendorProject, product, CVE, dateAdded FROM CISA_known_exploited.csv WHERE vendorProject='Qualcomm'"

The assertion is valid, as seen in Figure 1: Qualcomm vulnerabilities have indeed been victim to active exploitation in the wild.
What about the three currently referenced CVEs CVE-2025-21480, 21479, and 27038? If already known to be exploited, what is the probability of exploitation per EPSS?

A query to join CISA’s KEV (CISA_known_exploited.csv) and FIRST’s EPSS.json follows:

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE CVE='CVE-2025-21480' OR CVE='CVE-2025-21479' OR CVE='CVE-2025-27038'"

As seen in Figure 2, those are low EPSS scores, indicating a rather low probability of exploitation. What about all the other known exploited Qualcomm CVEs? Here again I join KEV Catalog results with EPSS to answer the question with results produced in descending order by EPSS score.

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE vendorProject='Qualcomm' ORDER BY EPSS DESC"

Turns out the highest scoring Qualcomm CVE is one the current three of interest, CVE-2025-27038, with a score of only 0.16672 as seen in Figure 3.
What does all mean?
Per Jay Jacobs of Cyentia, EPSS is driven by data and has a strong temporal aspect. It only learns from the exploitation activity it sees (from data partners) and predicts on the vulnerability attributes presented. Those with low EPSS scores on the KEV are more likely to be “Access Vector:Local”, “Confidentiality:None”, require some privileges and/or be without published exploit code. Those with higher EPSS scores tend to have exploit code published, be integrated into pen testing tools and scanners, and/or involve remote command execution/injection. Likelihood of exploitation for these Qualcomm vulns is low due to “Access Vector:Local” above all else.
One additional excellent feature offered by OctoSQL is the ability to explain query plans. As you build complex queries, and potentially productionize them, explainability will be important. Rerunning our last query with the –explain flag set yields an informative visualization as seen in Figure 4. Setting it to 1 produces a query plan without type and schema information, while setting it to 2 includes type and schema. I use 1 here for visual clarity.

octosql "SELECT                        
    c.CVE,
    c.vendorProject,
    c.product,
    c.vulnerabilityName,
    c.dateAdded,
    e.EPSS
FROM
    CISA_known_exploited.csv AS c
INNER JOIN
    EPSS.json AS e
ON
    c.CVE = e.CVE
WHERE vendorProject='Qualcomm' ORDER BY EPSS DESC" --explain 1

I’ve barely scratched the surface of its potential use cases here, but I’ve incorporated OctoSQL into my personal practice, and truly appreciate the ability to query disparate sources in my terminal. I also appreciate the ability to download vulnerability data use the information for enrichment courtesy of the CVE Vulnerability Information Downloader. Please consider both of these offerings for your on purpose and benefit.

Cheers…until next time.

References

[1] Prasanna Gautam, Eric Fernandez & Sammy Tbeile, TLDR Information Security, 03 JUN 2025
[2] Jay Jacobs, Why does EPSS score some CVEs on the KEV so low?, https://www.cyentia.com/integrating-epss-and-kev, retrieved 05 JUN 2025