You want to build an app for a DJI drone. So you buy a drone. You set up your project. You write your first lines of code.

And then you find out: this drone is not supported.

Or maybe the drone is on the list, but your controller is not. Now you have lost money and time.

So how do you know before you buy? This guide gives you the answer, and shows you how to check any DJI drone yourself.

Quick answer: DJI Mobile SDK V5 (MSDK V5) supports mostly enterprise drones, such as the Matrice 400, Matrice 4 series, Matrice 350 RTK, Matrice 300 RTK, Matrice 30 series and Mavic 3 Enterprise series. Only three consumer drones are supported: the Mini 4 Pro, Mini 3 and Mini 3 Pro. Each drone is supported only with specific controllers, so always check the aircraft and the controller together on DJI’s official list.

Prefer to watch? This guide is also available as a video on the DroneDev Academy YouTube channel.

Checked against: MSDK V5.20.1, November 2026. The video was recorded with the V5.18 list, so it does not show the Matrice 5T, which DJI added in V5.20.1. The list changes, so always check the official page before you buy.

What you will learn about supported DJI drones

• What “supported” really means
• The three DJI drone groups, and which ones MSDK V5 covers
• The enterprise drones on the list, with their controllers
• The three consumer drones on the list
• How to check any DJI drone yourself

I’m Peiman. In the years I have developed apps for drones, I faced this problem myself: which drone, with which controller, works with MSDK V5? The official list can be confusing. Let’s read it together.

One note before we start: this guide covers MSDK V5 only, DJI’s Mobile SDK for Android apps. Other DJI SDKs, such as the Payload SDK and Cloud API, have their own lists.

What does “supported” mean?

“Supported” means MSDK V5 can work with the drone. Your app can:

• Read data from it, such as telemetry and live video
• Send commands to it, such as takeoff

If a drone is not supported, MSDK V5 does not work with it, and your app cannot control it. So in this guide, “Can you program it?” means “Is it supported by MSDK V5?”

DJI supports a pair, not a drone

This is the most important part. DJI does not support the drone alone. It supports a pair: the aircraft and the remote controller.

This is because your app talks to the controller, and the controller talks to the aircraft. If the controller has a screen, your app can run on it. If not, your app runs on a phone connected to the controller. (New to this chain? Read What Is DJI MSDK V5? first.)

The official list also shows firmware versions for each aircraft and controller. So remember three things, always together:

The three DJI drone groups

Before you read the list, you need to know how DJI groups its drones. There are three main groups:

• Consumer drones are made for photos, video and travel. Examples are the Mini series, the Air series and the Mavic 3 Pro.
• Enterprise drones are made for professional work, such as inspection, mapping and public safety. Examples are the Matrice series and the Mavic 3 Enterprise series.
• Agriculture drones are made for farms, for spraying and spreading. The Agras series is the example.

Now look at the MSDK V5 list:

• Enterprise: most of the list
• Consumer: only three drones, all from the Mini series
• Agriculture: none

What DJI support says about the future

In October 2026, I asked DJI support about consumer drones. In their email reply, they said that:

• Other consumer drones are not supported, and there are currently no plans to support them.
• Going forward, MSDK will mainly focus on enterprise aircraft.

So if you plan a long-term project, an enterprise drone is the safer choice.

The enterprise drones supported by MSDK V5

Here are the enterprise drones on the list, grouped by family, with their controllers.

• Matrice 400: DJI RC Plus 2
• Matrice 4 series (Matrice 4E, 4T, 4D and 4TD): DJI RC Plus 2
• Matrice 350 RTK: DJI RC Plus
• Matrice 300 RTK: DJI RC Plus, or DJI Smart Controller Enterprise. It is the only enterprise aircraft listed with two controllers.
• Matrice 30 series: DJI RC Plus
• Mavic 3 Enterprise family (Mavic 3 Enterprise series, Mavic 3M and Mavic 3TA): DJI RC Pro Enterprise
• Matrice 5T: new in MSDK V5.20.1. Check the official list for its controller and firmware.

All of these controllers have a screen, so your app can run directly on the controller.

The list also includes payloads, such as the Zenmuse cameras. Payloads are a topic for another guide.

The three consumer drones supported by MSDK V5

Only three consumer drones are on the list, and all of them are from the Mini series:

• DJI Mini 4 Pro: DJI RC-N2 or DJI RC-N3
• DJI Mini 3: DJI RC-N1 only
• DJI Mini 3 Pro: DJI RC-N1 or DJI RC Pro

Look at the controllers:

• The RC-N1, RC-N2 and RC-N3 have no screen, so your app runs on a phone connected to them.
• The RC Pro has a screen, so your app can run on the controller.

Every other consumer drone is not supported

Examples include the Mini 5 Pro, the Air series, the Mavic 3 Pro and the Mini 2.

Be careful with bundles

Some drone bundles come with a different controller. For example, a Mini 3 sold with a controller other than the RC-N1. If the controller in your bundle is not on the list, the pair is not supported, even if the aircraft is.

How to check any DJI drone yourself

Checking a drone takes two minutes:

1. Open the DJI developer site.
2. Go to the Mobile SDK section and open the MSDK release notes.
3. Find the section called “Supported Product List and Firmware Version”.

Then:

1. Find your aircraft.
2. Find its controllers under it.
3. Check the firmware versions for both.

If your aircraft or your controller is not there, it is not supported.

One last tip: the list changes. Check it again on the day you buy, and look at the MSDK version on the page.

The Developer Scorecard: how to choose a drone

When you choose a drone for a project, answer four questions about it:

1. Is it supported by MSDK V5?
2. Which controller does it use?
3. What is listed with it? (payloads and accessories)
4. What is it best for?

Here is an example from a drone I have used with MSDK V5, the Matrice 300 RTK:

• Supported by MSDK V5: Yes
• Controller: DJI RC Plus, or DJI Smart Controller Enterprise
• Listed with it: Zenmuse H20, H30, P1, L1 and L2, and the D-RTK 2 Mobile Station
• Best for: inspection and mapping with interchangeable payloads

You can use the same scorecard for any drone on the list.

Key takeaways: which DJI drones MSDK V5 supports

• A DJI drone is supported as a pair: the aircraft and its controller, with the right firmware.
• MSDK V5 is mainly for enterprise drones. Only three consumer drones are supported: the Mini 4 Pro, Mini 3 and Mini 3 Pro.
• No agricultural drones are on the list.
• DJI support says MSDK will mainly focus on enterprise aircraft going forward.
• Check the official list on the day you buy, including the controller in your bundle.

Frequently asked questions about MSDK V5 supported drones

Is the DJI Mini 4 Pro supported by MSDK V5?

Yes, with the DJI RC-N2 or RC-N3 controller. Your app runs on a phone connected to the controller.

Is the DJI Mini 5 Pro supported by MSDK V5?

No. At the time of writing, the Mini 5 Pro is not on the MSDK V5 supported list.

