NearScrub

2026-10-01

Polarsteps’ open API exposed 1 billion GPS points and tracked soldiers to military bases — only one of its two location sources was a photo’s metadata

Most of the breaches this blog has covered involve one failure: a server gets compromised, or a platform preserves a GPS tag it should have stripped. In September 2026, Dutch investigative outlet Follow the Money (FTM) reported on a travel-journaling app, Polarsteps, where the location data it exposed actually came from two separate places inside the same product — and only one of them is something a file-level metadata scrubber like NearScrub was ever positioned to do anything about. The other is a different problem, and worth being honest about.

What Follow the Money found

Polarsteps, used by more than 23 million people to automatically log a travel route and attach photos to it, left its backend reachable by anyone — no login, no password, no hack. As the Belgian outlet IT Daily reported, the API had "no rate limiting, no anti-bot measures, no per-object authorization check," meaning a request for one user's trip data wasn't checked against who was actually asking. Working from that opening, FTM says it pulled down 230 million photos and videos and over a billion GPS points from nearly two million trips, along with names and follower lists. A French security researcher, Louis Couderc, had already flagged the hole in late 2025; IT Daily quotes him describing Polarsteps' response as doing nothing: "Then you are simply negligent." Using the exposed data, FTM says it traced likely home addresses for more than 30 military personnel from the US, the UK, France, and Belgium, plus Dutch service members tied to barracks including Wezep, Havelte, and Schaarsbergen — enough that the Dutch Ministry of Defence banned the app from service devices once FTM published.

Two different techniques, described in the same sentence

What makes this breach worth a closer look, rather than just a bigger number than the last one, is how FTM itself describes finding those addresses. In DutchNews' account of the investigation: "FTM pinned down dozens from the exact location saved inside users' photos — a shot of packed suitcases taken at home, for example — and worked out many more from the spots people returned to each night." Those are two distinct techniques, not one. The first reads a GPS coordinate that was already sitting inside a single photo file — written once, by the phone's camera, at the moment someone photographed their packed bags before leaving. The second never touches a photo at all: it's pattern analysis over Polarsteps' own Travel Tracker log, the stream of background location points the app collects continuously while a trip is active, used to infer where someone sleeps from where the dots cluster every night. IT Daily's reporting shows the same split elsewhere in the data — a service member identified not from any photo but because he "regularly stops at a primary school in his village," a pattern visible only across months of the app's own tracking.

Two sources of location data inside one Polarsteps trip A photo you upload GPS tag written once, by the camera, inside that one JPEG — e.g. a suitcase photo taken at home. Scrubbed before upload: the file carries no coordinate — nothing left for that app's API, or any future one, to leak from this specific file. The Travel Tracker log GPS/Wi-Fi/cell points written continuously by the app itself, whether or not a photo is taken. Not inside any file: no metadata tool, before or after upload, reaches a service's own location-tracking feature or a broken API access check.
The same breach, the same investigator, two unrelated causes — one lives inside a photo file and can be scrubbed out of it before upload, the other lives inside the app's own tracking feature and can't be touched by any file-level tool.

What Polarsteps changed, and what no file ever could

Polarsteps disputes calling this a breach — its public statement says trips and profiles are private/followers-only by default and that FTM worked from data its API exposed, not from broken authentication. Whatever the framing, the company's own fix lines up with the two-source picture above: it says it tightened rate limiting on the API, now requires manual approval before someone can follow a profile, and — specifically — stopped including a photo's location data in what the API hands back, rolling that change out in two stages, in February and August 2026. That last piece is Polarsteps closing the same channel a pre-upload scrub closes, just from the other end: once the location was never read out of your photo and republished through the API, it doesn't matter that the API itself used to have no per-request authorization check. Nothing in that fix, or in any fix Polarsteps could ship, touches the Travel Tracker's own background log — that feature works by design, collecting location continuously as you carry your phone, and the privacy question there is whether you want a service collecting and storing that stream at all, not whether a file it stores has a tag in it. The Dutch Ministry of Defence's response — banning the app outright on service devices — is really an answer to that second question, and it's not one a metadata tool can give.

What scrubbing metadata before you post actually changes here — and what it can't

If the suitcase photo FTM describes had been run through a browser-based scrubber before it was added to a trip, the file handed to Polarsteps would have carried no GPS tag for that API, or any future one found to have the same hole, to ever read out and leak — the location simply wouldn't have been there to expose, independent of whether the app ever fixed its access controls. That's a real, narrow thing a tool like NearScrub does, and it's exactly what Polarsteps itself eventually did on its own end for new API responses. It is not the same as disabling a travel-tracking app's own ongoing collection of your location, and it does nothing about the access-control bug that let FTM read other people's data in the first place — those are server-side problems with server-side fixes, not file problems. And since this is a client-side tool that only processes JPEG, PNG, PDF, and Office files, it has nothing to offer the video files FTM says were also part of what the API exposed; that's simply outside what the format support covers, not a case of the tool quietly falling short of a claim it made.