Loading story…
Researchers from the University of California San Diego and Oberlin College disclosed a coin-sized hardware implant that can be attached to an accessible Boeing 737 avionics service port to spoof commands sent between the Flight Management Computer and the cockpit display interface. In Boeing test-lab demonstrations using a custom 737 avionics test bed known as Triton, the team showed the device could remain concealed under a dust cap, intercept avionics traffic, and alter data such as outside air temperature, aircraft weight, and flight-plan information, creating the potential for incorrect takeoff calculations or route deviations.
The researchers said they first shared the findings with Boeing more than six years ago and warned that aircraft redesign cycles could slow remediation if technical changes are required. Boeing said it reviewed component designs, installations, and interfaces and maintains that existing aircraft design and operational safeguards significantly limit real-world feasibility and risk, while the researchers recommended mitigations including blocking access to the service port, improving electrical isolation, and adding cryptographic protections to prevent spoofed avionics messages; the device was also reported to support remote access through in-flight Wi‑Fi.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
4 events from the most recent confirmed update back to the earliest known activity.
After spending years acquiring secondhand Boeing 737 computer components, the research team had assembled a wired-together avionics test bed called Triton. The platform enabled their later experiments on Boeing 737 systems.
In response to the researchers' findings, Boeing conducted its own review of component designs, installations, and interfaces. Boeing said existing design and operational protections significantly limit the feasibility and risk of real-world attacks.
The team demonstrated its attack in a Boeing facility test lab, showing interception, alteration, and spoofing of communications between the Flight Management Computer and the Multipurpose Control Display Unit. The attack used a coin-sized hardware implant attached to an avionics service port.
The researchers shared their physical-access Boeing 737 hacking findings with Boeing more than six years before the 2026 reporting. Their work showed that commands could be spoofed to aircraft computers through an undisclosed or service port.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
2 references tracked. Mallory keeps watching after this page renders.
tomshardware.com
Open sourcewired.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers disclosed **CVE-2026-32193**, a Microsoft Copilot hijack that abused an undocumented URL parameter, `?autorun=1`, to bypass the normal user-approval step and automatically run attacker-supplied prompts. By pairing that parameter with crafted input in the `q` field, an attacker could make Copilot operate within a victim’s authenticated session, search connected enterprise data including inbox contents, and send sensitive results to an attacker-controlled server. The attack could be delivered through phishing links, chat messages, webpages, or QR codes, and researchers reported it could continue even if the victim closed the Copilot tab immediately after opening it. Separate reporting tied the issue to a broader attack chain described as moving from an **AKS node root vulnerability** to a Copilot compromise, underscoring how cloud and AI weaknesses can be chained together. Researchers also described a second prompt-injection method that poisoned Copilot’s persistent memory using hidden webpage metadata, allowing later manipulation of Copilot responses and actions. The disclosures highlight risks from undocumented AI features, prompt injection, and trusted-session abuse in enterprise copilots connected to corporate data.
Aug 20, 2026
Independent researchers published detailed reverse-engineering of SpaceX Starlink user terminals, showing that the devices’ firmware, boot chain, and runtime services can be closely inspected through hardware teardown, eMMC extraction, and emulation. Analyses of v2, v3, and Standard Actuated Rev3/GenV2 terminals found large portions of firmware left unencrypted, documented custom integrity controls including ECC and `sxverity`, and mapped a Linux-based architecture in which user-space C++ networking components handle much of the terminal logic. Researchers also identified an `STSAFE-A110` security chip used for device identity and key operations, observed telemetry-related Ethernet recording components, and reported that one terminal initialized 41 SSH public keys while leaving port `22` open on the local network. Separate work demonstrated that Starlink secure boot could be bypassed in a lab by voltage fault injection against the `BL1` stage on the custom ARM SoC, yielding root-level access despite secure-boot protections. Researchers built QEMU-based environments to debug services such as `httpd`, WebSocket, and gRPC, examined the internal `user_terminal_frontend` interface, and found an unauthenticated `SoftwareUpdateRequest` on the internal network that could start the update flow, although fuzzing did not uncover a practical remote exploit path. Black-box testing also triggered out-of-memory crashes in the Go-based frontend through malformed localhost-bound IPC traffic, while SpaceX reportedly reproduced the fault-injection proof of concept and mitigated part of it by disabling UART output via eFuse.
Aug 3, 2026
CISA warned that **PX4 Autopilot** contains a critical vulnerability, `CVE-2026-1579`, that can let an unauthenticated attacker execute arbitrary shell commands through the **MAVLink** interface. The flaw affects `PX4 Autopilot v1.16.0_SITL_latest_stable` and stems from MAVLink not requiring cryptographic authentication by default, allowing attackers with interface access to send `SERIAL_CONTROL` messages that could alter flight paths, crash drones, intercept data, or lock out legitimate operators. CISA rated the issue **CVSS 9.8** and mapped it to **CWE-306: Missing Authentication for Critical Function**. The advisory said PX4 supports **MAVLink 2.0 message signing** as its authentication mechanism, and unsigned messages are rejected when signing is enabled. The vulnerability was reported by **Dolev Aviv of Cyviation**, and CISA said it had no evidence of public exploitation at publication. Because PX4 is used in drones and autonomous vehicles deployed worldwide, the agency said the exposure could affect **Transportation Systems, Emergency Services, and the Defense Industrial Base**, and urged organizations to reduce network exposure, isolate control systems behind firewalls, use secure remote access such as updated VPNs, assess operational risk before changes, train personnel against phishing, and apply vendor fixes when available.
Jun 29, 2026