Are the DJI Air series drones supported by MSDK V5?

No. The Air series is not on the list. The only supported consumer drones are the Mini 4 Pro, Mini 3 and Mini 3 Pro.

Are DJI Agras drones supported by MSDK V5?

No. No agricultural drones are on the MSDK V5 list.

Can I use any DJI controller with a supported drone?

No. DJI supports specific aircraft and controller pairs. If your controller is not listed with your aircraft, the pair is not supported.

Where is the official MSDK V5 supported list?

On the DJI developer site, in the MSDK release notes, in the section called “Supported Product List and Firmware Version”.

Does MSDK V5 work on iOS?

No. MSDK V5 is for Android only. Learn more in What Is DJI MSDK V5?

Next steps after you choose a supported drone

Keep learning DJI drone programming with DroneDev Academy

This guide is part of DroneDev Academy, where I teach drone software development from real project experience. Here is where to go next:

• Watch it on YouTube. This guide has a video version. Subscribe at youtube.com/@DroneDevAcademy to catch new tutorials as they come out.
• Read more guides. Step-by-step articles on DJI Mobile SDK V5 are collected on the all DroneDev Academy guides.
• Learn MSDK V5 step by step. In the full DroneDev Academy course, we learn the fundamentals of DJI drone programming and build a real drone app together, from zero. See the DroneDev Academy course.

If you got stuck somewhere, write to me at info@dronedevacademy.com. I read every message.

Want the full course?

The DroneDev Academy course starts with this same SDK. Join the early-access list to hear first about the course and about new guides like this one.

Get early access

Originally published at https://dronedevacademy.com on November 11, 2026.

Which DJI Drones Support MSDK V5? (2026) | DroneDev Academy was originally published in Radio Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Somewhere in Argentina there is a long wire strung between two points, feeding a KiwiSDR on a shelf. Somewhere in Germany there is a knob. Turn the knob, and the receiver in Argentina retunes, and the audio arrives a quarter second later through a speaker the size of a coin.

That is the whole trick behind ESPica32, a build Ivan (LU8MIL) shared this week and RTL-SDR.com wrote up on November 5. An ESP32-WROOM-32, a small OLED, one rotary encoder and an I2S amplifier. No tuner chip, no ADC, no antenna. The radio is a network client that has learned to behave like a radio.

It is a cheap build and a clever one, and the most interesting part is the bug he hit along the way.

Why a Radio Without RF Matters Right Now

Earlier this year, the RTL-SDR Blog team announced the end of the line for the V4 dongle. The Rafael R828D tuner it depends on is out of production; the stockpile ran dry, and the last chips they could find were faulty. Their stopgap, the V4L, runs on an R828S that is also out of production. Meanwhile, the marketplaces are full of “V4” listings that are a V4 shell wrapped around a V3-clone board.

Hardware supply is a weather system. Nobody controls it, and the hobby keeps getting caught in it.

A KiwiSDR client sidesteps that weather entirely. The Kiwi network is a scattered fleet of HF receivers, roughly 0 to 30 MHz, run by operators who chose to share them publicly. Their antennas sit in quiet rural noise floors you will never have in an apartment full of switch-mode power supplies. A client gets you their ears. You trade local RF for latency and for depending on a stranger’s uptime.

For shortwave broadcast, ham bands, utility stations and weather fax, that is a good trade. For anything involving transmitting, or signals above 30 MHz, it is no trade at all. Know which problem you are solving before you buy parts.

The Bill of Materials

The build is deliberately minimal. Ivan links each part to AliExpress without giving a total, so the prices below are typical listing ranges, not a quote.

The brain is an ESP32-WROOM-32 dev board with onboard USB. In the Arduino IDE it shows up as “ESP32 Dev Module.” Nothing exotic, no PSRAM requirement, which matters later.

The display is a 1.3-inch SH1106 OLED at I2C address 0x3C. A 0.96-inch SSD1306 also works.

Input is a single EC11 rotary encoder with a pushbutton, or the KY-040 breakout if you hate soldering bare encoders. That one knob carries frequency, volume and mode through LSB, USB, AM, CW and FM.

Audio goes through a MAX98357A I2S class D amplifier into a 4 to 8 ohm speaker. The amp is good for about 3 W, which is loud for a desk and absurd for a pocket. There is a fallback path using the ESP32’s internal DAC on GPIO25 into an LM386, selected with AUDIO_INTERNAL_DAC, and Ivan is candid that it sounds worse. The internal DAC is 8-bit. Your ears will agree with him.

Expect to spend somewhere around fifteen to twenty dollars on parts if you buy from the usual overseas sellers and already own a speaker and jumper wire. Add a USB power bank, and it walks around with you.

If you are building a bench of ESP32 field tools and want the firmware and radio fundamentals behind them laid out in one place, the ESP32 Field Kit: Wireless Research & Offline Hardware Bundle covers the ESP32 and Wi-Fi side of portable recon builds, which is the same toolbox this radio pulls from.

ESP32 Field Kit: Wireless Research & Offline Hardware Bundle

Wiring and First Boot

The sketch uses eight GPIOs, all defined in config.h. The exact pin map lives in a wiring diagram on Ivan's blog rather than in the text, so pull it from there instead of guessing.

The power rules are simple and easy to get wrong at 1 AM. The OLED runs from 3V3. The amplifier runs from VIN, which is the 5 V coming off USB. Every ground joins every other ground. The encoder common and the pushbutton’s second leg both go to GND, and the sketch turns on internal pull-ups, so you skip the resistors.

Two config.h settings save the most frustration:

// Blank screen on a 1.3" panel? It is probably an SH1106, not an SSD1306.
#define OLED_SH1106 1
// Each detent jumping four steps? Many encoders emit two or four per click.
#define ENC_STEPS_PER_DETENT 2

Before compiling, change the partition scheme. In the Arduino IDE go to Tools, then Partition Scheme, and pick “No OTA (2MB APP/2MB SPIFFS).” The sketch is about 1.2 MB, and Ivan reports it dropping from 94 per cent to 59 percent of available flash after the change. You lose over-the-air updates. On a device that lives on your desk next to a USB cable, that is a low price.

Libraries are the Espressif ESP32 Arduino core and U8g2 for the display. Notably absent is any off-the-shelf WebSocket library, for reasons covered below.

First boot puts the ESP32 into access point mode:

SSID:     KiwiRadio-Setup
Password: kiwiradio
Setup:    http://192.168.4.1

Join it, enter your Wi-Fi credentials, pick a KiwiSDR server, and the board reboots onto your network at kiwiradio.local. Settings persist in flash. The same web page gives you full remote control and a diagnostics panel that classifies each audio dropout as network, ESP32 or buffer.

A small security note, because someone has to say it. That setup password is now published in a blog post and a news article. Anyone within Wi-Fi range during first boot can join the setup network and see what you type into it. Do the initial configuration somewhere boring, then treat kiwiradio.local like every other unauthenticated IoT web panel on your LAN. Cheap gadgets with web interfaces belong on the guest VLAN, and this one is no exception.

