arXiv CSopen access

Control-Aware Manipulation of ArduPilot via Legitimate MAVLink Commands: Simulation and Hardware Validation

1

Control-Aware Manipulation of ArduPilot via Legitimate MAVLink Commands: Simulation and Hardware Validation

arXiv:2606.22289v1 [cs.CR] 21 Jun 2026

Feras Benchellal, Lotfi Ben Othmane, Yasaswini Konapalli, Cihan Tunc, Bharat Bhargava

Abstract—This paper investigates control-aware attacks against ArduPilot-based Unmanned Aerial Vehicles (UAVs), in which an adversary exploits the sensitivity of flight-controller dynamics to parameter changes to cause loss of control and crashes. It describes six attacks that exploit interactions among multilayer controllers by modifying Proportional-Integral-Derivative (PID) gains, altering Extended Kalman Filter (EKF) estimation configuration, and violating failsafe assumptions, thereby forcing ArduPilot into unsafe operating conditions. We evaluate the attacks in Software-in-the-Loop (SITL) simulation and validate them on a Pixhawk 2.4.8 hardware platform. The results show that short sequences of well-formed MAVLink messages can exploit controller sensitivity to parameter values and updates frequency, affecting controller states and degrading attitude stability, angular-rate behavior, trajectory tracking, and estimator health. We demonstrate that when multiple effects are combined, the vehicle can enter an unsafe state and crashes. These findings show that security gaps in input-parameter handling, command trust, and controller-state validation can be exploited to cause loss of control and crashes in UAVs. Index Terms—UAV security, ArduPilot, MAVLink, controlsystem attacks, extended Kalman filter, cyber-physical systems

I. I NTRODUCTION Unmanned Aerial Vehicles (UAVs), especially quadcopter drones, have been widely adopted for commercial, consumer, and military applications, including agriculture, infrastructure inspection, package delivery, emergency response, surveillance, and reconnaissance. This adoption has contributed to rapid growth in the global drone market, which is projected to increase from USD 83 billion in 2025 to USD 182 billion by 2033 [1]. A key driver of this growth is that drones can operate autonomously or semi-autonomously in shared airspace at relatively low cost and without requiring complex supporting infrastructure. Nevertheless, drone security is a growing concern as physical or cyber attacks against drones can cause operational disruption or failure, financial loss, and even human safety. Research on UAV security mainly focuses on four directions. First, protocol-level studies have shown that injected or replayed MAVLink packets can disrupt missions [2], [3], [4]. Second, physical sensor attacks have demonstrated that acoustic or electromagnetic interference can corrupt Micro-ElectroMechanical Systems (MEMS) gyroscope and accelerometer F. Benchellal, L. Ben Othmane, Y. Konapalli, and C. Tunc are with the University of North Texas, Denton, TX, USA. B. Bhargava is with Purdue University, West Lafayette, IN, USA. Manuscript received [DATE]; revised [DATE].

measurements [5], [6], [7]. Third, Intrusion Detection Systems (IDSs) have been proposed to identify anomalies in communication patterns, software behavior, or flight dynamics [8], [9], [10], [11]. Fourth, cryptographic mechanisms have been proposed to secure the MAVLink channel [12], [13]. These efforts improve UAV security stack, but do not address the controlsystem consequences of accepted, well-formed commands. For the control and management of drones, open-source ArduPilot autopilot software is generally preferred that runs on a flight-controller hardware to provide stabilization, navigation, mission execution, and failsafe management for UAVs [14]. These systems also depend on the Micro Air Vehicle Link (MAVLink) protocol for command-and-control communication because it is lightweight and efficient over low-bandwidth telemetry links [2], [3], [4]. ArduPilot includes several security mechanisms [15] though their deployment could be constraints with overhead [4]. These mechanisms primarily follow a boundary-protection model: the Ground Control Station (GCS) is assumed to be trusted, the communication channel is protected through signing, and the firmware is protected from tampering through signature verification. In many deployments, however, commands may still be transmitted over the network in plaintext, authentication may be disabled or misconfigured, and the Cyclic Redundancy Check (CRC) protects only against accidental transmission errors rather than malicious command injection [2], [3]. ArduPilot uses a cascaded flight-control architecture in which position targets feed velocity controllers, velocity targets feed attitude controllers, attitude targets feed rate controllers, and rate-controller outputs ultimately drive the motors [16], [17]. It also uses Extended Kalman Filter (EKF), which fuses sensor measurements to estimate the vehicle state [18]. Each layer in th control-cascade relies on commands, state estimates, and parameters received from other components. ArduPilot exposes many of these parameters through standard MAVLink messages allowing operators to change them during flight. Thus, if an attacker modifies a Proportional-Integral-Derivative (PID) gain [19] or an EKF parameter through a well-formed PARAM_SET message, ArduPilot may apply the new value at runtime unless parameterlocking protections are enforced. The autopilot does not evaluate whether the resulting closed-loop behavior remains safe under the current flight conditions. Consequently, corrupted control parameters can propagate through the cascade control loops and produce unsafe behavior, especially when updates are issued at carefully chosen times or frequencies.

2

Prior works on IDSs for MAVLink-enabled and ArduPilotbased drones [10], [8], [9], [11] primarily focus on communication-level anomalies, software runtime behavior, or general flight anomalies and do not explicitly reason about command sequences manipulating Ardupilot’s closedloop control system. As a result, an adversary capable of placing well-formed packets on the communication channel, or controlling an authorized endpoint, may be able to issue commands that the autopilot accepts and executes without validating the paramters input. Figure 1 illustrates this scenario: a legitimate GCS and an adversary both send standard MAVLink messages to the UAV over telemetry channels. The parameter change commands sequence from the attacker can destabilize the drone, degrade tracking, bypass failsafe assumptions, or cause loss of control.

Fig. 1: Control-aware manipulation against a UAV. This paper investigates a class of attacks that we call control-aware attacks. In these attacks, an adversary exploits the dynamics of ArduPilot’s control system using legitimate MAVLink commands with maliciously chosen values exploiting the logic and dynamics of the control system. PID controllers and estimation models such as the EKF are inherently sensitive to their configuration parameters; changing these parameters can significantly affect stability, responsiveness, and state-estimation quality. Traditional network-boundary defenses do not address control-aware attacks targeting control loops, including the PID controllers, the EKF state estimator, and the cascaded architecture that translates high-level position commands into motor outputs. By exploiting the implicit trust among these components, we craft command sequences that push ArduPilot into dangerous states, including severe instability, loss of control, and crash. Existing protocoland traffic-centered defenses can identify malformed packets, unauthorized traffic, or suspicious communication patterns; however, they are not well suited to preventing command sequences from inducing undesirable outcomes through malicious manipulation of the behaviors managed by the ArduPilot control system, as shown by this paper. We consider two access models. In the channel-injection model, MAVLink signing is absent or misconfigured, allowing the adversary to inject packets over the telemetry link. In

the authorized-client model, MAVLink authentication may be enabled, but the adversary controls a trusted endpoint, such as a compromised GCS or companion computer. These capabilities could also arise from weak GCS authentication or malware running on an authenticated ground-control system. Our attacks require only the ability to issue standard command and parameter messages. They do not require firmware modification, sensor spoofing, radio jamming, or packet flooding. We define two attack outcomes. Partial success means measurable flight degradation, such as attitude oscillation, tracking error, angular-rate instability, or EKF drift, without a crash.1 Full success means the vehicle reaches an unrecoverable state, triggers crash detection, have the operator lose control, or impacts the ground. We exclude Denial of Service (DoS) attacks that rely on flooding the communication link, as those attacks are already well studied [3]. Instead, we focus on targeted command sequences whose danger comes from control-system effects rather than network-volume effects. This paper makes the following contributions: 1) We design six control-aware attacks against ArduPilot, each targeting a different subsystem or combination of subsystems: oscillation injection against the position controller, PID gain manipulation against the pitch-rate controller, EKF confusion through noise-parameter corruption, failsafe bypass through combined PID corruption and position oscillation, yaw-axis destabilization through yaw-rate controller manipulation, and a combined multilayer attack on the EKF, rate controllers, and attitude controllers. 2) We validate all six attacks in both SITL simulation and physical hardware demonstrations on a Pixhawk 2.4.8 platform. We quantify their effects using DataFlash telemetry logs that capture attitude stability, angularrate variability, EKF health, tracking error, and Global Positioning System (GPS) trajectory deviation. 3) We identify specific security gaps in ArduPilot’s design. In the tested configuration, ArduPilot accepted selected runtime parameter updates without enforcing controlaware safety constraints on their closed-loop effects. These gaps include limited validation of parameter modifications, implicit trust in command sequences regardless of timing or magnitude, and the inability of existing failsafe mechanisms to detect control-aware manipulation. The novelty of this paper is not merely that unsafe parameter values can exist; rather, it lies in systematically mapping ArduPilot’s cascaded control architecture to attack primitives, constructing MAVLink protocol-compliant command sequences that can cause loss of operator control and vehicle crashes, and validating their control effects in both SITL simulation and Pixhawk hardware. The rest of the paper is organized as follows. Section II describes ArduPilot’s cascaded controller architecture and the mathematical models our attacks target. Section III surveys related work. Section III presents the six attacks and their 1 These attacks may be interpreted as analysis of the sensitivity of the individual controllers as they do not cause malicious outcome.

