Account Takeover Stole the Servers, Not GPS Spoofing

Trailers of AI server hardware have been vanishing off American highways, and the line every outlet repeated is that the thieves faked the GPS. That is the least load-bearing part of the story. The FBI's own public advisory on this exact crime wave does not mention GPS once. In the Bureau's model the cargo is stolen in a login screen and a federal database, days before a truck moves. The spoofed tracker, if it happened at all, was the retreat.

This matters to you even if you have never booked a freight load. The hole those thieves walked through is a hole almost every product ships with.

What this costs you

Take the trucks out and the shape is this: an account can edit a field, and something downstream reads that field as proof of who the account holder is. The attacker takes the account, edits the field, and then passes the check, because the check is reading what they just wrote.

Go looking in your own product and the candidates come up fast:

• the bank details on a payout profile, read back by finance before a transfer
• the notification address a password-reset code is sent to
• the webhook or callback URL your signed events are delivered to
• the support contact a rep reads aloud to "confirm we're speaking to the right person"
• the email on a teammate invite, which decides who ends up with admin

Every one of those is either profile data or authorization, and the two are stored in the same table. The cost of the confusion is specific: one redirected payment, one account you cannot recover because the recovery channel now belongs to someone else, one invoice settled into a stranger's bank. The decision in front of you is which of those fields are authorization, which of them need step-up re-verification on write plus an out-of-band confirmation on read, and whether you would rather build that now or after the first incident.

It is a procurement question too. "We verify counterparties against the official registry" sits unchallenged in vendor security questionnaires, and it is a control that fails in exactly the case it was written for. A good share of our work at SV Dev is finding controls like that in software which performs perfectly until someone has a motive.

What is confirmed, and what is one investigator's word

This week's coverage blends two very different grades of claim, so here is the split before anything rests on either.

Confirmed in primary sources. FBI IC3 advisory I-043026-PSA, published 30 April 2026, which lays out a seven-step chain ending in a rewritten federal record. FMCSA's own fraud-prevention page, which tells brokers to call the phone number published in SAFER and carries the line "Last updated: Monday, April 7, 2025". The SAFER company snapshot, which does publish that phone field. And NBC News's investigation of 26 October 2026, which started this week's coverage.

Self-reported or unverified. The "more than $100 million stolen since June" total is NBC's own aggregate, assembled from the accounts of trucking, supply-chain and cargo-security veterans, which is to say interested parties describing their own market rather than an official dataset. The GPS spoofing is hedged in the reporting itself: coordinates on one California-to-Texas load were "apparently" spoofed, according to an investigator, with no forensic artifact published. The FBI's $725 million in 2025 losses, the 60% year-over-year rise and the $273,990 average per theft are industry estimates the advisory cites, not numbers the Bureau collected. Claims that the hardware reaches countries under US AI export controls are law-enforcement suspicion, and the reporting says so.

Nothing in the argument below depends on those estimates.

What the FBI actually describes

FBI advisory I-043026-PSA, 30 April 2026. The full chain the Bureau documents runs from a compromised broker load-board account to cargo resold by complicit drivers. No tracker appears in it.

The chain reads: phish a broker into installing remote-management software, take over their load-board account, post fake loads to harvest carrier credentials, then bid on real loads using a compromised carrier's identity. An unwitting driver collects the freight. It is cross-docked to a complicit one. There is no tracker in the diagram, no interception, no truck chase. By the time a location could be falsified, the load had already been handed to the wrong party by a system that believed it was talking to the right one.

Spoofing a tracker explains how a theft goes unnoticed for a few hours. Account takeover explains how it happens at scale.

The record the thieves rewrite

"Bids on Real Loads": the attacker edits the federal registration record, not the truck.

Here is the step the coverage skipped. In the advisory's "Bids on Real Loads" phase, the attackers "change the legitimate carrier's contact information with the Federal Motor Carrier Safety Administration and update insurance information to permit loads the legitimate carrier previously did not accept."

Read that as a product engineer. They are not hiding the truck; they are becoming the carrier in the system of record, and raising their own limits while they are in there. The advisory adds that the real carrier "may not realize they are compromised until brokers contact them about missing loads booked under their authority." The owner of the identity is the last to know, because nothing in the flow ever asks them.

The verification step that reads what the attacker wrote

FMCSA's prevention advice, unchanged since April 2025: confirm the counterparty by calling the number posted in SAFER, the field the FBI says the thieves rewrite.

Now put FMCSA's own prevention advice beside that. It tells brokers to confirm phone numbers using SAFER, and: "If the number you were given by the carrier/broker does not match the number posted, call the number posted in SAFER for the company to discuss the load."

The number posted in SAFER is the registration contact, the field the FBI says the attacker changes. Federal anti-fraud guidance instructs you to establish identity by reading the precise record the attack mutates, and it has not been revised since 7 April 2025, roughly a year before the advisory describing that attack. Two live federal documents, pointing opposite ways.

A check that reads attacker-writable state is not verification. It is a confirmation oracle: it answers fastest to the person who prepared the answer. The honest participant gets a mismatch and has to make a call; the attacker gets a clean match, because both ends of the comparison are theirs.

The audit to run this week

1. Inventory the writes. Every field an account can change without talking to you: profile, billing, integrations, team.
2. Mark the ones read as truth. If anything downstream treats that value as evidence of identity, entitlement or destination, it is authorization, not profile data.
3. Protect the write. Re-authentication, out-of-band confirmation to the old value, and a hold window on anything that moves money or receives secrets.
4. Fix the read. Resolve identity through a channel the account cannot edit: a signed agreement, a contact verified earlier, the counterparty's own authenticated session. Not the field they just saved.
5. Rewrite the questionnaire answer. If your security page promises registry verification, say which channel it actually uses.

Steps 3 and 4 are a sprint for most teams. The incident they prevent is not. We made a related argument about credentials trusted by default in AI agents and exposed credentials, and about single points of trust in the one-zone outage that took down banks.

Key takeaways

• The FBI's advisory on the data-center cargo thefts never mentions GPS. It describes account takeover and a rewritten federal registration record.
• FMCSA tells brokers to verify a counterparty by calling the number published in SAFER, the same field the FBI says attackers change. That page has been unchanged since April 2025.
• Any verification that reads a value the attacker can write is a confirmation oracle, not a control.
• The fix generalizes: separate profile data from authorization data, gate the writes to the second kind, and resolve reads through a channel the account does not own.
• The dollar totals in this story are industry estimates and one reporter's aggregate, not audited figures. The mechanism does not depend on them.