CVE-2026-48117 - Account Takeover via Pre-Registration Attack in DroneAware Node

TL;DR

• CVE: CVE-2026-48117
• Severity: Moderate (CVSS 6.8)
• Advisory: GHSA-h243-pmjf-chcj
• Patched: server-2026-05-20

This post describes an authentication vulnerability I found in DroneAware Node that allowed full account takeover of any user whose email address is known. The issue was responsibly disclosed to the maintainers and has since been patched.

Context

I came across DroneAware while doing research on drone protocols — specifically while building RemoteID Spoofer and Receiver, a tool that works with the Remote ID standard used by drones to broadcast their identity and position. DroneAware Node is an open-source server component in that same ecosystem: it receives and aggregates those broadcasts to provide airspace awareness and drone monitoring. Operators and drone pilots use it to track airspace activity, manage drone registrations, and coordinate with other users in shared airspace. Accounts hold flight records, location history, and operator configuration — data that is sensitive both in civilian and restricted-airspace contexts.

Registration supports two paths: standard email/password signup followed by an email verification step, or Google SSO for users who prefer to authenticate through their Google account. Both paths converge on the same account activation flow — and that is exactly where the vulnerability lives.

This is a classic Pre-Account Takeover scenario: a class of attack where an adversary claims a victim’s identity on a platform before the legitimate user ever registers, then waits for the victim’s own actions to silently hand over access. The only prerequisite is knowing the target’s email address.

Root Cause

The root cause is simple: the application allowed an attacker to register an account with a victim’s email address and an attacker-chosen password before the legitimate owner ever signed up. On its own, this is harmless — the account is unverified. The problem is what happens next.

When the real user eventually registers or logs in, the platform activates the account. This activation step also silently enables all previously-set authentication methods — including the attacker’s password. From that moment on, the attacker can log in with their own password, and the victim has no idea.

There are two ways this plays out:

Google SSO path

1. Attacker registers victim@example.com with a password of their choice.
2. Victim later signs in with Google (“Login with Google”).
3. Google SSO triggers account activation on the platform.
4. The pre-set password is now valid. Attacker logs in.

Email verification path

1. Same pre-registration step.
2. Victim registers normally and clicks the verification link in their email.
3. Verification activates the account, again enabling the attacker’s password.
4. Attacker has access.

In both cases:

• The victim receives no notification that password authentication was enabled on their account.
• The attacker’s access persists silently until the victim manually changes their password — which they have no reason to do.
• Exploitation requires only normal user behavior from the victim.

Impact

The bar for exploitation is low: an attacker only needs the victim’s email address. No phishing, no credential stuffing, no interaction from the victim beyond their normal registration or first login.

Any account whose email can be predicted or guessed is at risk. Once inside, the attacker has full access to the account: flight records, location history, registered drones, operator settings, and any actions the platform permits. In airspace monitoring contexts this can mean access to sensitive operational data about where drones are being flown and by whom — information that could be valuable in both civil and restricted-airspace scenarios.

The attacker’s access persists silently. The victim has no indication that a parallel credential exists on their account and no reason to change a password they never set.

Fix

The patch (server-2026-05-20) addresses both attack paths:

• Google SSO: when activating a previously unverified account, any pre-set password is now cleared before activation completes.
• Email verification: the token lifetime was reduced from 24 hours to 30 minutes, shrinking the window for pre-registration abuse.

There is no workaround — this required a server-side fix.

Weaknesses

• CWE-287 — Improper Authentication
• CWE-302 — Authentication Bypass by Assumed-Immutable Data

Disclosure

Reported to the DroneAware maintainers and acknowledged promptly. The fix was deployed before public disclosure.