3

Fig. 2: Reverse-engineered ArduCopter Control System [16].

SITL evaluation. Section V reports the hardware validation results on a Pixhawk 2.4.8. Section VII concludes. II. A RDU P ILOT C ONTROL A RCHITECTURE ArduPilot implements a layered control architecture that transforms high-level mission objectives into low-level motor commands through a cascade of nested control loops. This section summarizes the ArduPilot control architecture that we obtained by reverse-engineering the open-source ArduCopter code [14] (ArduCopter is one of the specific firmwares designed for multirotors and helicopters within ArduPilot ecosystem) and reported in [16]. The reverse-engineered ArduCopter flow is demonstrated in Figure 2, which is the foundation of this work, and explained in this section. A. System Overview and Reference Frames ArduCopter, as designed for multirotors (i.e., drones), adopts the North-East-Down (NED) reference frame as its primary coordinate system, where the x-axis points the North, the y-axis points the East, and the z-axis points towards the Earth’s center. This convention is widely adopted in aerospace applications and simplifies certain mathematical operations. All position, velocity, and acceleration vectors are expressed in this frame unless noted otherwise. The vehicle state at time t is characterized by position p(t), velocity v(t), and acceleration a(t), each as three-dimensional vectors as shown in Eq. 1 that flow through the control hierarchy from coarse position targets down to motor actuation commands.   x p(t) = y  (cm), z

  vx v(t) = vy  (cm/s), vz

desired velocity setpoints using a PID controller. This layer executes at 50 Hz. Layer 2: Velocity Control Loop (100 Hz). This layer takes velocity targets from the position controller and generates acceleration commands. It accounts for both tracking error and feed-forward terms. Layer 3: Attitude Control Loop (400 Hz). Acceleration commands are transformed into attitude targets, specifically desired roll (ϕ) and pitch (θ) angles that produce the required thrust vector direction. Layer 4: Rate Control Loop (400 Hz). The innermost feedback loop regulates angular velocities measured by gyroscopes, producing body-frame torque commands τ (t). Layer 5: Motor Mixing & ESC Outputs Loop (400 - 490 Hz). The final stage converts collective thrust and torques into individual motor commands through a mixing matrix. The mixer outputs PWM or Digital Shot (DShot) commands to Electronic Speed Controllers (ESCs). This layered structure allows the modular analysis and decision making for a stable flight for drones. Nevertheless, this structure has a security consequence as the manipulated commands or parameters at any layer propagate through all inner layers below it; i.e., a corrupted velocity target from the position controller cascades into incorrect acceleration, attitude, and motor commands. The ArduPilot software has no mechanism to detect that the cascade has been compromised from the outside. C. Sensor Fusion and State Estimation ArduPilot uses multiple sensors, such as Inertial Measurement Unit (IMU) for acceleration and angular rate, magnetometer for heading, barometer for altitude, and GPS for position and velocity, and employs the Enhanced Kalman Filter Version 3 (EKF3) [18] to fuse their measurements for a stable flight operation. The EKF operates in a twostep prediction-correction cycle. In the prediction step, inertial measurements propagate the state forward, using Eq. 2. xt|t−1 = f (xt−1 , ut−1 , wt−1 ) Pt|t−1 = Ft Pt−1 FtT + Qt

(2)

where x is the state vector (position, velocity, orientation, sensor biases), f (·) is the nonlinear state transition function,   Ft is its Jacobian, P is the state covariance, and Qt is the ax 2 noise covariance. ) a(t) = ay  (cm/sprocess When measurements zt arrive from slower sensors (GPS, az (1) barometer, magnetometer), the correction step adjusts the predicted state using the Eq. 3.

B. Hierarchical Control Structure The control architecture implements a five-layer cascade that progressively transforms waypoints into motor-level Pulse Width Modulation (PWM) signals. Each layer operates at a distinct frequency and produces setpoints for the layer below it, as shown in Figure 2. Layer 1: Position Control Loop (50 Hz). The outermost loop processes position targets received via MAVLink commands. It compares target positions against EKF estimates and computes

Kt = Pt|t−1 HtT (Ht Pt|t−1 HtT + Rt )−1 xt = xt|t−1 + Kt (zt − h(xt|t−1 ))

(3)

where Kt is the Kalman gain, Ht is the measurement model Jacobian, and Rt is the measurement noise covariance. The EKF is especially important in this work because the noise covariance parameters Qt and Rt are configurable through MAVLink. If we increase the process noise, the filter distrusts its own predictions and becomes overly reactive to

4

sensor readings. If we increase measurement noise, it ignores sensor corrections and drifts. Either way, manipulating these parameters can make the filter converge to incorrect states while its internal covariance bounds still look healthy, which means the autopilot can continue to treat an unsafe state estimate as valid.

where pd,xy is the desired position (from MAVLink commands, adjusted for EKF offsets) and pc,xy is the current estimated position. The PID output becomes the velocity target for the inner loop. In ArduPilot, the relevant gains are PSC_POSXY_P, PSC_POSXY_I, and PSC_POSXY_D. The velocity controller then takes this velocity target and produces an acceleration command, as shown in Eq. 7.

D. Mathematical Control Models All controllers in the ArduPilot cascade use variations of the discrete-time PID control law [19]. Understanding the general form, and how it applies to specific subsystems, helps identify which parameters to target and what behavior to expect when those parameters are modified. While ArduPilot uses cascaded PID as the dominant paradigm in open-source autopilots, the broader control literature has developed more sophisticated alternatives. Optimal and adaptive control approaches, including the reinforcement-learning-based optimal control framework developed by Lewis et al. [20], [21], offer principled handling of model uncertainty and disturbances that fixed-gain PID cannot match. The vulnerability class identified in this study (runtime gain corruption via PARAM_SET) would manifest differently in such systems but is not eliminated by them; extending control-aware attack analysis to optimal and adaptive controllers is a natural direction for future work. 1) General PID Control Law: For any controlled variable, error e(t) for time t is defined as the difference between target and measurement (Eq. 4). e(t) = target(t) − measurement(t)

(4)

and, using error information, the controller output is defined as f using the Eq. 5. t X

et − et−1 + kF F · target(t) ∆t i=0 (5) where kP , kI , kD are the proportional, integral, and derivative gains, ∆t is the time step, and kF F is the feed-forward gain. The proportional term responds to current error, the integral term eliminates steady-state offsets by accumulating past error, the derivative term damps oscillations by reacting to error rate of change, and the feed-forward term anticipates required output from the target setpoint directly. Every gain value (kP , kI , kD , kF F ) is a tunable parameter exposed via MAVLink PARAM_SET. This is an intentional decision because operators must tune gains for different vehicle configurations (e.g., quadcopter or hexacopter or even autonomous cars). However, it also means that an attacker with parameter-write access can modify these values at runtime and the autopilot software applies the new values immediately. 2) Position and Velocity Control: Horizontal motion is governed by two nested loops: The outer position loop computes velocity targets from position error, and the inner velocity loop computes acceleration targets from velocity error. Both follow the PID structure in Eq. 5. The position controller computes error using the Eq. 6:

f (t) = kP e(t) + kI

ei ∆t + kD

ep,xy (t) = pd,xy (t) − pc,xy (t)

(6)

ad,xy (t) = kPv ,xy ev,xy (t) + kIv ,xy

t X

ev,xy (i)∆t

(7) ev,xy (t) − ev,xy (t − 1) + kDv ,xy ∆t with gains from PSC_VELXY_P, PSC_VELXY_I, and PSC_VELXY_D. The resulting acceleration is bounded by PSC_ACCZ_MAX to prevent commands that would exceed actuator limits. Setting position gains too high causes rapid velocity commands that saturate the inner loop and induce oscillation. Setting integral gains too high causes windup where accumulated error drives the vehicle past its target and into oscillation around it. These dynamics are the basis for the attacks described in Section III. Altitude control follows the same cascaded structure along the NED z-axis with an additional thrust conversion step. The vertical acceleration command must be converted to a normalized thrust value using Eq. 8. i=0

Tout (t) =

Thover + Tin (t) cos α(t)

(8)

where Thover is the steady-state hover thrust (parameter MOT_THST_HOVER, typically 0.3–0.5), Tin is the PID output, and α(t) is the vehicle tilt angle. The cosine term compensates for the fact that tilting the vehicle reduces the vertical component of thrust. This coupling means aggressive horizontal maneuvers require more thrust to hold altitude, and if motors saturate, the vehicle loses both horizontal and vertical control authority simultaneously. The Thover parameter can be set through PARAM_SET. Setting it too low makes the vehicle think it needs less thrust than it actually does, causing it to descend. Setting it too high makes it climb. In either case, a single parameter change disrupts the relationship between commanded acceleration and actual thrust output. 3) Attitude and Rate Control: The attitude and rate controllers operate at 400 Hz, the fastest loops in the system, due to their importance in a stable flight operation. The attitude controller converts acceleration demands into angular targets, and the rate controller tracks those targets by commanding motor torques. To achieve horizontal accelerations at,x and at,y , the vehicle must tilt its thrust vector. For small angles, the desired roll and pitch are calculated using Eq. 9, ϕ(t) ≈

