TL;DR: MapRoulette had several security vulnerabilities which may have exposed access credentials (but not passwords) and user email addresses to attackers. These vulnerabilities have been fixed, and the exposed credentials have been revoked. There is no evidence in the maproulette.org server logs that they were exploited. Ordinary users do not need to take any action, but if you are a developer who uses MapRoulette API keys or if you run your own MapRoulette instance, read below for how the fixes for these vulnerabilities affect you.
Summary
MapRoulette (https://maproulette.org) is an open-source tool that helps OpenStreetMap contributors find and fix small problems on the map. I’m Jake Low, a current maintainer of MapRoulette and lead software developer at OpenStreetMap US.
On October 7, 2026, while working on the MapRoulette backend code, I discovered several serious security vulnerabilities. The most severe of these could be used by an attacker to learn the email addresses of MapRoulette users, and to obtain OSM access tokens which would let the attacker impersonate those users and make edits to OpenStreetMap under their names.
Upon discovering this, I took the application offline, revoked all credentials that could have been compromised, patched the code to eliminate these vulnerabilities, and deployed the new version (v4.11.0). In total MapRoulette was offline for about 15 hours.
After fixing the application, I reviewed the server logs carefully and found no evidence that any of these vulnerabilities were exploited maliciously. However, MapRoulette’s server logs cover only the last 29 days, and some of these bugs existed for years, so I cannot be sure that they were not exploited at some earlier time.
I’m writing this post to explain what happened in detail, what I’ve changed about MapRoulette as a result, and what I and the other maintainers will do to prevent issues like this from happening in the future.
Vulnerabilities
I found four major vulnerabilities, plus two smaller issues while fixing them.
-
Private user data was included in public API responses. When MapRoulette’s API returned information about a user (for example, in a list of followers, or through the GraphQL API used by certain features of the website), it included every field in the user’s record in the database, not just the public ones. This included the OSM access token MapRoulette stores for each user, their MapRoulette API key, and their email address (if they provided it, which is required for challenge creators but optional for other users). Several of these API endpoints did not require logging in, and one of them accepted a list of many user IDs at once. The MapRoulette website did not display these fields, but they were sent in JSON form to ordinary visitors during routine activity. Since MapRoulette’s OSM tokens include permission to edit the map, anyone who collected them (by inspecting the network traffic in their browser’s devtools, or by making manual API requests) could have made edits to OpenStreetMap that appeared to come from those users. (First introduced April 2020)
-
MapRoulette API keys were readable by other OSM applications. To let editors like Rapid and the JOSM MapRoulette plugin talk to MapRoulette on a user’s behalf, MapRoulette saved each user’s API key into their OpenStreetMap user preferences. But OSM preferences can be read by any application the user has authorized with the “read your user preferences” permission, which is one of the most commonly requested permissions. So any of those applications (or anyone who compromised one of them) could read the API key and use it to take over the user’s MapRoulette account. From there, it could also retrieve the user’s OSM token from MapRoulette and use it to edit OSM as that user. (First introduced October 2022)
-
Providing an empty API key would grant the user administrator privileges. MapRoulette supports a configuration value called the “super key” that grants administrator access to anyone who presents it. By default this was an empty string, and maproulette.org never set it. Because of a bug in how the key was checked, sending an empty API key with a request was treated as presenting the super key. Administrator users have full access to all data in MapRoulette: they can see every user’s private data, edit or delete other users’ challenges, and grant administrator rights to other accounts. (First introduced March 2017)
-
Several API endpoints were vulnerable to SQL injection, a class of bug that lets an attacker run any query they want to against the database. An attacker could have used them to read any data in MapRoulette’s database, including the same OSM tokens and email addresses exposed by the first vulnerability. (Several distinct vulnerabilities, the oldest of which was introduced November 2019)
Smaller issues:
- The session cookie that keeps you logged in to MapRoulette contained a copy of your OSM token in readable form. Anyone who obtained the cookie (for example, from a browser screenshot or a file attached to a bug report) could have extracted the token.
- Some error responses included internal details such as stack traces.
Server log analysis
I reviewed the web server’s access logs and MapRoulette’s application logs, covering September 8 to October 7, 2026. I looked for:
- GraphQL requests that returned large results,
- requests that used an empty string as their API key,
- API keys that were used from many different IP addresses,
- admin pages that were accessed by non-administrator users, and
- any SQL injection attempts
I found no evidence in the logs of any malicious exploitation of any of these vulnerabilities. The only SQL injection probing I saw came from generic automated scanners which search for vulnerable Wordpress sites; there were no signs of SQL injections on MapRoulette’s vulnerable API endpoints. I did find one case where a third-party app accidentally triggered the super key bug by sending an empty API key while updating a task’s status, but this appears to be an innocent bug in a well-known application and not malicious activity. I have also reviewed the list of accounts with administrator privileges and found that there were no unexpected entries.
However, this analysis cannot completely rule out the possibility of an attack because:
- The logs only go back 29 days, but the vulnerabilities existed for years.
- The logs do not record request bodies or cookies, both of which could be used to deliver SQL injections. A clever attacker might anticipate that these parts of the requests would not be logged, and use them to smuggle their injected strings through unnoticed.
- The second vulnerability starts with reading OSM preferences, which happens on openstreetmap.org, not on MapRoulette.
Actions taken
- Revoked all credentials. I deleted MapRoulette’s OAuth application on openstreetmap.org, which revokes every OSM token it was ever issued, and registered a new one. I also expired all session cookies on maproulette.org, which logs everyone out.
- Fixed the public API endpoints which were leaking private fields. Any user information that MapRoulette returns from any API endpoint now includes only an explicit list of public fields by default (ID, OSM username, avatar, etc). Endpoints that need to return additional sensitive info (like the admin endpoints or the /user/whoami endpoint) do so explicitly in their serialization code.
- Disabled API keys. MapRoulette no longer accepts API keys for authentication, and the super key feature has been removed. This breaks several common user workflows; see below for more details.
- Session cookies no longer contain your raw OSM token. I also changed the site’s cookie security settings so cookies are only sent over HTTPS, are not attached to requests made from other websites, and expire after 30 days.
- Fixed the SQL injection vulnerabilities and stopped returning internal error details to clients, which can sometimes be used to extract the results of injected queries.
The full list of changes is in the release notes for v4.11.0.
Users whose emails were exposed by these vulnerabilities will also receive an email from maproulette@maproulette.org soon to notify them of this incident, and containing a link to this forum post. You do not need to take any action. MapRoulette will never ask you for your OpenStreetMap password; beware of any emails claiming to be from us which do so.
Impact on users
The next time you visit https://maproulette.org/, you’ll need to log in again. OpenStreetMap will ask you to authorize MapRoulette again, because its OAuth application ID has changed.
Additionally, MapRoulette API keys no longer work. This breaks several tools that relied on them:
- Standalone Rapid (rapideditor.org) and the JOSM MapRoulette plugin can no longer update task status in MapRoulette. You can still edit with them, but you’ll need to mark tasks as done on the MapRoulette website. The Rapid editor built into MapRoulette is not affected.
- Scripts and the MapRoulette Python client that use an API key, including tools that rebuild challenges automatically, will fail with an authentication error (HTTP 401). Challenge owners can still rebuild challenges through the MapRoulette website in the meantime.
- The API key section on your profile page no longer does anything and will be removed.
- Your old API key may still be in your OSM preferences as maproulette_apikey_v2, but it can no longer be used for anything.
I know this disrupts people who use these tools and workflows. I plan to bring this functionality back in a safer form, but removing the feature was the fastest and safest way to fix this vulnerability.
You do NOT need to change your OpenStreetMap password. MapRoulette uses OAuth to let you log in with your OpenStreetMap account. It never receives your OpenStreetMap password, and none of the vulnerabilities above could be used to steal it. As always, only enter your OSM password on openstreetmap.org. MapRoulette will never ask you for it, so be wary of any email or message about this incident that does.
If you run your own MapRoulette server
All self-hosted MapRoulette deployments running a version above v2.0.3 (released early 2017) are affected by at least one of the vulnerabilities. If you run your own instance of MapRoulette, you should immediately do the following:
- Update to v4.11.0.
- Delete your MapRoulette OAuth application on openstreetmap.org (this revokes all of its associated user tokens) and register a new one with the scopes read_prefsandwrite_api. Add the new application’s ID and secret key to your MapRoulette backend’s application.conf file.
- Clear stored OSM tokens in your database. This will also log out all existing sessions (since the hash of the token is part of the session cookie). You can do this with the following command:UPDATE users SET oauth_token = gen_random_uuid()::text, oauth_secret = '';
- Review your server logs for signs of a breach, and review the list of superuser accounts.
Future work
In the short term I plan to:
- Bring back integrations for editors like Rapid and JOSM, using a more secure form of authentication (details still to be determined).
- Replace API keys for scripts with personal access tokens, which work like API keys but are only shown once, are revocable, and have a finite lifetime before they expire.
To make incidents like this less likely in the future, I also intend to:
- Remove GraphQL from the application, which will significantly reduce the surface area of potential vulnerabilities that MapRoulette presents to attackers.
- Remove the ability to follow other users, and reduce the number of endpoints that return information about specific users.
- Remove user email addresses from the database. MapRoulette has historically collected email addresses mainly so that challenge authors can be reached if mappers have concerns about their challenges, but the OpenStreetMap API now permits third-party apps like MapRoulette to send OSM direct messages to users, so we can do this instead.
- Audit the codebase for other unsafe configuration defaults or SQL injection risks.
- Audit other codebases maintained by OpenStreetMap US (namely OSMCha and Field Papers, both of which have stateful backend services and user accounts) for vulnerabilities similar to these.
- Publish a security policy explaining how to contact the MapRoulette maintainers if you discover a vulnerability.
- Increase our log retention to 90 days.
Speaking both for myself and on behalf of OpenStreetMap US, I’m sorry for the disruption and for the risk this created. If you have questions, please feel free to reply in this thread or contact me directly.