Skip to content
Llorenç Romà

Type to search…

↑↓ to navigate
Esc

Garmin MapShare: Insecure Link Design and User Data Privacy (Part 2)

Password-protected MapShares had unauthenticated API endpoints allowing location requests and inReach messaging — plus guessable identifiers exposing public maps.

Security Research 4 min read

In this post, I summarize a privacy-related issue identified during independent security research on Garmin services. The issue was responsibly disclosed to Garmin, investigated by their security team, and remediated prior to publication.

The vulnerability allowed unintended access to MapShare pages due to an insecure design in the link-based access mechanism, which relied on easily guessable identifiers. Exposed MapShares could contain private messages, location data, and contact information. This issue has since been fixed.

In addition, I identified a separate flaw that enabled bypassing the access controls of password-protected MapShares, allowing unauthorized use of certain inReach functions. This issue was also reported to Garmin and has been addressed.

MapShare is a Garmin feature that lets you share your real-world GPS location and trip data with others through a web page. It’s most commonly used with Garmin inReach satellite communicators and certain GPS devices.

share.garmin.com is the web portal where your MapShare page is hosted. When you create and activate a MapShare link, it typically looks like:

Terminal window
https://share.garmin.com/YourHandle

This is the page other people can open in a browser to:

  • See your shared map and track.
  • View messages you’ve sent or send messages back (if allowed).
  • See track points or waypoints you’ve published.

You can share this URL via email, text, or social media so others can follow along. Additionally, the map’s owner can set up a password to limit access to the map.

If the MapShare’s owner is also an inReach user, the MapShare will enable anyone with access to the map to use the inReach functionalities:

  • Send a message to the map owner’s inReach device
  • Send a location and a message to the map owner’s inReach device
  • Request the current location of the map owner

The product exposes a resource retrieval API/URL that uses a low-entropy identifier (short numeric or short alphanumeric token) embedded in the URL.

The use of a low-entropy identifier enables trivial enumeration of valid MapShares. Because identifiers are short and predictable, an attacker can systematically discover existing map URLs belonging to other users.

These maps may reveal sensitive activity information, exposing users to privacy risks such as tracking of movements, routines, or behavioral profiling. If the affected user has inReach enabled, the impact increases further. By abusing the predictable identifier, an attacker can:

  • Access messages sent via the inReach service, leading to unauthorized disclosure of potentially sensitive communications.
  • Send messages to the victim through the inReach service, similar to push notifications. Although the attacker initiates these messages, the financial cost is charged to the victim, as they are billed by the vendor for receiving such messages.
  • Trigger location requests, causing the victim’s device to share its location and incur additional charges for each location retrieval.

This results in a combination of:

  • Privacy impact: exposure of user activity and location.
  • Confidentiality impact: unauthorized access to messages.
  • Financial impact: direct costs charged to the victim for unsolicited messages and location requests.
  • Potential harassment/abuse: repeated unsolicited messages and location requests can be used for stalking, extortion, or general harassment.

When creating a MapShare, the owner can specify a password. Only people who know the password will be able to view the MapShare.

For non-protected MapShares I already mentioned that it was possible to use the inReach functionalities directly from the browser.

For password-protected MapShares, the web interface correctly prevents unauthenticated users from viewing the map. However, the backend API endpoints responsible for inReach actions (e.g., location requests and message transmission) do not enforce authentication or authorization checks.

As a result, an attacker does not need to know the MapShare password to interact with the associated inReach device. Once a valid MapShare identifier is discovered, sensitive actions can be performed directly via the API.

For example, to request the location of the MapShare owner, an attacker only needs to find a valid password-protected map and execute the following request:

POST /[redacted_map_ID]/Map/LocateDevices HTTP/2
Host: share.garmin.com
Content-Length: 11


deviceIds=*

To trigger the SEND action is a bit more complicated, since the specific deviceID of the MapShare owner is required. I did not find a reliable way to figure it out; however, if an attacker manages to find it, there’s no other access control in place:

POST /[redacted_map_ID]/Map/SendLocationMessageToDevices HTTP/2
Host: share.garmin.com
Content-Length: 84
...


deviceIds=[redacted_deviceID]&messageText=[redacted]
&fromAddr=[redacted_phonenumber]&lat=[redacted]&lon=[redacted]

After discussions with Garmin, they acknowledged the findings and addressed the access-control bypass affecting password-protected MapShares. However, the use of guessable URL identifiers for non-password-protected MapShares remains.

Garmin stated that public MapShares require explicit user opt-in and that interactive features (such as location requests or inReach messaging) must also be explicitly enabled by the user.