at,x (t) , g

θ(t) ≈ −

at,y (t) g

(9)

where g ≈ 980 cm/s2 . ArduPilot uses full quaternion math for arbitrary attitudes, but this approximation shows the core relationship: The horizontal acceleration scales directly with tilt angle. ArduPilot represents orientation using quaternions

5

q = [qw , qx , qy , qz ] to avoid gimbal lock. The attitude error between target qt and current qb is calculated using Eq. 10. eang (t) = axisangle(qt (t) ⊗ qb−1 (t))

(10)

A proportional controller maps this error to target angular rates using Eq. 11. ω t (t) = kP,ang ⊙ eang (t)

(11)

where kP,ang comes from parameters of ATC_ANG_RLL_P, ATC_ANG_PIT_P, and ATC_ANG_YAW_P. The rate controller is the innermost feedback loop and produces the actual torque commands sent to motors (using Eq. 12).

τ (t) = kP,ω eω (t) + kI,ω

t X

eω (i)∆t

(12) eω (t) − eω (t − 1) + kF F,ω ω t (t) + kD,ω ∆t where eω (t) = ω t (t) − ω c (t) is the rate error. The gains come from ATC_RAT_RLL_P/I/D/FF, ATC_RAT_PIT_P/I/D/FF, ATC_RAT_YAW_P/I/D/FF. These rate controller gains are among the most sensitive parameters in the entire system. Even small perturbations to well-tuned gains can move the system toward its stability boundary. Too little kP,ω causes vehicle to responds sluggishly and cannot reject disturbances. Too much kP,ω causes oscillation violently as the controller tries to balance sensor noise and structural vibrations. Our PID gain manipulation attacks directly exploit this sensitivity. Yaw control adds slew rate limiting to prevent abrupt heading changes with Eq. 13. i=0

ψ̇t (t) = clip(ψ̇cmd (t), −ψ̇max , ψ̇max )

(13)

where ψ̇max is set by RATE_Y_MAX. This filtering creates an interesting dynamic for our oscillation attacks: Rapidly alternating yaw commands get smoothed by the slew limiter, but the vehicle still accumulates heading drift over time because the filtering is not symmetric in both directions. 4) Motor Mixing: The mixing stage converts thrust Tout and torques τ into individual motor commands. For a quadcopter in X-configuration, Eq. 14 demonstrates the normalized motor thrusts, as follows.   1 1  um (t) =   T (t) + M τ (t) (14) 1 out 1 where um = [u1 , u2 , u3 , u4 ] are normalized motor thrusts in [0, 1] and M is the geometry-dependent mixing matrix. If any motor command exceeds [0, 1] bounds, ArduPilot applies proportional desaturation; i.e., it scales all commands values down while preserving their relative differences. This keeps the vehicle controllable at the cost of reduced total thrust. Motor saturation is where many of our attacks ultimately manifest their effects. When corrupted parameters cause controllers to demand more torque or thrust than the motors can

deliver, the mixer saturates. Sustained saturation means the vehicle cannot track its targets, errors accumulate through the cascade, integral terms wind up, and the error compounds until a failsafe triggers or the vehicle enters an unrecoverable state. E. Control Loop Dynamics 1) Multi-Rate Cascade and Timing: The cascade operates across four time scales, as mentioned previously: position control at 50 Hz, velocity at 100 Hz, attitude and rate at 400 Hz, and motor output at 400 - 490 Hz. Inner loops run faster than outer loops by factors of 2 - 10× to maintain time-scale separation, which is standard practice in control theory. Each fast inner loop appears quasi-steady to the slower outer loop above it. This separation has a security implication: A manipulated parameter in a fast inner loop can destabilize that loop without the slower outer loops noticing immediately. The outer loops keep commanding setpoints that the inner loop can no longer track. The result is a delayed instability that shows up as unexplained drift or oscillation at the position level while the actual root cause is in the attitude or rate dynamics. By the time the outer loops react, the situation may already be unrecoverable. A position command takes roughly 20 - 30 ms to propagate through the entire cascade to the motors, purely from computational sequencing. This latency is important for our attacks because rapidly oscillating commands must be timed relative to this propagation delay to achieve maximum destabilizing effect. 2) Inter-Loop Coupling and Saturation: Although the cascade appears hierarchical, significant coupling exists between axes. Three mechanisms are directly relevant to our attacks: Thrust-Attitude Coupling. Eq. 8 shows that thrust must increase as tilt angle grows to maintain the vertical component. During aggressive horizontal commands, thrust can exceed motor capacity. When this happens the vehicle loses both altitude hold and position tracking simultaneously, which is the tumbling behavior we observe in several of our attacks. Yaw-Roll Coupling. Yaw control relies on differential motor speeds between clockwise and counter-clockwise rotors. During combined roll and yaw commands, the mixer cannot satisfy both torque demands if motors saturate. ArduPilot prioritizes roll/pitch over yaw, meaning our yaw oscillation attacks cause heading drift while roll/pitch stability is preserved, at least until the situation gets bad enough to overwhelm everything. Integral Windup Cascade. Each PID controller accumulates integral error. If an inner loop saturates, error persists in the outer loop, of which integral keeps growing. When saturation eventually releases, the wound-up integral drives a large overshoot. In a three-layer cascade, windup can compound across all layers simultaneously. ArduPilot has anti-windup logic, but our parameter manipulation attacks are able to overwhelm these protections. F. Failsafe and Safety Mechanisms ArduPilot has extensive failsafe mechanisms for GPS loss, Remote Control (RC) loss, low battery, excessive EKF variance, and crash detection with configurable thresholds and

6

response actions (continue, Return to Launch (RTL), land, disarm), all adjustable through PARAM_SET. However, such a configurability introduces security weaknesses. For example, raising thresholds can prevent fault detection, letting the vehicle fly with degraded state estimation. Lowering thresholds causes false triggers from normal transients and noise. Changing the response action itself turns a safety mechanism into an attack vector, for example, setting the GPS failsafe action to “Land” causes the vehicle to descend immediately whenever it loses GPS lock, even briefly. Crash detection is particularly an interest of this study. ArduPilot declares a crash when several conditions occur simultaneously for more than 2 seconds: lean angle exceeding 15◦ , acceleration below 3 m/s2 , thrust error above 30◦ , and horizontal velocity below 10 m/s. Our combined attacks that push the vehicle into sustained high lean angles can trigger this logic, causing ArduPilot to disarm the motors mid-flight. The EKF has its own internal health checks based on innovation variance (the difference between predicted and actual measurements). The parameter FS_EKF_THRESH sets the threshold for declaring the EKF unhealthy. Our EKF confusion attacks manipulate noise parameters to push innovation variance close to this threshold, creating a situation where the state estimates are degraded but the failsafe has not triggered yet, a dangerous gray zone where ArduPilot is flying on bad information but does not know it. G. MAVLink Commands Used Our attacks rely on a specific subset of MAVLink messages. These are standard messages any ground control station uses during normal operations. The most important is PARAM_SET, which writes a new value to any autopilot parameter. We use it to modify PID gains, EKF noise thresholds, failsafe limits, and other configuration values at runtime. SET_POSITION_TARGET_LOCAL_NED and SET_POSITION_TARGET_GLOBAL_INT send position and velocity targets. SET_ATTITUDE_TARGET directly specifies desired attitude. COMMAND_LONG handles arming, takeoff, and mode changes. HEARTBEAT keeps the GCS connection alive. In the tested configuration, ArduPilot accepts these messages without control-aware contextual validation; that behavior is the property our attacks exploit. III. R ELATED W ORK MAVLink Protocol Vulnerabilities. The MAVLink protocol has been a primary entry point for UAV security research. Marty [2] was among the first to assess MAVLink vulnerabilities, demonstrating on the ArduPilot Mega 2.5 that unencrypted, unauthenticated messages allow injection, hijacking, and denial-of-service against operational UAVs. Kwon et al. [3] confirmed empirically that a remote adversary can disable missions or force UAVs to hover, requiring only basic knowledge of the MAVLink message format. Hamza et al. [4] surveyed the protocol’s evolution and current countermeasures, noting that MAVLink 2.0’s optional signature field is still rarely deployed because key distribution is operationally inconvenient.

