How a False Observation Enters the Shared Map

The specific problem posed by the WILD Attack is not that an attacker can invent a Wi-Fi packet. It is that a genuine device can carry a misleading observation into the same crowd-sourced path used to build a provider's location records. Following that path makes the attack's requirements and limits clear: the attacker does not need to compromise a victim device or provider, but does need to influence how a provider interprets an identifier observed away from its legitimate surroundings.

A genuine report can carry a false observation

There are two very different meanings of “injecting data” into a service. In the first, an attacker sends a crafted request directly to an internal reporting interface, attempting to imitate the provider's own collection client. In the second, the attacker causes an ordinary client to produce a report that looks normal at the request boundary. The WILD study focuses on the second route. It reports that certificate pinning and stricter source verification make direct injection impractical for modern providers, while a forged observation can travel through the device-side behavior that providers already expect.

The distinction is important because the client and the observation are separate sources of trust. A phone may be a real phone, running an unmodified location-dependent application, and sending a request in the expected format. That establishes something about the transport and the device. It does not establish that every Wi-Fi identifier in the request was physically present at the coordinates associated with the report. The device can faithfully report what it was made to observe, while the observation itself has been engineered to describe the wrong environment.

In the study's controlled setup, the researchers used test BSSIDs that had not previously appeared in the providers' LLTs. They caused devices at a selected reporting location to observe those identifiers and submit them, together with the location of that reporting site, through the provider-appropriate collection behavior. Some providers collect such data passively while a location-dependent service is used; WiGLE supports an active submission path. The researchers did not need the provider to accept a special attack message. They measured whether the ordinary path eventually created a record for each test identifier.

The result was consistent across the four investigated providers: falsified reports were accepted well enough to create LLT records. In the tested conditions, Google WPS took roughly 10 to 14 days, Apple WPS and A-Map about seven days, and WiGLE less than 30 minutes after processing the reports. These numbers are not interchangeable service-level promises. They show that the same general weakness can have very different time scales, and that a provider's update cadence affects how long an attacker must sustain influence before the false state becomes visible to later lookups.

The researchers also compared falsified reports with legitimate reports generated through the same general procedures and with similar volumes. The time required to record the test access points was nearly the same in the two conditions. That observation does not prove that production providers lack every anti-abuse mechanism. It does show that, in the experiment, the ingestion path did not reliably distinguish a report about a real nearby access point from a report about an identifier that had been made to appear nearby.

A useful way to describe the weakness is as a missing semantic assertion. The provider can check whether a BSSID has the right shape, whether the request is sent by an expected client, and whether the signal measurements are usable. It can still lack a strong answer to the question, “Was this particular BSSID physically present at this reported location?” The WILD Attack lives in that gap between the validity of a report and the truth of the fact it reports.

This is also why the attack is not equivalent to simply fabricating latitude and longitude in an API call. The provider's normal collection system is part of the evidence it receives. A report arrives from a real device, through a familiar application path, with a set of wireless observations that are technically plausible. The falsification is in the relationship among the identifier, the radio environment, and the reported coordinates. If the provider accepts that relationship without sufficient corroboration, the LLT can store the wrong association even though no request field looks obviously malformed.

There are several layers of validity in that report. The identifier can be syntactically valid. The radio frame carrying it can be a properly formed 802.11 beacon. The device can genuinely detect the frame, and the application can genuinely send the device's current coordinates. All of those statements can be true while the combined claim—“this BSSID is a stationary access point at these coordinates”—is false. The provider's challenge is not just to reject malformed data. It is to test a relationship that spans an identifier, a physical environment, time, and geography.

That relationship is difficult to verify using one observation. A provider may reasonably expect a phone to report the wireless signals it sees while using a location-dependent service. It may not be able to ask the access-point owner to confirm every sighting, especially when the system is intended to work at global scale. The practical design question becomes how much confidence a report earns from its source, how many independent observations are needed, and how geographically distant reports should be reconciled. The WILD study does not assume that these questions have one obvious answer; it shows that the observed answers have security consequences.

The collection path matters here because it changes what the provider can see. Some studied providers collect observations passively as location-dependent services run, while another supports an active user submission path. In either case, the provider receives data through a workflow built for usefulness rather than for a forensic investigation of every radio claim. A passive report may look like a routine background contribution. An active report may be intentional, but intentional submission is not the same as proof that the submitted BSSID was physically present at the stated place. The trust problem survives the difference between the two modes.

The researchers' comparison with legitimate reporting is therefore more informative than a demonstration that a test record can be created at all. If falsified data needed a special request shape or an unusual client, the provider could focus on that boundary. If falsified and legitimate observations reach the LLT through comparable device behavior and similar volumes, the relevant defense must examine the content and relationships of the observations themselves. In the tested setup, the time needed to create records was nearly the same under the two conditions. That supports the conclusion that the observed ingestion path did not reliably identify the semantic mismatch, while leaving open the possibility of additional production defenses outside the experiment.