The Bandwidth Wall and the ADPCM Fix

Here is the part worth the price of admission.

The first version streamed uncompressed audio over a WebSocket. Against nearby Kiwis, it worked. Against distant ones, it cut out constantly. Ivan instrumented it and found the ESP32 receiving about 13.5 audio packets per second when the stream needed about 23.4. The chip was falling behind real time by almost half.

Uncompressed, the stream ran around 24 kB/s. KiwiSDR servers can send IMA ADPCM instead, which encodes each 16-bit sample as a 4-bit difference from a prediction. Four to one. The stream dropped to roughly 6 kB/s, the ESP32 decoded it on the fly, and the audio went clean. His test case was a Kiwi in Argentina played from Germany over a link with about 260 ms of ping.

The interesting lesson is where the bottleneck lived. Twenty-four kilobytes per second is nothing for 802.11n on paper. The ceiling was everything stacked on top of the radio: TCP windowing over a high-latency path, WebSocket framing, the Wi-Fi driver sharing a core, the I2S DMA wanting its buffers on time. Each layer takes a slice, and at 260 ms round trip, a single lost segment stalls the pipe long enough to drain a small buffer. Shrinking the payload by four gave every layer room to breathe.

Datasheets quote the clean room. Your packets live in traffic.

ADPCM decode is cheap integer math, a handful of adds, shifts and a table lookup per sample, which is why a WROOM without PSRAM handles it while also running Wi-Fi and the display. Ivan paired it with a jitter buffer that can grow to two seconds and recovers automatically after a dropout, plus a manual minimum from 100 to 2000 ms and clock drift compensation. Drift matters more than people expect. The Kiwi’s sample clock and your ESP32’s I2S clock are two different crystals on two different continents, and they will never agree exactly. Without compensation the buffer slowly fills or slowly starves, and you get a glitch every few minutes that looks like a network problem and is actually physics.

The other war story is the WebSocket library. The common Arduino one connected and then got dropped by the Kiwi almost immediately, with badp=5 in the server log. Ivan wrote a smaller custom client that also reports why a disconnect happened. When a protocol peer hangs up on you without explanation, the fastest fix is often to stop using the abstraction and speak the protocol yourself. It is a lesson every embedded developer learns once, usually at the worst possible time.

Prototype the Stream Before You Solder

Before committing parts to a breadboard, you can poke a Kiwi from a laptop with kiwiclient, the Python client maintained by KiwiSDR's developer at github.com/jks-prv/kiwiclient. It needs Python 3 and numpy, plus PyYAML for its AGC and scanning options.

$ git clone https://github.com/jks-prv/kiwiclient
$ cd kiwiclient
$ pip3 install numpy pyyaml
$ python3 kiwirecorder.py --help        # the full flag list lives here

A short AM recording from a public receiver looks like this. Swap in a server from the public map at rx.kiwisdr.com and a frequency in kHz.

# 30-second AM capture at 9.42 MHz; writes a timestamped .wav
$ python3 kiwirecorder.py -s kiwi.example.org -p 8073 -f 9420 -m am --tlimit=30

The README also documents -m iq --kiwi-wav --station=name for IQ recordings with GNSS timestamps, and a --nc option that streams raw or WAV samples to standard output, which is the old kiwi_nc program folded into kiwirecorder. Pipe that into sox or ffplay and you have a headless radio in a terminal, which is a decent way to measure how stable a given server is from your location before you trust it with the ESP32.

Keep sessions short. A public KiwiSDR serves a fixed, small number of simultaneous users, and many operators set inactivity or session time limits. Your client occupies a real channel that someone else cannot use. A device that sits tuned to one station all day on a shared receiver is rude, and some operators will block it. If you want always-on listening, run your own Kiwi or an RTL-SDR at home and point the ESP32 at that.

Where This Build Goes Next

Ivan lists the obvious gaps himself. There is no waterfall yet, which needs a colour display. There is no favourites list. Filter bandwidth options and memory presets are thin, and a commenter on his blog asked for adjustable filters, more memory slots and station names. Band switching sits on a double click because giving bands their own encoder focus would have broken step-size adjustment. One knob is a design constraint, and he is honouring it on purpose.

For a cyberdeck builder, the module is the interesting part. Strip the OLED and encoder, keep the WebSocket client and the ADPCM decoder, and you have a radio service that runs on any ESP32 with an I2S DAC. Bolt it into a deck that already has a screen and a keyboard, and the deck gains a shortwave receiver for the cost of a few hundred kilobytes of flash.

The scheduled-listening angle is where it gets fun. A laptop or Pi running kiwirecorder on a timer can capture the same weather fax broadcast or utility net every day and drop the audio into a folder, then hand it to a decoder. Wiring that kind of recurring capture into a bot that pings you on Telegram or Discord when a file lands is exactly the job-plus-integration pattern laid out in the OpenClaw Operator Workstation, whose YAML configs cover scheduled jobs and platform integrations. Keep the schedule polite to the receiver you are borrowing.

OpenClaw Operator Workstation: Local AI Workspace & Runbook

Ivan’s sketch, wiring diagram and write-up are on his Todo-SDR blog, with a Spanish-language video that has English subtitles. Start there, flash it, and go find a receiver on a continent you have never visited. The noise floor on the far side of the world is quieter than yours.

A Shortwave Radio With No Radio Inside It was originally published in Radio Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

How a simple redirect_to parameter can turn a trusted application URL into an unexpected external redirect.

Introduction

Sometimes, while testing a web application, the most interesting findings come from places we do not initially pay much attention to.

A logout endpoint is a good example. Most users expect it to end their session and take them back to a login page. They usually do not think about where the application might send them afterwards.

During a security test, I looked at a logout URL that accepted a parameter named redirect_to. That small detail caught my attention because redirect parameters can introduce security problems when an application does not validate their values properly.

Understanding the Open Redirect Vulnerability

An open redirect occurs when a web application redirects users to a destination controlled by someone else without properly validating that destination.

For example, consider this URL:

https://example.com/api/logout?redirect_to=https://evil.com

Here, example.com represents the application's domain, while evil.com represents an external destination used for testing.

The parameter redirect_to appears to control where the browser goes after the logout request. If the application accepts an arbitrary external URL, the redirect destination is effectively controlled by the person creating the link.

The problem is not necessarily the logout functionality itself. The problem is that the application trusts a destination supplied by the user without restricting where that destination can lead.

How I Investigated the Issue

When testing web applications, I try not to assume that every parameter behaves as its name suggests. Instead, I look at what changes when I modify its value.

In this case, I focused on the logout endpoint and its redirect_to parameter. I wanted to understand whether the application restricted redirects to its own domain or accepted external destinations.

I used a controlled test URL to check how the application handled an external redirect target.

The test URL