Cryptographic Solutions. Khan et al. [12] proposed a packetlevel encryption scheme combining a Caesar cipher with custom character mapping and a synchronized key list. Tufekci et al. [13] proposed authenticated encryption with associated data (AEAD) schemes, including ChaCha20-Poly1305, AES-GCM-SIV, AES-OCB3, and AES-CCM, that encrypt the payload while authenticating the header and provide replay protection through sequence-number authentication. These approaches strengthen channel security but do not address the class of attacks studied here, where commands are well-formed and authorized. Physical Sensor Attacks. Beyond protocol vulnerabilities, researchers have shown that even cryptographically secure command channels do not protect against attacks on the physical sensors themselves. Son et al. [5] demonstrated that MEMS gyroscopes in commercial drones are vulnerable to acoustic resonance attacks, causing rotor commands to saturate and rendering the drone uncontrollable. Tu et al. [6] extended this to fine-grained adversarial control over inertial sensor outputs. Trippel et al. [7] achieved similar control over MEMS accelerometers via signal-conditioning vulnerabilities. Sensor Fusion Vulnerabilities. Shen et al. [22] performed the first security analysis of multi-sensor fusion-based localization in autonomous driving, exploiting transient periods of elevated state uncertainty in a Kalman-filter implementation. Tu et al. [23] addressed the related challenge of recovering flight when redundant IMUs are simultaneously compromised by acoustic resonance. Sensor Deprivation and Reconfiguration Attacks. Erba et al. [24] introduced sensor deprivation attacks, which manipulate drone behavior by reconfiguring onboard sensors via unauthenticated Inter-Integrated Circuit (I2C)/Serial Peripheral Interface (SPI) Application Programming Interfaces (APIs) rather than continuously injecting false data. A single malicious reconfiguration message persistently alters sensor behavior even after the attacker leaves range. This work is conceptually closest to ours: both exploit reconfiguration rather than continuous spoofing. Our attacks operate one abstraction layer higher, on the autopilot’s parameter store, which is reachable from any authenticated MAVLink client. Intrusion Detection. Jeong et al. [8] proposed MAVLinkbased UAV Intrusion Detection System (MUVIDS), a network-level IDS for MAVLink-enabled vehicles that detects flooding and false-injection patterns. Tufekci [9] presented Distributed UAV Delay-based Intrusion Detection System (DUDE-IDS), a multi-layered IDS combining flow-based supervised learning at the network layer with LSTM-based sequence learning at the control layer. These systems detect protocol anomalies and unusual message sequences, but they may miss attacks that use properly formatted commands at normal rates. In such cases, malicious behavior arises from the timing, magnitude, and combination of values rather than from a protocol violation. Software Reliability of Open-Source Autopilots. The ArduPilot project was subjected to monthly Coverity scans for several years, identifying hundreds of defects, mostly memoryrelated [25]. Wang et al. [26] conducted a large-scale empirical study of UAV autopilot bugs from PX4 and ArduPilot,

7

identifying eight UAV-specific root-cause categories and five challenges in detection and reproduction tied to the cyberphysical nature of these systems. Position of This Work. MAVLink protocol research focuses on malformed packets and unauthorized injection. Cryptographic solutions assume that authentication resolves security concerns, but authenticated commands can still exploit control system dynamics. Physical sensor research bypasses software but requires specialized equipment and proximity. IDS detect protocol anomalies but may not catch attacks where there is no pattern of commands or malformed commands. Our hypothesis is that a properly authenticated command can still be malicious if the values it carries push the control system beyond stability boundaries and cause unintended behavior. This paper investigates this class of attacks. Compared to Marty [2] and Kwon et al. [3], our attacks use only well-formed, protocol-compliant commands. Compared to Son et al. [5] and Trippel et al. [7], our attacks need no physical proximity. Compared to Shen et al. [22], who exploit Kalman-filter uncertainty windows through GPS spoofing, we show that a single PARAM_SET message inflating EKF noise covariances produces the same kind of filter divergence on a UAV without external signal injection. Compared to Erba et al. [24], our attacks target the autopilot parameter store rather than sensor configuration registers, and the parameter store is reachable from any authenticated MAVLink client. TABLE I: Summary of evaluated control-aware attacks along with the target controller and outcomes. #

Attack

Target layer

Outcome

1 2 3 4

Oscillation Injection PID Gain Manipulation EKF Confusion Bypassing Failsafe Constraints Yaw Axis Destabilization Combined Multi-Layer

Position controller Pitch rate controller State estimation Rate controller + position Yaw rate controller EKF + rate + attitude

Partial Partial Partial Dangerous Partial Crash

5 6

IV. ATTACK D ESIGN AND S IMULATION This section presents our six control-aware attacks against ArduPilot. Each attack targets a different subsystem or combination of subsystems in the control hierarchy described in Section II. All attacks, listed in Table I, use only legitimate MAVLink commands. ArduPilot accepts them because they are well formed and use the protocol as designed; their malicious effects arise from the selected values and from the timing and frequency with which the commands are sent. A. Simulation Setup We developed and evaluated the attacks using ArduPilot’s Software-in-the-Loop (SITL) simulator. SITL compiles the actual ArduPilot firmware as an executable and replaces physical sensors and actuators with a flight-dynamics model. For each attack, we armed the vehicle, had it take off to a stable hover, and then ran the attack script while logging telemetry. The scripts connect to ArduPilot via pymavlink [28] on tcp:127.0.0.1:5763 and use the MAVLink messages

described in Section II. Table II describes the parameters modified by the attacks. All degradation percentages reported in this section were computed offline from the ArduPilot’s DataFlash log for each flight. For each attack, we first recorded a baseline log of the mission, from the starting position through return-to-home, with no attack script running. We then recorded a log of the same mission with the attack script activated. A script parsed both logs, extracted the same telemetry metrics, and reported the relative difference between the attack run and the baseline scenario over the attack window. We report one representative experiment for each case; repeated exploratory trials showed similar behavior, but we did not collect enough repetitions to report means and standard deviations. All scripts and logs are available on our GitHub page [29]. B. Attack 1: Oscillation Injection This attack induces oscillatory behavior by alternating position setpoints sent through the MAVLink command SET_POSITION_TARGET_LOCAL_NED when the drone is in Guided mode. We command the vehicle to move approximately 20 m north and south at 10 Hz for 30 seconds. The position controller computes a velocity target proportional to the position error at the default frequency of 50 Hz. When we flip the target to the opposite side, the error sign reverses and the controller commands velocity in the new direction, but the vehicle still has inertia toward the old target. This creates a large velocity error. The attack tests whether the ArduPilot can reject a sequence of well-formed but adversarially timed targets; i.e., this attack does not modify any controller parameters. In the tested configuration, we observe that ArduPilot did not perform this type of validation. Results. We observed that the pitch-rate variability rose by 133%, with peak rates of 40.3◦ /s, and the roll-rate variability rose by 186%. The attitude oscillations stayed below the 15◦ failsafe threshold, so no failsafe was triggered – See Section II-F for details about the implemented fail-safe mechanisms. However, the altitude tracking degraded, the position trajectory deviated by tens of meters from the commanded path, and the GPS ground track showed clear oscillation. During this attack, the vehicle remained airborne but exhibited visibly degraded flight. C. Attack 2: PID Gain Manipulation The pitch-rate controller is the innermost feedback loop for the pitch axis. It runs at 400 Hz with default gains ATC_RAT_PIT_P ≈ 0.135, ATC_RAT_PIT_I ≈ 0.135, ATC_RAT_PIT_D ≈ 0.0036, and ATC_RAT_PIT_IMAX ≈ 0.5; see Table II for descriptions of these parameters. We modify these parameters via the MAVLink command PARAM_SET to ATC_RAT_PIT_I = 0.500 (a 3.7× increase, causing integral windup), ATC_RAT_PIT_D = 0.0001 (a 36× decrease, causing near-zero damping), and ATC_RAT_PIT_IMAX = 1.0 (doubled). We leave the roll and yaw axes at their default values.

8

TABLE II: Parameters modified by the control-aware attacks in this work. Source: ArduPilot Copter parameter documentation [17] and EKF3 source code [27]. Parameter

Subsystem

Description

Rate controller parameters ATC_RAT_PIT_P ATC_RAT_PIT_I ATC_RAT_PIT_D ATC_RAT_PIT_IMAX ATC_RAT_RLL_I ATC_RAT_RLL_D ATC_RAT_RLL_IMAX ATC_RAT_YAW_P ATC_RAT_YAW_I ATC_RAT_YAW_D ATC_RAT_YAW_IMAX

Pitch rate PID Pitch rate PID Pitch rate PID Pitch rate PID Roll rate PID Roll rate PID Roll rate PID Yaw rate PID Yaw rate PID Yaw rate PID Yaw rate PID

Proportional gain Integral gain Derivative gain (damping) Maximum integral accumulation Integral gain Derivative gain (damping) Maximum integral accumulation Proportional gain Integral gain Derivative gain (damping) Maximum integral accumulation

Attitude controller parameters ATC_ANG_PIT_P ATC_ANG_RLL_P ATC_ANG_YAW_P ATC_SLEW_YAW

Pitch attitude Roll attitude Yaw attitude Yaw controller

