My first security vulnerability

I found my first security vulnerability on the fifth day of an Android security research course. I wasn't expecting it. I was still trying to figure out how to use the tools properly.

The setup

The course involved analysing Android APKs — decompiling them, reading the manifest, poking at the exported components. I was working through a practice application that was intentionally insecure, the kind used for security training.

One of the first things you learn in Android security is to read the AndroidManifest.xml carefully. Every component — activities, services, broadcast receivers — can be declared as exported, meaning other apps on the device can interact with them. If a component is exported and has no permission check, that's a door without a lock.

What I found

The app had an activity declared like this:

<activity
  android:name=".AdminPanelActivity"
  android:exported="true" />

No android:permission attribute. No intent filter that would limit who could call it. Just… open.

I wrote a simple test app — literally a button that fired an explicit intent at AdminPanelActivity. Launched it. The admin panel opened. No authentication, no check, no warning.

Any app installed on the same device could do this. A game, a calculator, a fake utility app — any of them could launch the admin panel directly.

The vulnerability wasn't complex. That's what made it instructive. The most dangerous bugs are often the simplest ones, hiding in plain sight in a config file.

What it means in practice

In a real app, an exported activity without a permission check is a privilege escalation vector. If AdminPanelActivity had any functionality — change user roles, access payment info, modify app data — an attacker could access it without ever breaking encryption or guessing a password. They'd just call the component directly.

Android has a permission system specifically for this. Declaring android:permission="com.example.ADMIN" on the activity means only apps that hold that permission can launch it. It's one attribute. One line.

The lesson that actually stuck

Reading about exported components is different from finding one. When I fired that intent and the admin panel opened, it clicked in a different way. The vulnerability wasn't theoretical anymore — it was a button on my screen.

Security research works this way a lot. You can read about SQL injection, XSS, IDOR, path traversal — but until you've executed one in a controlled environment and watched it work, the mental model stays abstract. The hands-on experience builds pattern recognition that reading alone doesn't.

The other lesson: read the manifest first. Always. Before you look at the code, before you run the app, read AndroidManifest.xml. The attack surface is right there.

Final thoughts

That first find was a training app designed to be broken. But the pattern it taught me — look for exported components, check for permission attributes, verify what's actually protected — applies to real applications.

Curiosity is the right disposition for security work. Not "this is probably fine" but "let me check if this is actually fine." Those are very different mental habits, and the second one is worth cultivating deliberately.