GET /api/logout?redirect_to=https://evil.com HTTP/1.1
Host: example.com

The important part of the request is the value supplied to redirect_to.

A secure implementation should validate that value before using it in a redirect response. Simply accepting a URL because it was included in a request is not sufficient.

What I observed

In my test, the application redirected the browser to the external destination supplied in the parameter.

The relevant response would look like this:

HTTP/1.1 302 Found
Location: https://evil.com

The 302 Found status indicates a temporary redirect, while the Location header specifies the destination.

This behaviour confirmed the open redirect condition in the tested scenario. The application accepted an external redirect destination instead of restricting the user to an approved location.

Why Does a Logout Redirect Matter?

At first, this might not look like a serious security issue.

After all, the user is visiting a logout endpoint. They are not necessarily accessing private information, changing account settings, or performing a sensitive operation.

However, the domain shown in a link can influence whether someone trusts it. A user may recognise the application’s domain and assume that the entire link leads to a legitimate page.

An attacker could potentially take advantage of that trust by sharing a link that begins with the legitimate application’s domain but redirects to an unrelated external website.

For example, a user might see the trusted domain in a message, click the link, and then arrive at a fake login page hosted elsewhere. The redirect itself does not steal credentials, but it can make a phishing attempt more convincing.

This distinction matters when evaluating the vulnerability. An open redirect can support a phishing attack, but it does not automatically mean that credential theft, account takeover, or token leakage has occurred.

What Is the Actual Security Impact?

The impact depends on how the affected application is used and how the redirect functionality interacts with other features.

For a logout endpoint, the primary confirmed concern is the ability to redirect a user from a trusted domain to an arbitrary external destination.

Potential consequences include:

• Phishing support: The trusted domain may make a malicious link appear more legitimate.
• Trust abuse: An attacker can use the application’s domain as the starting point of a redirect.
• Security control weaknesses: Redirects may create problems for systems that rely on trusted-domain checks, depending on how those checks are implemented.
• Authentication-flow risks: If similar redirect behaviour is present in OAuth, SSO, or other sensitive workflows, the impact could be greater.

The last point requires particular care. A redirect vulnerability in a logout endpoint does not prove that OAuth tokens, authorisation codes, or session credentials can be stolen.

Those outcomes require separate evidence showing that sensitive information is actually exposed or that another security control can be bypassed.

For this finding, I would focus the report on the behaviour that was demonstrated: an externally controlled redirect after logout.

How Should This Vulnerability Be Classified?

The appropriate classification is Open Redirect, also known as an unvalidated redirect.

The relevant Common Weakness Enumeration identifier is CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’).

The finding is also relevant to web application security testing guidance concerning client-side redirection.

What about severity?

Severity is one of the most important parts of a bug bounty report, and it is also one of the easiest parts to overestimate.

For a logout-only endpoint where the main impact is trust abuse and phishing support, Low severity may be more appropriate under some bug bounty programs. A program may also classify the issue as informational or decline it if its policy excludes standalone open redirects.

I would not assign High severity based only on the possibility that the issue could be combined with OAuth, SSO, or token leakage. Those scenarios need to be tested and supported by evidence.

This approach makes a report more credible because it separates the confirmed vulnerability from the risks that might exist in other circumstances.

How Can Developers Fix It?

The good news is that open redirects are generally straightforward to prevent when the application does not need arbitrary external destinations.

1. Allow only approved destinations

The safest approach is to accept relative paths such as /login or /dashboard when the application only needs to redirect users internally.

If external destinations are required, developers should use a strict allowlist of approved hosts rather than accepting arbitrary URLs.

2. Validate the destination on the server

Redirect validation should happen on the server before the application sends a redirect response.

The application should parse the URL and verify its scheme, hostname, and other relevant components. Checking only whether the string contains the trusted domain is not sufficient.

For example, a URL such as https://example.com@evil.com has evil.com as its hostname, even though the trusted domain appears in the URL.

3. Handle unusual URL formats carefully

Developers should also consider scheme-relative URLs, backslashes, encoded characters, and differences between URL parsers.

Validation must match the way the application ultimately interprets the URL. Otherwise, a value that appears safe during an initial string check may still resolve to an untrusted destination.

4. Use a fixed destination after logout

If the application does not need customizable redirect destinations, the simplest solution may be to remove the user-controlled parameter entirely.

After logout, the server can send the user to a predefined location, such as /login. This reduces complexity and removes an unnecessary source of risk.

Lessons for Bug Bounty Hunters

This test was a useful reminder that security testing is not only about discovering complicated vulnerabilities.

Small parameters can reveal important assumptions in an application’s design. A redirect parameter may look harmless, but its security depends on how the server validates and uses the supplied value.

When I investigate a possible open redirect, I want to answer three questions:

1. Can I control the destination?
2. Does the server actually redirect to an untrusted external destination?
3. What security impact can I demonstrate beyond the redirect itself?

The third question is especially important. A technically valid vulnerability and a reportable bug bounty finding are not always the same thing.

Understanding the difference helps produce better reports, supports more accurate severity ratings, and avoids overstating what a proof of concept actually demonstrates.

Final Thoughts

An open redirect in a logout endpoint may appear minor, but it is worth investigating because it shows how an application handles user-controlled destinations.

The key is to report what the evidence proves. If the browser is redirected to an arbitrary external URL, document the request, the response, and the resulting behaviour. Then explain the realistic risks without claiming an account takeover or credential leak that has not been demonstrated.

For developers, strict redirect validation or a fixed post-logout destination can prevent this class of issue. For bug bounty hunters, the lesson is simple: test carefully, verify the behaviour, and let the evidence determine the severity.

AI assistance: I used an AI-powered grammar and spelling checker to review this article. The ideas, research, technical analysis, and final content are my own.

Have questions or want to share your own workflow? Drop a comment below or connect with me on :

🔗Linkdin: https://www.linkedin.com/company/sam-shield/

🔗Youtube: https://www.youtube.com/@sam_shield-w7l

🔗Medium: https://medium.com/@samadhanshimple

How a Logout Endpoint Led to an Open Redirect Vulnerability was originally published in Radio Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

An ingenious discovery revealed that the ESP32 has a hidden capability: capturing raw I/Q samples from radio signals. This opened the door to ESP-SDR, an ultra-low-cost software-defined radio built around the ESP32.

In this article, I’ll show you how to use ESP-SDR to capture radio signals and bring those raw I/Q samples into Python for analysis and signal processing.

Step-1:Installing esp-sdr firmware:

There are two ways to install ESP-SDR firmware on your ESP32. You can either build the firmware yourself from the official ESP-SDR GitHub repository or install a prebuilt firmware directly from the ESP-SDR website.

The second option is by far the easiest. Simply connect your ESP32 board to your computer using a USB cable, open the ESP-SDR website, and follow the installation instructions provided there. I’ll skip the detailed installation steps since the website makes the process straightforward.