Proportional gain for pitch angle correction Proportional gain for roll angle correction Proportional gain for yaw angle correction Maximum yaw target slew rate (cdeg/s)

EKF3 process, bias, and measurement-noise parameters EK3_ACC_P_NSE EK3_GYRO_P_NSE EK3_ABIAS_P_NSE EK3_GBIAS_P_NSE EK3_POSNE_M_NSE EK3_ALT_M_NSE EK3_VELD_M_NSE

Process noise Process noise Bias estimate Bias estimate Meas. noise Meas. noise Meas. noise

Accelerometer noise (m/s3 ); higher = less trust in IMU prediction Gyroscope noise (rad/s); higher = less trust in angular-rate prediction Accelerometer bias drift rate; higher = faster bias wander Gyroscope bias drift rate; higher = faster bias wander Horizontal position noise (m); higher = weaker GPS correction Altitude measurement noise; higher = weaker barometer correction Vertical velocity noise; higher = weaker vertical correction

EKF3 gates, safety checks, and source configuration EK3_POS_I_GATE EK3_HGT_I_GATE EK3_GPS_CHECK EK3_GLITCH_RAD EK3_SRC1_POSXY EK3_SRC1_VELXY EK3_SRC1_POSZ

Innovation gate Innovation gate EKF safety EKF safety Source config Source config Source config

Position outlier rejection threshold; higher = accepts worse measurements Height outlier rejection threshold; higher = accepts worse measurements Bitmask for GPS health checks; 0 = all checks disabled GPS glitch detection radius (m); 0 = disabled Horizontal position source; 0 = none Horizontal velocity source; 0 = none Vertical position source; 0 = none

EKF failsafe

Variance threshold that triggers EKF failsafe

Failsafe parameters FS_EKF_THRESH

Results. Pitch-rate variability rose by 3%, and the attitude trace showed minor irregularities. However, the vehicle continued to fly normally, and no failsafe was triggered. The asymmetric corruption, which targeted pitch only, was not enough on its own to push the controller across the stability boundary. The important finding is not the limited visible effect, but that ArduPilot accepts and applies these gain values in real time without control-aware checking, operator confirmation, or rate limiting. This weakness is exploited in Attacks 4 and 6. D. Attack 3: Extended Kalman Filter (EKF) Confusion Attack 3 targets the state estimator rather than the attitude loops directly. Under normal operation, EKF3 balances shortterm IMU prediction against GPS, barometer, and magnetometer corrections. The default parameter values used in our experiments are EK3_ACC_P_NSE≈ 0.35, EK3_GYRO_P_NSE≈ 0.015, EK3_POSNE_M_NSE≈ 0.5, EK3_POS_I_GATE≈ 5, and EK3_GPS_CHECK= 31; see Table II for descriptions of these parameters. These parameters control the estimator’s

trust model: process noise affects prediction covariance, measurement noise affects correction strength, and gates/checks reject implausible sensor updates. The attack corrupts nine EKF parameters in three phases. First, process noise is inflated so the filter distrusts its own inertial prediction. This is achieved by setting EK3_ACC_P_NSE= 5.0, EK3_GYRO_P_NSE= 3.0, EK3_ABIAS_P_NSE= 1.0, and EK3_GBIAS_P_NSE= 0.5. Second, measurement noise is inflated so GPS, barometer, and vertical-velocity corrections carry less weight. This is achieved by setting EK3_POSNE_M_NSE= 10.0, EK3_ALT_M_NSE= 5.0, and EK3_VELD_M_NSE= 5.0. Third, the safety envelope is widened by setting EK3_POS_I_GATE= 1000 and EK3_GPS_CHECK= 0. Each value is sent through MAVLink command as PARAM_SET and is applied immediately. In the EKF prediction step, inflated process noise increases– see Equation 2. In the update step, shown in Equation 3, inflated measurement noise increases the denominator of the Kalman gain, causing sensor corrections to be underweighted. The bias-noise parameters let accelerometer and gyro bias estimates wander, and the disabled GPS checks remove the

9

protection that would normally reject implausible updates. Downstream controllers then operate on corrupted state estimates without knowing that the estimator has been manipulated. Why this works against the EKF. The attack exploits the structural trust the filter places in its own configuration. ArduPilot’s EKF3 has no notion of a “reasonable” noise value: the parameters Qt (process noise) and Rt (measurement noise) are treated as ground truth. By inflating Qt , the attacker tells the filter that its inertial prediction is unreliable, so it leans harder on sensor corrections. By simultaneously inflating Rt , the attacker tells the filter that the sensors are also unreliable, so the Kalman gain Kt shrinks toward zero and corrections are effectively ignored. With both inflated, the filter trusts nothing: it neither predicts well nor corrects well, and the state estimate drifts along the accumulated bias. Crucially, the filter’s own covariance bound Pt|t−1 stays within the range Ardupilot considers healthy because the inflated noise values make the larger covariance look expected rather than anomalous. This is why FS_EKF_THRESH does not trigger the fail-safe mechanisms, which compare the innovation variance against the threshold. Simulation Results. Figure 3 shows the error traces during the attack simulation. This attack damages the state estimator where the EKF roll/pitch innovation magnitude errRP rises from a baseline mean of 0.007 to a mean of 0.100, with a peak of 0.170. This corresponds to an increase of roughly 1,376% relative to baseline. The ramp begins near t = 60 s, which is when the inflated measurement noise has reduced the Kalman gain enough that the filter stops correcting accumulated prediction error.

Fig. 3: Attack 3 - The EKF roll/pitch error errRP. Note that the error is almost 0 in the baseline scenario and ramps to 0.170 while the vehicle remains airborne in the attack scenario. An operator watching the attitude and rate panels from the authorized GCS would not see the effect of this attack. The external flight behavior remained almost unchanged – roll, pitch, and yaw variability changed by less than 1%, and angular rates shifted by less than 0.3%. Even though the attack does not crash the drone or activate the failsafe mechanism, instead it establishes internal damage in the controllers via a corrupted but failsafe-silent state estimate. In Attack 6,

we exploit this weakness by combining it with rate-loop corruption so that the silently incorrect estimate is fed into deliberately destabilized controllers. Thus, monitoring attitude and rate alone is insufficient to detect this attack. Independent monitoring of EKF innovation health is required to mitigate this attack. E. Attack 4: Bypassing Failsafe Constraints The attacker corrupts both the pitch and roll rate loops by issuing commands that set ATC_RAT_PIT_I to 0.5 and ATC_RAT_RLL_I to 0.8, set ATC_RAT_PIT_D=ATC_RAT_RLL_D to 0.0, and raise both IMAX values to 1.5–affecting the altitude and the rate controller of Eq. 12. The attacker then injects circular position oscillations that repeatedly excite the weakened inner loops. The script sends a three-dimensional oscillating position target in which latitude and longitude trace a circular pattern while altitude oscillates independently. The corrupted integral terms accumulate error quickly while zero derivative damping removes the term that normally suppresses oscillation. The rotating position target prevents the outer loop from converging: Every time the cascade begins correcting toward one target, the target moves and because both roll and pitch are corrupted, the vehicle loses stable lateral axis. The altitude oscillation stresses thrust compensation, i.e., when the vehicle leans, the vertical thrust component decreases, and the altitude controller demands more thrust and pushes the motors closer to saturation. Results. Attack 4 severely degraded ArduPilot control by increasing the roll-rate variability by 3,155%, with peaks near 320◦ /s in SITL. The SITL’s DataFlash analysis also shows sustained ±100–125◦ /s oscillation after the attack onset. Pitchrate variability increased by 2,533%, tracking errors increased by 437% in roll and 573% in pitch, and errRP jumped to approximately 0.15. The vehicle drifted southward and remained airborne in a severely degraded state rather than failing cleanly. Figure 4 shows the angular-rate response on the roll and yaw axes. We observe that, while the yaw rate changes instantly, the roll rate oscillates between extreme values for about 3 minutes. Figure 5 shows the ArduPilot deviations in terms of ground track and barometric-altitude deviation. Figure 5a shows minor deviations in latitude and longitude, while Figure 5b shows a delayed landing. Together, these show how the destabilized inner loops degrade the altitude and trajectory tracking simultaneously while the vehicle remains airborne. F. Attack 5: Yaw Axis Destabilization The yaw controller maintains heading orientation. It is normally limited by ATC_SLEW_YAW (∼6,000 cdeg/s) and RATE_Y_MAX. We modify six yaw-related parameters: ATC_RAT_YAW_P = 1.5 (8×), ATC_RAT_YAW_I = 0.5 (28×), and ATC_RAT_YAW_D = 0.0–see Eq. 12. We widen the slew rate to 36,000 cdeg/s (6×, removing slew protection) and weaken ATC_ANG_YAW_P = 0.5–see Eq. 14. We

10

(a) Roll rate. (a) GPS ground track.

(b) Yaw rate.

Fig. 4: Attack 4 angular-rate response. (a) Roll rate enters sustained high-amplitude oscillation between roughly ±100◦ /s once the PID corruption and setpoint excitation interact. (b) Yaw rate stays close to baseline most of the time but shows large transient spikes near the setpoint-flip events, exposing the cross-axis coupling.