This does not mean that every device near a reporting site will contribute, or that an attacker can dictate a provider's update schedule. The study used controlled identifiers and devices, and its timing results varied sharply by provider. Real environments introduce changing application states, signal coverage, reporting limits, and unrelated observations. The finding is narrower: the normal path is capable of carrying a false association into provider state under the conditions the researchers tested. That capability is enough to make provenance and conflict resolution central security properties.

The study's attacker is deliberately modest in another sense. They are not assumed to have privileged access to a provider, the victim's phone, or the owners of the legitimate access points. The victim location is assumed to contain working access points whose identifiers are already represented in the LLT. Those access points continue to generate legitimate reports from their true surroundings. The challenge is therefore not to make the victim environment disappear. It is to make the provider treat a second, contradictory stream as meaningful enough to change the state that represents the first.

That condition separates the attack's prerequisites from its consequences. Before any provider-side conflict can occur, the attacker needs to know which identifiers are worth targeting; the study treats that discovery problem separately. During the reporting phase, the attacker needs a way for devices at another location to submit observations containing those identifiers. After the provider changes its records, the attacker may no longer need to remain near the victim or even continue transmitting. The attack moves effort from the moment of the victim's lookup to the earlier moment when shared state is formed.

One identifier, two places

Imagine the same BSSID represented in two geographic streams. At the access point's real location, nearby devices continue to observe it and contribute legitimate reports. At a separate reporting location, devices are induced to observe the same identifier and contribute coordinates for that second place. The provider now has a conflict that is not visible in the later victim's scan. The victim's device sees the local beacon; the provider sees a history in which the identifier has been associated with more than one place.

flowchart LR LT["Victim site: legitimate APs"] --> LR["Legitimate reports"] LS["Separate reporting site"] --> FR["Falsified observations from normal devices"] LR --> C["Competing reports for target BSSIDs"] FR --> C C --> P["Provider conflict handling"] P --> L["Shared LLT state"] L --> Q["Later lookup at victim site"] Q --> O["False location or no result"]

The two streams do not have equal meaning simply because they use the same identifier. One describes the access point's continuing physical operation at the victim location. The other describes a report produced at the attacker's chosen location. The provider must decide whether the difference is a sign of mobility, measurement error, a portable hotspot, a temporary anomaly, or malicious manipulation. The WILD study's central finding is that the providers do make such decisions, but their observed rules differ and can be exploited in different ways.

The LLT is the mediator. It turns a conflict that exists in the reporting history into one current record—or into no record. Once the provider has chosen what to store, a later querying device usually does not receive both sides of the dispute. It asks for a location from the identifiers it sees and receives the provider's current interpretation. The device therefore need not be fooled at the radio layer. It can perform a correct local scan and still obtain a wrong answer because the interpretation layer has been changed upstream.

This is the point at which “remote” becomes precise. The attacker is remote from the victim at the time the victim uses WPS, not necessarily absent from every physical location involved in the earlier reporting process. The false observations are created somewhere the attacker can influence, and the altered record is later consumed somewhere else. The distance between those places is not itself the security boundary; the provider's willingness to merge or arbitrate the reports is.

It also explains why the attack can be persistent. A conventional rogue-access-point attack has to keep supplying the misleading signal whenever the victim needs a location. A provider-side change can remain in the LLT after the false reporting stops. The later query has no direct way to know that the record was established during an anomalous period. Persistence is not guaranteed for every provider or record, and its duration is a separate empirical question, but the architecture makes persistence possible: the read path can continue to consume state after the write-side influence has ended.

The same causal chain can produce either a false result or an absent result. If the provider overwrites a record with the reporting location, a later device may receive coordinates that look precise because the surrounding BSSIDs agree on the poisoned map. If the provider treats the conflict as a reason to remove the record, the later device may lose its Wi-Fi-based estimate and fall back to another source. The attacker has influenced the same shared state, but the user-visible harm depends on the provider's conflict policy.

The experiment therefore establishes a narrower and more useful conclusion than “Wi-Fi location is insecure.” It shows that, under the tested conditions, falsified observations can enter the accepted crowd-sourcing pipeline, compete with legitimate observations, and become provider state without any rogue transmitter appearing beside the later victim. It does not show that every report is accepted, that every location can be altered on demand, or that all production safeguards are absent. Those questions depend on provider-specific rules, report volume, spatial conditions, target coverage, and the downstream application's source-selection behavior.

There is a further reason not to describe the problem as a single exploit. A provider can harden its request interface and still leave the observation-to-record relationship under-verified. It can improve signal-quality filters and still mistake repeated correlated reports for independent agreement. It can detect a conflict but choose to preserve a false record, delete a correct one, or wait for more evidence. The WILD Attack exposes the design space created by those choices; the next question is how the four studied providers resolve the conflict once it is present.

References