Once the firmware is installed, it’s a good idea to verify that everything is working correctly. You can do this using the browser-based ESP-SDR Viewer.

Connect your ESP32 and open the viewer. If everything is working as expected, you should start seeing the frequency spectrum and waterfall display, as shown below.

After verifying the firmware is working properly, we can move on to the next step.

Step 2: Building the Python code:

Before diving into the code, let’s take a moment to understand how the ESP-SDR firmware communicates with our Python application.

The firmware uses a standard USB serial interface for communication. It implements a simple, text-based command protocol through which we can send commands and receive responses. If you’re interested in exploring the protocol in detail, you can find the complete command reference in the official ESP-SDR documentation.

In this article, however, I’ll focus only on the commands necessary to capture raw I/Q samples at a specified frequency.

One important thing to note is that continuous I/Q capture and streaming are not supported by every ESP32 variant. Only the ESP32-S3 and ESP32-S31 support continuous capture and streaming. Other variants support only burst-mode capture. You can read the detailed info about capabilities supported by each ESP32 variant here

What exactly does burst mode mean? When we issue a capture command, the firmware captures a fixed number of samples and sends them to our application. To capture the next batch of samples, we must issue another capture command. This introduces a delay between consecutive captures, unlike continuous streaming, where samples are captured and transmitted continuously.

I’m using an ESP32-C6, which supports only burst-mode I/Q capture. So, in the following sections, I’ll walk you through the commands and Python code required to capture I/Q samples using this mode.

Connecting to the firmware:

Connecting with the firmware:

PORT = "/dev/ttyACM0"     # Serial port in my Linux system(Rpi5) where esp32 is connected
BAUD = 2000000            # Default baud rate
FREQ = 2457               # Center frequency the chip should tune in
SAMPLE_RATE = 80e6        # Sample rate; In this case 80M samples/second

ser = serial.Serial(PORT, BAUD, timeout=3) # Connecting to esp32

A Helper Function to Send Commands to the ESP32

Sending commands to the ESP32 and reading its responses is something we’ll need to do repeatedly throughout this program. Rather than writing the same serial communication code over and over again, let’s create a small helper function to handle this operation.

With this function in place, we can easily send commands to the firmware and retrieve its responses whenever needed, keeping the rest of our code clean and readable.

def command(cmd):
ser.write((cmd + '\n').encode())
ser.flush()
response = ser.readline().decode(errors="replace").strip()
print("TX:", cmd)
print("RX:", response)
return response

Synchronising with the ESP32

Before we begin communicating with the firmware, we first need to synchronise with the ESP32. This ensures that both sides are ready to exchange commands and responses.

The following example shows the synchronisation process. In the command logs, TX: indicates a command transmitted by our Python application to the ESP32, while RX: represents the response received from the firmware.

Let’s look at the commands and their corresponding responses:

The synchronisation command has the following format:

TX: SYNC <nonce>
RX: SYNC <nonce>

Here, nonce is a number generated by our Python application and sent to the firmware. The firmware should respond with a SYNC command containing the same nonce. If the received response matches the command we sent, synchronisation is considered successful.

Once synchronisation is established, we can proceed with sending other commands to the firmware.

Corresponding Python code:

Corresponding Code:
nounce = 123456789  # I am using a fixed nounce here, a random nounce will be better.

response = command(f"SYNC {nounce}")
if response!= f"SYNC {nounce}":
    raise RuntimeError(f"Synchronization with the firmware failed")

Setting the Capture Frequency

Before capturing I/Q samples, we need to configure the RF centre frequency. We can do this using the FREQ command.

The command format and firmware response are shown below:

TX: FREQ <frequency>
RX: OK

Here, <frequency> specifies the desired centre frequency in MHz. The firmware responds with OK once the frequency configuration is successful.

Corresponding Python code:

command(f"FREQ {freq}")

In our example, freq is set to 2457 MHz, corresponding to Wi-Fi channel 10 in the 2.4 GHz band.

Issuing the Capture Command

Now that we have configured the centre frequency, we’re ready to capture I/Q samples. We can initiate the capture process using the CAP16 command.

The command follows this format:

TX: CAP16 <num_samples> <rate_code>
RX: DATA <num_samples> <CRC> <time_in_us>

In this example, I’m using 16000 as the number of samples and 0 as the rate code, which corresponds to a sampling rate of 80 MSamples/s.

Therefore, our capture command will be:

TX:CAP16 16000 0

Once the command is issued, the firmware captures the requested number of samples and responds with a DATA message containing three important pieces of information:

RX:DATA 16000 c71df737 47  # This line is known as header

#Here 16000 is the number of samples captured and c71df737 is the CRC, and 47 
# is the time in microsecond took to capture data.

• num_samples: The actual number of samples captured.
• CRC: A Cyclic Redundancy Check value used to verify the integrity of the received data and detect transmission errors.
• time_in_us: The time taken to capture the samples, expressed in microseconds.

The firmware then transfers the captured I/Q data to our Python application. We’ll look at how to receive and process this binary data in the next section.

Corresponding Python code:

Corresponding Code:
header = command(f"CAP16 {num_samples} {rate_code}")
    parts = header.split()
    if parts[0] != "DATA":
      raise RuntimeError("Invalid response")
    count = int(parts[1])
    expected_crc = int(parts[2], 16) # Parameter 16 is passed because crc is hex
    capture_us = float(parts[3])

# I think the code is self explanatory

Reading the Captured I/Q Samples

After issuing the capture command, the firmware first sends a response header containing the metadata we discussed earlier. It then starts transmitting the captured I/Q data over the serial interface.

We need to read this binary data from the serial port. However, there’s one important detail to consider: the firmware may transmit the data in multiple chunks rather than sending it all at once.

If we simply call ser.read() and expect to receive the entire dataset in a single operation, we may end up with incomplete data or a serial timeout.

To handle this, let’s introduce a helper function called read_exact(). It keeps reading from the serial port until the requested number of bytes has been received.

The function:

def read_exact(size):
    data = bytearray()

    while len(data) < size:
        chunk = ser.read(size - len(data))

        if not chunk:
            raise TimeoutError("Serial timeout")

        data.extend(chunk)

    return bytes(data)

The function is straightforward:

1. It initialises an empty bytearray to accumulate the received data.
2. It repeatedly reads the remaining number of bytes from the serial port.
3. Each received chunk is appended to the buffer.
4. If a read operation times out before all the requested bytes arrive, it raises a TimeoutError.
5. Once all the bytes have been received, it returns the complete data as a bytes object.

This ensures that we don’t accidentally process an incomplete I/Q capture.

Understanding the I/Q Sample Data Format

After transmitting the header, the firmware sends the actual I/Q sample data over the serial interface.

Each sample consists of two components: an in-phase (I) component and a quadrature (Q) component. Each component is represented by a signed 8-bit integer (1 byte).

Therefore, for 16,000 complex samples, we’ll receive:

16000 x 2 = 32000 bytes

The byte arrangement follows this pattern:

I0 Q0 I1 Q1 I2 Q2 I3 Q3 ...

At this stage, we don’t need to separate the I and Q components. Instead, we’ll read the entire dataset into a single buffer and process it later.

Corresponding Python code:

raw = read_exact(count * 2)  # count = 16000 samples

Since each complex sample contains two bytes (one for I and one for Q), we multiply the sample count by two to determine the total number of bytes to read.

We now have the complete raw I/Q data in memory, ready for further processing.

Verifying Data Integrity Using CRC

Now that we’ve received the complete I/Q dataset, the next step is to verify its integrity. During transmission, data can potentially get corrupted, so we need a way to ensure that the received bytes match what the firmware originally transmitted.

Fortunately, the firmware provides a CRC (Cyclic Redundancy Check) value in the response header. We can calculate the CRC of the received data and compare it with the expected CRC provided by the firmware.

Corresponding Python code:

actual_crc = zlib.crc32(raw) & 0xffffffff
if expected_crc != actual_crc:
    raise RuntimeError("CRC Mismatch")
else:
    print("CRC Check OK")

Separating I and Q Components

Now that we’ve successfully received the data and verified its integrity using CRC, we can move on to processing the I/Q samples.

The next step is to separate the interleaved I and Q components into two independent NumPy arrays. We’ll then combine them into complex numbers, which makes subsequent signal processing operations much easier.

Corresponding Python code:

data = np.frombuffer(raw, dtype=np.int8)

I = data[0::2].astype(np.float32)   # Extract I components
Q = -data[1::2].astype(np.float32)  # Extract Q components

samples = I + 1j * Q               # Combine into complex samples

Let’s break this down:

• np.frombuffer(): Interprets the raw byte buffer as an array of signed 8-bit integers.
• I = data[0::2]: Extracts every other element starting from index 0, giving us the I components.
• Q = -data[1::2]: Extracts every other element starting from index 1, giving us the Q components. Notice that we negate the Q values to account for the I/Q sign convention used here.
• samples = I + 1j * Q: Combines the two arrays into a single array of complex numbers.

We now have our I/Q data represented as complex-valued NumPy samples, ready for further signal processing and analysis.

Now, the samples variable contains our captured I/Q data as a complex-valued NumPy array. And finally, we've done it! We've successfully captured raw I/Q samples from the airwaves using nothing more than an ESP32.

But capturing the data is only half the fun. Let’s explore what we’ve captured by plotting the waveform and visualising the I/Q samples.

In the next section, we’ll use Matplotlib to plot the signal amplitude over time and see what our captured RF signal actually looks like.

Plotting I and Q Components Against Time

Now that we have our I/Q samples in a complex-valued NumPy array, let’s visualise them. We’ll plot the I and Q components separately against time to see how the captured signal varies.

Since our sampling rate is 80 M Samples/s, the time interval between consecutive samples is:

Ts = 1 / (80 × 1⁰⁶) = 12.5 ns

We can construct a time axis using the sampling rate and plot both components using Matplotlib.

Corresponding Python code:

N = len(samples)
# Time axis in microseconds
time = np.arange(N) / SAMPLE_RATE * 1e6
plt.figure(figsize=(12, 5))
plt.plot(time, samples.real, label="I")
plt.plot(time, samples.imag, label="Q")
plt.xlabel("Time (µs)")
plt.ylabel("Amplitude")
plt.title("Received IQ Signal")
plt.legend()
plt.grid(True)
plt.tight_layout()
plt.show()

Let’s break down what’s happening here:

• N = len(samples) gives us the total number of complex samples.
• np.arange(N) / SAMPLE_RATE generates the time instant corresponding to each sample.
• Multiplying by (10⁶) converts the time axis from seconds to microseconds.
• samples.real extracts the I component, while samples.imag extracts the Q component.

Finally, Matplotlib plots both components on the same graph, allowing us to observe how the I and Q signals vary over time.

And there we have it! We’ve successfully captured raw RF I/Q samples using an ESP32 and visualised them in Python.

Plotting Magnitude against time:

magnitude = np.abs(samples)

plt.figure(figsize=(12, 4))
plt.plot(time, magnitude)
plt.xlabel("Time (µs)")
plt.ylabel("Magnitude")
plt.title("IQ Signal Magnitude")
plt.grid(True)
plt.show()

IQ scatter plot:

I = samples.real
Q = samples.imag

plt.figure(figsize=(8, 8))
plt.scatter(I, Q, s=2, alpha=0.5)
plt.xlabel("In-phase (I)")
plt.ylabel("Quadrature (Q)")
plt.title("IQ Scatter Plot")
plt.axhline(0, color="gray", linewidth=0.5)
plt.axvline(0, color="gray", linewidth=0.5)
plt.grid(True)
plt.axis("equal")
plt.tight_layout()
plt.show()

Playing with IQ Samples: A Little DSP with Python

Now, let's do some simple signal processing on the captured signal

Calculating Signal Power

One of the simplest signal-processing operations we can perform on captured IQ samples is calculating signal power. This is useful for identifying periods of increased RF activity and detecting possible wireless transmissions.

An IQ sample consists of two components: the in-phase component (I) and the quadrature component (Q).

The instantaneous signal power can be calculated by squaring both components and adding them together:

P[n] = I[n]² + Q[n]²

We can implement this easily using NumPy:

import numpy as np
import matplotlib.pyplot as plt

# Calculate instantaneous power
power = I**2 + Q**2
# Plot signal power
plt.figure(figsize=(12, 5))
plt.plot(power)
plt.xlabel("Sample")
plt.ylabel("Normalized Power")
plt.title("Instantaneous Signal Power")
plt.grid()
plt.show()

The resulting plot shows how signal power varies across the captured samples.

However, instantaneous power can fluctuate considerably between consecutive samples. To obtain a smoother representation, we can calculate the moving average of the signal power.

A moving average filter calculates the average power over a sliding window of samples. For example, with a window size of 100, it calculates the average power of 100 consecutive samples and then moves forward by one sample to repeat the calculation.

We can implement this using NumPy’s convolution function:

window = 100

avg_power = np.convolve(
    power,
    np.ones(window) / window,
    mode="valid"
)
plt.figure(figsize=(12, 5))
plt.plot(avg_power)
plt.xlabel("Sample")
plt.ylabel("Average Power")
plt.title("Moving Average Signal Power")
plt.grid()
plt.show()

The moving average smooths out short-term power fluctuations, making it easier to observe changes in signal activity.

This technique is particularly useful for detecting possible Wi-Fi transmissions, since wireless transmissions generally produce periods of increased received signal energy.

Note: The calculated power is expressed in normalised digital units squared when the IQ samples are normalised. It is not an absolute RF power measurement in watts or dBm.

Applying a Low-Pass Filter

Another interesting signal-processing operation we can perform on captured IQ samples is low-pass filtering.