then send CONDITION_YAW commands at ±720◦ /s, with CW/CCW reversals every 0.5 seconds. Results. The attack forced the yaw rate to peak above ±200◦ /s and caused cross-axis roll/pitch variability to rise visibly because the differential thrust required for yaw saturated the mixer, which prioritizes roll/pitch over yaw. The attack did not affect the copter’s altitude. However, it exposes a design tradeoff in the mixer: heading accuracy is sacrificed to maintain roll/pitch stability under saturation. Attack 6 exploits this design trade-off.

G. Attack 6: Multi-Layer Combined Attack Attack 6 combines EKF corruption from Attack 3, rateloop destabilization from Attacks 2 and 4, and altitude-loop weakening. The attack creates a destructive feedback loop in which corrupted state estimates and overtuned controllers reinforce one another even after the attacker stops transmitting.

(b) Barometric altitude.

Fig. 5: Attack 4 trajectory response. The ground track deviates significantly from baseline, and barometric altitude drifts as the destabilized inner loops corrupt thrust compensation.

The attack sends approximately 30 PARAM_SET commands, organized into three groups, in under five seconds. Figure 6 shows the sequence of messages sent by the attacker and their impacts. The attack has three phases. In phase 1, we corrupt the EKF noise, gates, checks, and source selection by assigning extreme values to EK3_ACC_P_NSE, EK3_GYRO_P_NSE, EK3_ABIAS_P_NSE, EK3_GBIAS_P_NSE, EK3_POSNE_M_NSE, EK3_ALT_M_NSE, EK3_VELD_M_NSE, EK3_POS_I_GATE, EK3_HGT_I_GATE, EK3_GPS_CHECK, and EK3_GLITCH_RAD. It also removes EKF position and velocity sources using EK3_SRC1_POSXY=0, EK3_SRC1_VELXY=0, and EK3_SRC1_POSZ=0. In phase 2, we corrupt the pitch, roll, and yaw rate controllers. For the pitch and roll controllers, the atatck script sets ATC_RAT_PIT_P and ATC_RAT_RLL_P

11

Attacker

ArduPilot

Phase 0: connection & takeoff COMMAND_LONG (ARM + TAKEOFF) COMMAND_ACK Stable hover Attack 3

Phase 1: EKF parameter corruption (11 params) PARAM_SET (EK3_ACC_P_NSE=10.0) PARAM_SET (EK3_GYRO_P_NSE=5.0) PARAM_SET (EK3_SRC1_POSXY=0)

EKF trusts sensors less; no absolute reference

. . . (8 more EKF PARAM_SETs)

(a) EKF roll/pitch error errRP. Attack 2

Phase 2: Rate controller corruption (9 params) PARAM_SET (ATC_RAT_PIT/RLL_P=5.0) PARAM_SET (ATC_RAT_PIT/RLL_I=3.0) PARAM_SET (D=0.0, IMAX=3.0)

All rate loops: 37x gain, zero damping

Attack 5

Phase 3: Altitude controller weakening PARAM_SET (ATC_ANG_PIT/RLL/YAW_P=0.5)

Attitude correction 9x slower

Attacks 2+3

Response: Destructive feedback loop

IMU vibrations feed back Wrong torque commands

ATTITUDE (roll=155◦ )

(b) Velocity east (VE).

Fig. 7: Attack 6 estimator response. errRP peaks at 0.524 before the EKF failsafe triggers and the north/east velocity estimates show the filter losing coherent state long before the failsafe activates.

SYS_STATUS (errRP=0.524)

Outcome: EKF Failsafe / Crash EKF failsafe triggered Vehicle crash (t ≈ 153 s)

Fig. 6: UML Sequence Diagram for Attack 6

to 5.0, ATC_RAT_PIT_I and ATC_RAT_RLL_I to 3.0, ATC_RAT_PIT_D and ATC_RAT_RLL_D to 0, ATC_RAT_PIT_IMAX and ATC_RAT_RLL_IMAX to 3.0. For the yaw, the script sets parameter ATC_RAT_YAW_P to 1.5, ATC_RAT_YAW_I to 0.5, and ATC_RAT_YAW_IMAX to 2.0. Phase 3 weakens the outer attitude controllers by setting ATC_ANG_PIT_P, ATC_ANG_RLL_P, and ATC_ANG_YAW_P to 0.5. The script then stops issuing attack commands and monitors telemetry and attack impact. We emphasize that the values for PARAM_SET messages were chosen empirically through trial and errors. In this paper,

we report a successful attack scenario. Future work will derive analytical bounds on the parameters needed to guarantee the desired impact. ArduPilot response to the attack commands. Attack 6 requires no attacker input after the initial parameter burst. The attack corrupts three input and command processing layers impacting the controller’s feedback loop. The overtuned controllers, with controller gain constants P and I, are raised by roughly 37× and derivative damping set to zero, oscillate at high frequency, and that oscillation shakes the airframe. The IMU registers the vibration as a genuine motion. Normally, the EKF would reject this using GPS, barometer, and velocity corrections. However, Phase 1 has set EK3_SRC1_POSXY, EK3_SRC1_VELXY, and EK3_SRC1_POSZ to zero and widened every gate, so the filter has no independent reference to contradict the vibration-corrupted inertial data. Therefore, the resulting incorrect state estimate is passed to the weakened attitude controllers, whose constant P gains are reduced to roughly 1/9 of their default values and are therefore too slow to correct the growing error. Their late and incorrect

12

(a) Roll angle.

Fig. 9: Quadcopter testbed with a Pixhawk 2.4.8 flight controller used for hardware validation of the six attacks.

degradation through different mechanisms: Command timing alone in Attack 1, single-axis gain corruption in Attack 2, state-estimator corruption invisible to attitude monitoring in Attack 3, and yaw destabilization with cross-axis coupling in Attack 5. Attack 4 produces a dangerous but non-crashing outcome, and Attack 6 produces complete loss of control by combining mechanisms across multiple control layers. Across all six attacks, the tested configuration applies parameter changes and command sequences without controlaware validation of whether the resulting behavior remains safe, reasonable, or consistent with stable flight. (b) Yaw angle.

Fig. 8: Attack 6 attitude response. Roll diverges to approximately 155◦ (near inversion) and yaw drifts uncontrollably as the corrupted controllers and corrupted estimator drive each other. torque commands drive the rate loops harder, which increases vibration and further corrupts the estimation where with each iteration of the loop, errors are amplified. Therefore, the attacker does not need to continue transmitting after about five seconds as the vehicle still proceeds to failure on its own. Results. Attack 6 forced Ardupilot for complete loss of control. Figure 7 shows the roll/pitch error while Figure 7a shows errRP reaching 0.524 and causing the east velocity of Figure 7b to become unstable. Figure 8 shows the attitude deviation in response to the combined attack. We observe that the roll (Figure 8a) reaches approximately 155◦ , indicating near inversion and the yaw fluctuates without control (Figure 8b). These deviations saturate the throttle; see Eq. 14. Hence, the EKF failsafe triggers at approximately t = 153 s, right after the roughly five-second parameter-corruption burst has ended, confirming that the loop is self-sustaining rather than driven by continued attacker input. H. Summary of Simulation Results The six attacks span a spectrum from partial degradation to complete loss of control. Attacks 1, 2, 3, and 5 produce partial

V. P ROOF - OF - CONCEPT VALIDATION U SING A P IXHAWK 2.4.8 F LIGHT C ONTROLLER A. Hardware Setup To evaluate whether the SITL findings, we replicated the operations and attacks using real-world flight environment with a physical quadcopter (i.e., drone) under wind, motor noise, physical sensor behavior, and aerodynamic effects because although SITL runs the ArduCopter firmware, it does not fully capture these physical factors. The hardware experiments provide transfer evidence rather than exhaustive statistical validation. In the following, we first describe the hardware setup, then present and analyze the experimental results. The physical testbed, shown in Figure 9, consisted of a Pixhawk 2.4.8 flight controller running ArduPilot Copter firmware, mounted on a quadcopter airframe with onboard GPS, a telemetry radio, a battery, and electronic speed controllers. The Ground Control Station (GCS) laptop ran Mission Planner [30] and the Python attack scripts [29]. The attack scripts connect to the quadcopter over a 915 MHz SiK telemetry radio at 57,600 baud through a MAVProxy TCP splitter, which allows Mission Planner and the attack scripts to share the telemetry link. The scripts use pymavlink package to communicate with the quadcopter. All flight experiments complied with U.S. Federal Aviation Administration regulations. The drone is registered under 14 CFR Part 48, registration number FA3TC7HCTX. Flights

13

TABLE III: Hardware validation results. Attack

Hardware behavior

1: Oscillation Injection

