Whitebox pentesting: A week, a challenge, and a goal

Most of my day-to-day work revolves around graybox and blackbox testing, but I felt the urge to push my limits with whitebox testing. So I gave myself a week — one focused, intense week — to dive in. What came out of it were some surprising (and satisfying) results. I had previously dabbled in whitebox testing on Huntr, but the experience was more frustrating than rewarding.

Vulnerability Submissions

I submitted 5 reports (1 project huntr, 1 project apache): 3 were marked as duplicates, 1 was rejected, and 1 was accepted.

And once again, I disappointed with Huntr. Three of my reports were marked as duplicates in the most frustrating way — different attack vectors, yet all flagged as duplicates of the same report.

One of the two reports on Apache Airflow was accepted and led to the publication of CVE-2025-30473.

How to Find Vulnerabilities?

1. Build product

This can be a challenging step when you first start hunting bugs in it. But with AI, the process of building and fixing bugs seems to have become faster. Still, AI can assist but can't do everything. Make sure to double-check everything before making any changes. Be persistent and seek further help from the community if you can't resolve the issue yourself.

2. Understand the Application’s Purpose and Architecture

Before diving into the code or chasing potential bugs, take a step back and understand the “why” behind the application.

• What problem is it solving?

• Who is the target user?

• How is data supposed to flow?

• What are the critical components or modules?

Understanding the purpose and architecture helps you prioritize where to look. You’ll start spotting areas that are more likely to contain logic flaws, trust boundary issues, or unsafe data processing.

3. Identify the Sinks

Sinks are the dangerous parts of the code — where data ends up and something impactful happens (e.g., file operations, command execution, database queries).

4. Taint Tracking

This is the heart of whitebox work: taint tracking.
Where does user input come from (sources)?

• How does it flow through the application?
• Does it reach a sink without proper validation?

You can do this manually by reading code or using tools like:

• Semgrep (Good)
• CodeQL (Very good)
• Joern (Maybe dead)

5. Craft the Exploit

Once you've confirmed a data path from source → sink with no proper validation/sanitization, it's time to prove impact.

Diving into CVE-2025-30473

The first thing I did was review previous reports related to Apache Airflow. I quickly noticed a pattern — most submissions were focused on the DAG examples. That gave me a clue: if everyone is targeting the DAG examples, there must be something interesting there. So I decided to take a closer look at what these DAGs were trying to demonstrate. You can search on google with key "airflow hackerone"

After setting up the environment and going through the DAG examples recommended by the developers, I discovered an SQL injection bug that allowed users to modify the underlying query.

While reading through the source code, I realized that it supports a wide range of database.

The partition_clause parameter was being used in a string concatenation. This opened the door for me to exploit it.

The developers mentioned that this was an intentional feature — it allowed users to control the query to fetch data from different partitions. They fixed it by simply filtering out semicolons (;).
I found this fix rather questionable. When I followed up via email, the response I got reaffirmed that it was “part of the feature.”
Interestingly, after the CVE was published, a few people started paying attention to the way it was patched.

Final Thought

Try harder