A low-pass filter allows frequency components below a specified cutoff frequency to pass through while attenuating higher-frequency components. This is useful for removing unwanted high-frequency components and isolating a particular frequency range.

We can use SciPy to implement a Butterworth low-pass filter. A Butterworth filter has a maximally flat frequency response in its passband.

Let’s apply a fifth-order Butterworth filter with a cutoff frequency of 5 MHz to our captured IQ samples.

import numpy as np
import matplotlib.pyplot as plt
from scipy.signal import butter, sosfilt

# Combine I and Q into a complex IQ signal
iq = I + 1j * Q
# Sampling frequency
Fs = 80e6
# Design a fifth-order Butterworth low-pass filter
cutoff = 5e6
sos = butter(
    5,
    cutoff,
    fs=Fs,
    output="sos"
)
# Apply the filter
filtered = sosfilt(sos, iq)
# Plot original and filtered signals
plt.figure(figsize=(12, 5))
plt.plot(np.real(iq[:1000]), label="Original")
plt.plot(np.real(filtered[:1000]), label="Filtered")
plt.xlabel("Sample")
plt.ylabel("Amplitude")
plt.title("Low-Pass Filtering")
plt.legend()
plt.grid()
plt.show()

Here, we first combine the I and Q components into a complex signal. We then design a Butterworth filter using SciPy and apply it to the complex IQ samples.

The cutoff frequency determines which frequency components are retained. In this example, frequencies near the baseband DC component and below approximately 5 MHz are passed, while higher-frequency components are attenuated.

This demonstrates how we can manipulate captured RF signals entirely in software using Python.

Note: The filter operates on the complex baseband IQ signal, not directly on the original 2.4 GHz RF carrier. Also, the cutoff frequency is relative to the receiver’s tuned centre frequency.

Time to Wrap Up

My ultimate dream is to decode a complete Wi-Fi frame entirely in Python. Whether that’s possible with the ESP32-C6 remains to be seen, but I’m certainly going to give it my best shot!

I hope this article serves as a starting point for others interested in experimenting with ESP-SDR hardware and RF signal processing using Python. There’s still so much to explore, and I’d love to see others take this further and share their experiments.

Until then, happy ESP-SDR experimentation and Python-based RF signal processing!

Here you can find my GitHub Repository containing the Python code to capture and plot IQ samples.

Turn Your ESP32 into an SDR: Capturing and Analyzing 2.4 GHz Signals with Python was originally published in Radio Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

A practical bug bounty story about testing authorisation, manipulating request parameters, and finding a potential IDOR vulnerability.

Introduction

While testing a web application’s folder-creation functionality, I noticed something interesting. The application sent an email address along with the request whenever a user created a new folder.

At first, this looked like a normal part of the application’s functionality. But it raised an important security question: Does the server verify which account the authenticated user is allowed to modify, or does it trust the email address sent by the browser?

To investigate this behaviour, I used two test accounts and Burp Suite to examine how the application handled folder-creation requests.

Understanding the Vulnerability

Broken Access Control occurs when an application fails to properly enforce permissions for a requested action or resource.

For example, a user should not be able to modify another user’s account simply by changing an identifier in an HTTP request.

One related vulnerability is Insecure Direct Object Reference (IDOR). It occurs when an application uses a user-controlled reference to access an object without properly checking whether the current user is authorised to access it.

In this case, the parameter of interest was an email address associated with the folder-creation request.

If the server accepts a modified email address and performs an action in another user’s account without checking permissions, this may indicate a cross-account authorisation flaw.

My Testing Setup

For this test, I used two accounts that I controlled.

• Account 1: The account used to initiate the folder-creation request.
• Account 2: The account used to verify whether the folder appeared in another account.

I logged in to both accounts using separate browser sessions. This helped me compare the behaviour of each account without confusing their authenticated sessions.

I used Burp Suite to intercept and inspect the HTTP request generated when creating a folder.

Step 1: Create a Folder in Account 1

I started by logging in to Account 1 and opening the folder-management feature.

Next, I used the Add Folder functionality to create a new folder. Before forwarding the request, I intercepted it in Burp Suite.

I examined the request parameters to understand how the application identified the account associated with the new folder.

Step 2: Identify the Email Parameter

While inspecting the request, I noticed that it contained an email parameter.

This was worth investigating because an email address is an identifier, not proof that a user has permission to modify the associated account.

A secure application should verify the authenticated user’s permissions on the server. It should not rely on a client-controlled parameter to make authorisation decisions.

Step 3: Modify the Request

To test the authorisation boundary, I changed the email parameter from Account 1’s email address to the email address associated with Account 2.

I then forwarded the modified request using Burp Suite.

The purpose of this test was to determine whether the server would reject an operation targeting an account that the authenticated user was not authorised to manage.

This type of test can help identify authorisation checks that are missing or incorrectly implemented.

Step 4: Verify the Result

After forwarding the request, I checked Account 2 to see whether the folder had been created.

The observed result was that the folder appeared in Account 2.

This was an important finding because the request originated from Account 1, but the folder was created under Account 2 after the email parameter was changed.

Based on this result, the behaviour suggested that the application might be using the supplied email address to determine the target account without properly enforcing the required authorisation checks.

However, the exact cause still needs to be confirmed. For example, the application could have an intended delegation feature or another authorisation rule that affects the result.

Why Is This a Security Issue?

Creating a folder might seem like a minor action. However, security testing is not only about how sensitive an operation appears; it is also about whether the operation respects account boundaries.

If an authenticated user can create folders in another user’s account without permission, the application may allow unauthorised changes to that user’s workspace.

Depending on how the application uses folders, this could create unwanted content, interfere with organisation, or affect workflows that depend on folder ownership.

The impact should be limited to what has actually been demonstrated. If only folder creation has been verified, it would be incorrect to claim that the vulnerability also allows file access, data theft, deletion, or account takeover.

How Should This Vulnerability Be Classified?

The most appropriate classification depends on the application’s behaviour and intended access-control model.

Potential vulnerability: Broken Access Control

Related CWE: CWE-639 — Authorisation Bypass Through User-Controlled Key, if the evidence confirms that a user-controlled key is used to access or modify another user’s resource without proper authorisation.

OWASP category: A01:2021 — Broken Access Control.

Affected feature: Add Folder.

Authentication: Required in the observed scenario.

What About Severity?

Severity depends on the impact and the application’s security requirements.

The final rating should follow the bug bounty program’s severity guidelines. A parameter change alone does not automatically qualify as a high-severity IDOR.

How Developers Can Prevent This Issue

There are several ways to reduce the risk of this type of authorisation weakness.

1. Do not trust client-supplied identity parameters.

An email address supplied by a browser should not, by itself, determine which account a user can modify.

2. Enforce authorisation on the server.

Before creating a folder, the application should check whether the authenticated user has permission to perform the requested action in the target account.

3. Test with multiple accounts.