Visible attitude oscillation at 2 Hz; increased pitch-rate peaks; yaw drift; altitude unaffected; no failsafe. Minimal observable flight impact; corrupted gains confirmed via parameter read-back; no failsafe. This confirms that the tested configuration accepts unsafe PID values without control-aware validation. Externally normal flight; errRP climbed steadily; no failsafe. This was the stealthiest attack: attitude monitoring alone could not detect EKF parameter corruption. Sustained ±100◦ /s roll and pitch oscillation; visible southward drift; severely degraded but airborne flight. Effects were more pronounced than in SITL due to real vibrations. Yaw rate exceeded ±200◦ /s; cross-axis roll/pitch variability increased; the mixer prioritized roll/pitch as expected; altitude was unaffected. Roll reached 155◦ , nearly inverted; roll rate exceeded −512◦ /s; errRP peaked at 0.524; the drone crashed at t ≈ 153 s when the EKF failsafe triggered.

2: PID Gain Manipulation 3: EKF Confusion 4: Bypassing Failsafe Constraints 5: Yaw Axis Destabilization 6: Combined Multi-Layer

were conducted under the recreational operations exception, 49 U.S.C. §44809 [31]. B. Experimental Results Each attack was executed at least once in flight, and ArduPilot’s DataFlash logs were collected for post-flight analysis. Table III summarizes the observed behavior for each attack. Overall, the Pixhawk 2.4.8 hardware reproduced the same attack mechanisms observed in SITL: ArduPilot accepted and read back the tested PARAM_SET commands without control-aware validation, and the drone exhibited the same categories of the degraded behavior documented in Section III, including sustained attitude oscillation, EKF state drift, and controller instability. For Attack 6, the corruption window again lasted under five seconds, after which the drone entered a self-sustaining destructive feedback loop and crashed. In several cases, the hardware effects were more pronounced than in SITL because real airframe vibration and sensor noise provided additional excitation for the destabilized controllers to amplify. ArduPilot’s response to Attack 6 is of particular interest because it produced the most severe outcome. The corruption window of the attack lasted under five seconds. After the last PARAM_SET command, no further attacker input was needed. The drone entered a self-sustaining destructive feedback loop. The 37× overtuned rate controllers oscillated at high frequency, producing airframe vibrations that the IMU registered as real motion. With EK3_SRC1_POSXY, EK3_SRC1_VELXY, and EK3_SRC1_POSZ all set to zero, the EKF could not distinguish these controller-induced vibrations from legitimate sensor data. The weakened attitude controllers, with gains reduced to roughly one-ninth of their default values, could not correct the growing attitude errors. The DataFlash logs confirm roll angles approaching 155◦ , roll rates exceeding −512◦ /s, and an errRP peak of 0.524. The drone crashed approximately 153 seconds into the flight becuase the errRP exceeded the threshold FS_EKF_THRESH. These results show that ArduPilot’s layered control architecture, although designed for modularity, can become a safety liability when an attacker corrupts multiple layers at once. Several observations from the hardware experiments are worth noting. First, Ardupilot applies malicious parameters

values without validation, including values that no legitimate tuning workflow would normally use, such as gyroscope process noise inflated by a factor of 200 and attitude proportional gain reduced ninefold. Second, the combined attack’s selfsustaining property matters from a defensive perspective: The operator has roughly five seconds of anomalous parameter activity to detect and interrupt before the destructive loop closes. An operator monitoring Mission Planner’s standard attitude and rate panels may not see malicious behavior while the navigation state silently degrades. Third, Attack 3 (i.e., the EKF Confusion) is the most concerning attack from an intrusion detection standpoint because it can remain externally quiet while preparing the estimator state that, when combined with controller corruption as in Attack 6, can contribute to a crash. VI. D ISCUSSION Summary. Figure 10 summarizes the six control-aware attacks against ArduPilot presented in this paper, in which an attacker uses only legitimate, well-formed MAVLink commands to drive the autopilot’s control system into degraded or unsafe states. The attacks were evaluated in SITL simulation and demonstrated on a Pixhawk 2.4.8 flight platform. The attacks span a spectrum from partial flight degradation (Attacks 1, 2, 3, and 5), through severely degraded flight (Attack 4), to complete loss of control (Attack 6). They exploit four distinct primitives that ArduPilot exposes to any authenticated MAVLink client: (1) command-timing manipulation, (2) runtime PID-gain modification, (3) EKF noise-covariance manipulation, and (4) cascade-control parameter corruption. A consistent finding across all six attacks is that the tested configuration applies parameter changes and command sequences without control-aware validation of whether the resulting values are safe, reasonable, or consistent with stable flight. The autopilot’s trust model assumes a benign operator, and that assumption creates exploitable gaps at every level of the cascaded control hierarchy. Implications. Securing the MAVLink communication channel is not enough. An attacker who compromises a legitimate GCS, gains access through social engineering, or controls a malicious companion computer could damage the drone by manipulating the control system as presented in this paper.

14

ATTACKER CAPABILITIES

EFFECTS ON VEHICLE MAVLink (legitimate commands)

Motors & Actuators

• Access to MAVLink channel (e.g., radio link) • Send legitimate, well-formed MAVLink commands • Cannot modify firmware or inject malformed packets

• Attitude instability (oscillation, divergence) • Angular rate excursions • EKF degradation / loss of state estimate • Trajectory tracking error / deviation • Failsafe bypass or unsafe states (e.g., flyaway, crash)

SIX CONTROL-AWARE ATTACKS 1. POSITION OSCILLATION ATTACK

Target L1: Position Controller Layer

2. PID GAIN MANIPULATION (PITCH RATE)

3. EKF CONFUSION ATTACK

L4: Pitch Rate Controller (ATC_RAT_PIT_*)

EKF (State Estimator)

Multiple: PID (Roll/Pitch) + L1 Position

MAV_CMD_DO_REPOSITION (or SET_POSITION_TARGET_ Method GLOBAL_INT) with high-frequency oscillatory waypoints

PARAM_SET to modify PID gains (e.g., increase P/D, reduce I)

PARAM_SET to corrupt EKF noise parameters (e.g., EKF_GYRO_NOISE, EKF_ACC_NOISE, EKF_MAG_NOISE, etc.)

Effect

• Overshoot and sustained oscillations • Increased angular rate variability • Reduced attitude stability and control authority

• Increased state uncertainty • Position/velocity estimate error • Degraded control performance and tracking accuracy

• Induces sustained position/velocity oscillations • Large tracking error and energy drain

4. FAILSAFE BYPASS ATTACK

5. YAW AXIS DESTABILIZATION ATTACK

6. MULTI-LAYER COMBINED ATTACK

L4: Yaw Rate Controller (ATC_RAT_YAW_*)

EKF + L4 Rate Controllers + L3 Attitude

1) Corrupt PID gains (PARAM_SET) 2) Inject position oscillations (repeated REPOSITION)

PARAM_SET to modify yaw rate PID gains (e.g., excessive P/D, reduced I)

Simultaneous PARAM_SET to multiple subsystems (EKF noise, rate PID, attitude PID/limits, etc.)

• Degrades control while keeping vehicle within normal bounds • Prevents triggers of standard failsafes • Enables unsafe states without arming failsafe

• Yaw oscillations and heading instability • Poor trajectory tracking and pointing error • Can propagate to lateral path deviation

• Strongly degraded state estimation • High-frequency oscillations • Large tracking error; possible loss of control and unsafe outcomes

Fig. 10: Summary of the control-aware attacks, their methods, and their effects. TABLE IV: Mitigation impact across the six attacks. Mitigation

A1

A2

A3

A4

A5

A6

Limitations

MAVLink signing

Partial

Partial

Partial

Partial

Partial

Partial

Parameter range checks Parameter rate limiting Control-aware monitoring

No No Yes

Yes Partial Yes

Yes Partial Yes

Yes Partial Yes

Yes Partial Yes

Yes Yes Yes

Does not stop a compromised Ground Control Station (GCS). Requires safe parameter ranges. Slows attacks but does not fully prevent them. Requires model-specific thresholds.

The commands resemble normal operations because they use standard interfaces, but they carry maliciously selected values and timing. Protocol-level Intrusion Detection System (IDS) [10], [32], [33], [34] that focus on message format or rate patterns would also miss these attacks because the messages are well formed, use standard types, and arrive at expected rates. Effective detection would require an IDS to understand the control-theoretic implications of command sequences and parameter values, which is more difficult than packet-pattern matching. Mitigations and Future Work. Table IV summarizes mitigation techniques that address the proposed attacks. Several directions follow naturally. Parameter validation through range checking on PARAM_SET could reject values exceeding a configurable multiple of the factory defaults. Rate limiting on parameter changes would prevent the rapid multi-parameter corruption that enables Attack 6. Limiting modifications to one or two per second would extend the attack window from five seconds to minutes, giving operators time to notice the anomaly and giving control monitors time to respond. Cross-layer consistency monitoring could flag the simulta-

