Skip to content
Llorenç Romà

Type to search…

↑↓to navigate
Esc

CVE-2026-14850: Arbitrary Password Reset in MobiAPParc

A client-controlled user_id in MobiAPParc’s password recovery flow allowed arbitrary password resets. Predictable IDs, email enumeration, and missing rate limiting increased the impact.

Security Research4min read

  • CVE: CVE-2026-14850 (CWE-640)
  • Severity: High, CVSS v4.0 8.8, according to INCIBE-CERT
  • Affected versions: iOS MobiAPParc through 2.28 and Android through 2.42
  • Status: INCIBE reports that SMAP fixed the vulnerability in the latest app version

MobiAPParc’s password recovery flow trusted a client-supplied user_id when setting a new password. An attacker could trigger the reset of another user’s password.

The application also used predictable user identifiers. This weaknesses could support unauthorized resets at scale. Account takeover would additionally require identifying the email address associated with a reset account.

MobiAPParc is a mobile application from SMAP for paying for regulated parking and municipal car parks in Palma. At the time of testing, the affected surface included the mobile app and the web-based password reset endpoint at /recuperar-password.

From a regular user, the password reset workflow looked normal:

  1. Submit an email address in the mobile app.
  2. Receive a password reset email.
  3. Open the reset page in a browser.
  4. Set a new password.

The interesting part turned out to be the final request, which relied only in the user_id value to reset the password of the user associated to this user_id. This value consisted in a number of up to 6 digit (as far as I observed), e.g., 123456.

MobiAPParc login and password recovery screens showing where the reset flow starts

The password reset endpoint accepted a client-controlled user_id parameter and trusted it when updating the password.

The backend did not validate that this user_id belonged to the same account that initiated the password recovery flow. In other words, the reset context and the target account identifier were not cryptographically or logically bound together.

That is the core issue. Once an attacker reaches the final password reset step for their own account, they can modify the identifier and attempt to reset another user’s password instead.

Conceptually, the vulnerable request looked like this:

POST /recuperar-password HTTP/1.1
Host: smap.studiogenesis.es
Cookie: XSRF-TOKEN=<redacted>; smap_session=<redacted>
Content-Type: application/x-www-form-urlencoded


_token=<redacted>&password=<attacker-chosen-password>&user_id=<victim-user-id>

The password belongs to the attacker. The user_id belongs to the victim. If the backend accepts that combination, the victim’s password is changed to a value chosen by the attacker.

Redacted password reset request with the password and user_id fields highlighted

The main impact is mass account password reset and the operational disruption that follows from it.

An attacker who controls their own reset flow can change the password associated with another account by modifying the user_id parameter in the final request. When combined with predictable identifiers and missing rate limiting, this enables mass password reset attacks against many accounts.

That alone is already severe. Even without logging into the affected accounts, forcing unsolicited password changes can lock users out, trigger support load, and create large-scale service disruption.

However, I did not find a direct mapping between user_id values and email addresses, and email is required to log into the app, that is why complete account takeover was not possible.

The exploitation flow was straightforward:

  1. Create a normal account in the application.
  2. Trigger the password recovery process for that account.
  3. Open the reset link from the received email.
  4. Intercept the final request before submitting the new password.
  5. Replace the original user_id with another account’s identifier.
  6. Forward the modified request.

If the user_id identifier existed, the password for that account was changed.

This is what makes the issue more than a UI bug or weak validation mistake.

The IDOR was the main vulnerability, but three other weaknesses increased its impact considerably.

The backend used low-entropy internal user identifiers. Because those identifiers were short and guessable, an attacker did not need prior knowledge of a specific victim’s exact user_id to begin abusing the reset flow.

That turns a one-off password reset bug into something that can be iterated over.

The password recovery flow behaved differently depending on whether the submitted email address existed in the system.

That allowed attackers to test candidate addresses and identify valid accounts. It did not, by itself, reveal which internal user_id belonged to a given email address.

The reset endpoint did not appear to enforce meaningful rate limiting or abuse protections for repeated password reset attempts within the same session.

That matters because the attack becomes scriptable. Instead of testing one identifier manually, an attacker can automate large numbers of modified reset requests and cause widespread account disruption.

I recorded the finding on 5 March 2026 and documented it in a responsible vulnerability report. INCIBE coordinated public disclosure on 17 September 2026 under INCIBE-2026-640 and CVE-2026-14850. Its advisory says SMAP fixed the issue in the latest app version.