Authorisation testing should include requests made by one user that reference resources belonging to another user. Both permitted and denied actions should be tested.

4. Add automated authorisation tests.

Developers should test that users cannot create, update, or delete resources in other accounts unless the application’s permission model explicitly allows it.

Lessons Learned

This test reinforced an important lesson: a small request parameter can reveal a significant authorisation weakness.

The email parameter was not inherently vulnerable. The security concern was whether the server used that value without independently verifying the user’s permissions.

For bug bounty hunters, the important part is to identify the account boundary, test it safely with authorised accounts, and verify the actual result.

A reliable report should explain what was changed, what the server did, why the behaviour violates the expected permission model, and what impact was demonstrated.

Final Thoughts

Broken Access Control is worth testing because applications often rely on identifiers such as email addresses, user IDs, workspace IDs, or organisation IDs when processing requests.

Changing an identifier is only the beginning of the test. The real question is whether the server correctly checks authorisation before performing the action.

In this scenario, the folder appeared in the second account after the email parameter was changed. That observation provides a strong reason to investigate the application’s account-level authorisation logic further.

Remember: Report what you can reproduce, demonstrate the impact you can prove, and avoid claiming consequences that you have not verified.

AI assistance: I used an AI-powered grammar and spelling checker to review this article. The ideas, research, technical analysis, and final content are my own.

Have questions or want to share your own workflow? Drop a comment below or connect with me on :

🔗Linkdin: https://www.linkedin.com/company/sam-shield/

🔗Youtube: https://www.youtube.com/@sam_shield-w7l

🔗Medium: https://medium.com/@samadhanshimple

One Email Parameter Was All It Took: How Broken Access Control Let Me Create a Folder in Another… was originally published in Radio Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.

Every December, we do the same thing everyone in the security sector does. We pull the previous year’s data, count the vulnerabilities, and try to figure out what the numbers are trying to say. It’s become a regular ritual for folks running this space, and every year the data tells us something we didn’t expect going in.

Last year, our platform and pentests logged 6.8 million findings across 8,000+ engagements, and the most useful insights this year were about the geography of vulnerabilities. Where exposures actually live, versus where our testing programs are scoped to find them.

To put it simply, we ignored the costliest vulnerabilities in front of us while patching the simplest ones.

We wrote all of this up in the State of Continuous Pentesting Report 2026 if you want the full breakdown. Here’s the short version.

80% of Cloud Credential Leaks Were Found in Mobile Pentests

In 2025, 80% of tracked AWS and S3 credential exposure was surfaced during mobile app pentests, and cloud infrastructure scans caught the other 20%.

Devs often embed an IAM access key or a hardcoded secret into a mobile client to skip a backend round-trip during a sprint. Once the APK or IPA ships, that key sits in the binary with no clear owner.

Anyone with strings, APKtool, or a five-line Frida script can pull the credentials, and our data showed this single gap carried over a million dollars in tracked financial exposure before anyone went looking for it deliberately.

Other Findings Worth Sitting With

Cloud vulnerabilities grew 44x in 2025 while cloud pentesting coverage grew 1.23x, which works out to a 37-to-1 disparity between where risk is growing and where testing is scaling. Cloud alone now drives 39% of vulnerability volume on 14% of pentest engagements, and cloud pentests return an average of 7,480 findings per engagement against 3,060 for web, roughly 2.4x the yield at a fraction of the coverage.

Severity tells its own story. In 2024, 1 in 40 findings was Critical, and in 2025 it was 1 in 10. Criticals grew 14.6x faster than everything else, and a critical vulnerability was found somewhere on the platform every 48 seconds. Dashboards reporting “total findings up 275%” flatten all of that into background noise.

The strangest phenomenon in the data was December itself. It produced 1.8 million vulnerabilities, more than all of 2024 combined. Most of that pileup was locked in a month earlier, in November, which was the quietest scanning month of the year by a wide margin. Every quiet November builds a loud December, and the security folks and devs on call over the holidays wear it.

Then there’s Q3 versus Q4. Q4 had 63% more raw findings, so the count-based dashboards flagged it as the crisis quarter, but September alone was the most dangerous month of the year, and Q3 was 29% more dangerous per finding than Q4.

The teams that treated Q4 as the crisis spent their best engineers on a compliance surge, while September sat quietly producing the most serious findings of the year with whoever was left.

The report breaks all of this down quarter by quarter.

IDOR Is Everywhere, and Nobody’s Fixing It

IDOR (Insecure Direct Object Reference) was the only vulnerability class in the 2025 dataset that appeared across all six tested surfaces simultaneously: web, API, cloud, iOS, Android, and network. Every other class in the dataset has a home surface. IDOR carries $1.1M in tracked financial exposure, the highest of any single vulnerability class in the dataset.

IDOR is a consequence of how dev teams reason about data ownership when they’re building API endpoints under sprint pressure. Fixing IDOR at the design layer means treating it as a cross-surface architectural pattern instead of a per-surface finding.

This is exactly where our Autonomous Pentesting product, rolling out to customers this year, changes the shape of the problem. It runs continuously against every deployment, reasons about application architecture the way a human pentester would, and surfaces IDOR patterns easily.

What to Fix Now

None of the shifts below requires a bigger budget, and all of them are executable inside your existing program. If you take only one thing from the 2025 data, it’s that most security teams already have the tools they need. What’s missing is the wiring between how the attack surface behaves and how the program is set up to read it.

• Assign ownership to cross-surface findings: A hardcoded cloud key in a mobile binary belongs to nobody today. It gets forwarded between the mobile lead and the cloud lead until someone drops it. Designate a single owner for any finding that spans two or more scopes.
• Retire “total findings” as a risk metric: Measure by severity, exploitability, and business impact. If your dashboard can’t tell 2024 from 2025 because the total grew smoothly, it’s measuring throughput instead of risk.
• Budget by attack surface, not by legacy scope: If cloud drives 39% of risk, it should get more than 14% of the security spend. If 80% of your cloud credential exposure surfaces in a mobile scope, mobile is part of your cloud program.

Final Thoughts

The hardest problem in our sector is admitting that vulnerabilities don’t live where the org chart says they should.

The credential in the binary, the cloud risk on a web budget, and the Critical hidden inside a “total findings grew 275%” headline. All of it was visible, all of it filed in the wrong column, and read by the team that wasn’t asked to look.

The exposures are already there, and it’s about time we ask whether your security strategy is scoped to see them.

If any of this rhymes with what your dashboards are showing, you can read the full State of Continuous Pentesting 2026 report here.

SAST tells you what could be exploited based on how the code is written. DAST tells you what actually can be exploited when the app is running. Mature programs run both, because each covers the other’s blind spots.

Vulnerability Statistics 2026: 6.8 Million Findings Show Risk Isn’t Where You’re Testing was originally published in Radio Hackers on Medium, where people are continuing the conversation by highlighting and responding to this story.