neous modification of EKF, rate, and attitude parameters within a short window, since legitimate tuning workflows do not modify these layers together. EKF health monitoring should be included in any IDS, since attitude-only monitoring cannot detect Attack 3. Finally, extending control-aware attack analysis to autopilots that use optimal or adaptive control approaches [20], [21], as well as to PX4, is a natural direction for future work. VII. C ONCLUSION This paper presented six control-aware attacks against ArduPilot that use legitimate, well-formed MAVLink commands to manipulate the internal dynamics of the autopilot. The attacks target different layers of ArduPilot’s cascaded control architecture, including position guidance, PID rate loops, EKF state estimation, failsafe assumptions, yaw control, and combined multi-layer interactions. Evaluation in SITL and validation on a physical Pixhawk 2.4.8-based drone, as a subset of UAVs, show that short sequences of accepted MAVLink commands can produce measurable degradation in attitude stability, angular-rate behavior, trajectory tracking, and EKF health. When multiple weaknesses are combined, the

15

drone can enter a self-sustaining unstable state that persists after the attacker stops transmitting and can lead to loss of control or crash. The findings highlight a gap in current UAV defenses: Protocol-level protection alone is insufficient when trusted runtime interfaces can be used to issue unsafe control actions. Future defenses should therefore combine communication security with control-aware safeguards, including parameter range checks, limits on rapid parameter changes, EKF health monitoring, and detection logic that reasons about the physical and control-theoretic effects of command sequences. More broadly, this work shows the need to treat autopilot parameters and guidance commands as safety-critical inputs, not merely configuration data, and motivates extending control-aware attack analysis to other autopilots, drone types, and control architectures. Disclaimer: Ardupilot was informed about this paper. ArduPilot includes now a parameters lockdown mechanism, which when activated, mitigates the attacks described in the paper. R EFERENCES [1] “Drone Market (2026 - 2033),” https://www.grandviewresearch.com/ industry-analysis/drone-market-report, [Accessed 21-05-2026]. [2] J. A. Marty, “Vulnerability analysis of the MAVLink protocol for command and control of unmanned aircraft,” Master’s thesis, Air Force Institute of Technology, Wright-Patterson AFB, Ohio, 2014. [3] Y.-M. Kwon, J. Yu, B.-M. Cho, Y. Eun, and K.-J. Park, “Empirical analysis of MAVLink protocol vulnerability for attacking unmanned aerial vehicles,” IEEE Access, vol. 6, pp. 43 203–43 212, 2018. [4] M. A. Hamza, M. Mohsin, M. Khalil, and S. M. K. A. Kazmi, “MAVLink protocol: A survey of security threats and countermeasures,” in Proceedings of the 4th International Conference on Digital Futures and Transformative Technologies (ICoDT2), 2024, pp. 1–8. [5] Y. Son, H. Shin, D. Kim, Y. Park, J. Noh, K. Choi, J. Choi, and Y. Kim, “Rocking drones with intentional sound noise on gyroscopic sensors,” in 24th USENIX Security Symposium (USENIX Security 15). Washington, D.C.: USENIX Association, 2015, pp. 881–896. [6] Y. Tu, Z. Lin, I. Lee, and X. Hei, “Injected and delivered: Fabricating implicit control over actuation systems by spoofing inertial sensors,” in 27th USENIX Security Symposium (USENIX Security 18). Baltimore, MD: USENIX Association, 2018, pp. 1545–1562. [7] T. Trippel, O. Weisse, W. Xu, P. Honeyman, and K. Fu, “WALNUT: Waging doubt on the integrity of MEMS accelerometers with acoustic injection attacks,” in 2017 IEEE European Symposium on Security and Privacy (EuroS&P). IEEE, 2017, pp. 3–18. [8] S. Jeong, E. Park, K. U. Seo, J. D. Yoo, and H. K. Kim, “MUVIDS: False MAVLink injection attack detection in communication for unmanned vehicles,” in Workshop on Automotive and Autonomous Vehicle Security (AutoSec), 2021. [9] B. Tufekci, “Intrusion detection system for drones,” Ph.D. dissertation, University of North Texas, Denton, Texas, 2024. [10] F. J. Alruwaili and C. Tunc, “A lightweight and efficient intrusion detection system for drone networks,” in 2025 5th Intelligent Cybersecurity Conference (ICSC), 2025, pp. 219–226. [11] I. Tan, W. Minn, C. M. Poskitt, L. K. Shar, and L. Jiang, “Runtime anomaly detection for drones: An integrated rule-mining and unsupervised-learning approach,” 2025. [12] N. A. Khan, N. Z. Jhanjhi, S. N. Brohi, and A. A. Almazroi, “A secure communication protocol for unmanned aerial vehicles,” Computers, Materials & Continua, vol. 70, no. 1, pp. 601–618, 2022. [13] B. Tufekci, A. Arslan, C. Tunc, and K. Morozov, “Enhancing the security of the MAVLink with symmetric authenticated encryption for drones,” in Proceedings of the 11th International Conference on Internet of Things: Systems, Management and Security (IOTSMS), 2024, pp. 58–65. [14] “Ardupilot,” https://ardupilot.org/, accessed in Oct. 2025. [15] A. D. Team, https://ardupilot.org/dev/docs/security-landing-page.html, 2026.

[16] Y. Konapalli, L. B. Othmane, C. Tunc, F. Benchellal, and L. Mudagere, “Reverse engineering and control-aware security analysis of the ardupilot uav framework,” in 8th International Workshop on Software Engineering Research and Practices for the IoT, Rio De Janeiro, April 2026. [17] ArduPilot Development Team, “Complete parameter list — Copter documentation,” https://ardupilot.org/copter/docs/parameters.html, 2025, accessed: 2026-03-30. [18] R. E. Kalman, “A new approach to linear filtering and prediction problems,” Journal of Basic Engineering, vol. 82, no. 1, pp. 35–45, 03 1960. [19] N. Minorsky, “Directional stability of automatically steered bodies,” Journal of the American Society for Naval Engineers, vol. 34, no. 2, pp. 280–309, 1922. [20] F. L. Lewis, D. Vrabie, and V. L. Syrmos, Optimal Control, 3rd ed. Hoboken, NJ: Wiley, 2012. [21] F. L. Lewis and D. Vrabie, “Reinforcement learning and adaptive dynamic programming for feedback control,” IEEE Circuits and Systems Magazine, vol. 9, no. 3, pp. 32–50, 2009. [22] J. Shen, J. Y. Won, Z. Chen, and Q. A. Chen, “Drift with devil: Security of multi-sensor fusion based localization in high-level autonomous driving under GPS spoofing,” in 29th USENIX Security Symposium, 2020, pp. 931–948. [23] Z. Tu, F. Fei, M. Eagon, D. Xu, and X. Deng, “Flight recovery of mavs with compromised imu,” in 2019 IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS). Macau, China: IEEE, November 2019, pp. 3638–3644. [24] A. Erba, N. O. Tippenhauer, and D. Balzarotti, “Sensor deprivation attacks for stealthy UAV manipulation,” in Proceedings of the 33rd USENIX Security Symposium, 2024, pp. 1–18. [25] ArduPilot Development Team, “ArduPilot coverity scan results,” https: //scan.coverity.com/projects/ardupilot-ardupilot, 2019, accessed: 2024. [26] D. Wang, S. Li, G. Xiao, Y. Liu, and Y. Sui, “An exploratory study of autopilot software bugs in unmanned aerial vehicles,” in Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE), 2021, pp. 20–31. [27] ArduPilot Development Team, “AP_NavEKF3.cpp — ArduPilot source code,” https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_ NavEKF3/AP_NavEKF3.cpp, 2025, accessed: 2026-03-30. [28] “Mavlink developer guide,” https://mavlink.io/en/, accessed in oct. 2025. [29] Feras Benchellal, “Control-aware attacks against ArduPilot drone systems,” https://github.com/CopterRecon/CopterManipulation, 2026, accessed: 2026. [30] Michael Oborne, “Mission planner home,” https://ardupilot.org/planner/ #mission-planner-home, 2026, accessed: 2026. [31] D. o. T. D. Federal Aviation Administration (FAA), “Exception for limited recreational operations of unmanned aircraft,” https://www.federalregister.gov/documents/2019/05/17/2019-10169/ exception-for-limited-recreational-operatio\ns-of-unmanned-aircraft# h-7, 2019. [32] B. Tufekci, V. Quach, C. Tunc, and R. Dantu, “DUDE-IDS: A framework for efficiently detecting network-related drone cyberattacks,” in Proceedings of the 2024 11th International Conference on Internet of Things: Systems, Management and Security (IOTSMS). IEEE, 2024, pp. 240–247. [33] Y. Wu, L. Yang, L. Zhang, L. Nie, and L. Zheng, “Intrusion detection for unmanned aerial vehicles security: A tiny machine learning model,” IEEE Internet of Things Journal, vol. 11, no. 12, pp. 20 970–20 982, Jun. 2024. [34] V. U. Ihekoronye, S. O. Ajakwe, J. M. Lee, and D.-S. Kim, “DroneGuard: An explainable and efficient machine learning framework for intrusion detection in drone networks,” IEEE Internet of Things Journal, pp. 1–1, 2024.