MOL Move flaws let users turn accounts into employees

On 29 July 2026, Polish cybersecurity publication Niebezpiecznik documented researcher Filip Dębiński’s findings in the MOL Move application. According to that original report, a profile-update endpoint accepted additional fields in a POST request even though users could not edit them in the interface. The behaviour allowed a standard account to be changed into an employee account and enabled changes to the email address, referral code, loyalty-card code and loyalty tier.

This is not evidence that somebody “hacked all of Salesforce” or that a customer database was leaked. The researcher reached an expanded view of his own account and part of a Salesforce interface, but the report says he did not find a way to access other users’ data. The second half of the story is equally important: the first responsible-disclosure attempts did not produce an effective response, and MOL later said the original message had been classified as spam.

What the 29 July report confirms

Niebezpiecznik’s original Polish report provides the technical description, disclosure timeline and MOL Polska press-office responses. It supports the following claims:

• the profile endpoint accepted fields that were absent from the user interface;
• an email address could be changed without verification of the new address;
• a selected field value could mark a normal account as an employee account;
• a user could change a referral code, loyalty-card code and loyalty tier;
• Salesforce-related interface elements became available and some of the researcher’s own records could be edited;
• the researcher did not confirm access to records belonging to other customers.

MOL told the publication that the information had been forwarded to the appropriate MOL Group teams and was being handled under its security procedures. The company did not disclose the status of a specific fix, citing security reasons. It would therefore be wrong to claim that the behaviour definitely remains exploitable, but there is also no public technical evidence that lets an external observer declare remediation complete.

Technical root cause: the client cannot define authority

An interface may hide an employee, email, tier or cardCode field, but that is not a security control. An attacker does not have to use the form. They can reconstruct the HTTP request, add parameters and send it directly to the API. The backend needs an explicit list of fields that the current role may change.

The report fits the vulnerability class known as mass assignment, over-posting or improper authorization of object fields. A framework maps JSON or form input to an application model, while the developer assumes that the client will submit only fields shown on screen. If the serializer accepts everything, the trust boundary has moved into a browser controlled by the user.

The safer pattern is not a growing denylist of dangerous names. It is a dedicated input object for each action:

UpdateCustomerProfile = {
  displayName,
  phoneNumber,
  marketingConsent
}

Employee status, role, loyalty-card identity and tier should be managed by separate operations with separate authorization, audit trails and business-rule validation. When one generic updateProfile() function persists arbitrary model properties, testing should assume that a user will eventually submit something the interface never rendered.

Why this is not merely a form bug

Changing a user role is vertical privilege escalation. Changing an email without verification can become an account-takeover stage if password recovery trusts the new address. Altering a loyalty tier or card code affects programme integrity, partner settlement and potentially financial benefits.

Those consequences differ, but the cause is shared: the server authorizes “edit your profile” without checking which properties the user may edit. It is closely related to the authorization failures in our IDOR and BOLA testing guide. IDOR normally concerns selecting somebody else’s object; mass assignment concerns a prohibited property on one’s own object. A mature penetration test covers both dimensions.

Salesforce Sites is not evidence of a platform defect

The report says that MOL Move used Salesforce Sites and that custom-field names could be recognized through a characteristic suffix in code. That does not mean Salesforce automatically granted an employee role. The platform supplies data and API mechanisms, while the implementation still has to configure object access, field access, profiles and custom endpoints correctly.

A remediation review should separate:

1. Salesforce profile or guest-user privileges;
2. input validation in a controller or Apex code;
3. record-level access rules;
4. the email-change workflow;
5. loyalty-programme business logic;
6. exposure of administrative interfaces.

Fixing one endpoint without reviewing similar controllers can leave the same pattern elsewhere. Teams should identify every operation that deserializes client data into domain objects and test its authorization at property level.

How to verify remediation safely

A retest should not grant real benefits or interfere with production customer data. Dedicated test accounts and harmless marker values are enough. The team should demonstrate that:

• fields outside the allowlist are rejected or safely ignored;
• email changes require confirmation through the old and/or new address according to the threat model;
• an employee role can only be granted through a controlled administrative workflow;
• the backend recalculates loyalty tier from trusted events;
• every privilege increase and loyalty-identifier change reaches a tamper-resistant log;
• monitoring detects unusual bulk changes to profiles or privileged fields;
• equivalent endpoints do not repeat the pattern.

An automated scanner may discover a public endpoint, but it cannot understand why an employee flag or loyalty tier matters. That is why a manual web application and API penetration test needs roles, workflows and field semantics—not only familiar payloads.

The second vulnerability: an ineffective disclosure channel

The researcher tried to report the issue on 27 April, 15 May and 6 June. After Niebezpiecznik contacted the press office, the company requested technical details. MOL later said the original message reached the correct handling channel late because mail servers had classified it as spam.

The absence of a bug-bounty programme is not decisive. A bug bounty pays rewards. A Vulnerability Disclosure Programme defines a safe channel, scope, good-faith rules, expected acknowledgement time and coordination process. An organization can decline to pay rewards and still handle security reports professionally. Our guide to VDPs versus bug bounties explains the distinction.

A minimum process should provide:

• /.well-known/security.txt with a current contact and expiry date;
• a mailbox handled by security staff rather than a general office address;
• encrypted communication and safe file transfer;
• automatic acknowledgement with a case number;
• owner cover during absence and monitoring of spam folders;
• impact-based triage targets;
• a clear safe-harbour policy for good-faith research;
• a record from intake through remediation and retest.

For organizations within NIS2 or Poland’s national cybersecurity framework, vulnerability intake is part of risk management, not a courtesy to researchers. A security.txt file is also insufficient if it points to an unattended mailbox.

What owners of similar applications should do

Inventory endpoints that update users, organizations, subscriptions, loyalty programmes and roles. Compare fields accepted by the backend with fields each role is actually authorized to modify. Include JSON, form data, GraphQL, bulk operations, CSV imports and mobile clients that reuse the API.

Then review historical telemetry. Look for privileged-field changes from customer sessions, sudden tier increases, email modifications without a corresponding verification event and sequences in which a normal account opened employee-only views. The absence of a log does not prove that abuse did not occur; it is an evidence gap that should be recorded explicitly.

Finally, exercise the disclosure process. Send a controlled report from an external address and measure acknowledgement, escalation, encryption and time to the product owner. This is useful training material for employees. Cybersecurity training and phishing simulations should teach people not only to spot fraud, but also to recognize messages whose automatic rejection could increase the organization’s risk.

Sources and limits of inference

The facts about the application’s behaviour, contact attempts and MOL responses come from Niebezpiecznik’s 29 July 2026 report. The statement that the researcher did not access other users’ data comes from the same account; it is not proof that no other attack path existed.

The mass-assignment analysis, property allowlists, detection ideas, retest plan and VDP recommendations are BreachRoad conclusions based on the public mechanism. We do not claim that data was leaked, that criminals exploited the issue, or that the behaviour remains active. The practical conclusion is narrower: field-level authorization and disclosure handling are two parts of the same security system.

Evidence that a fix really works

Removing fields from a mobile response is not a sufficient retest. Build a role-and-operation matrix covering an anonymous client, loyalty member, station employee, administrator and system integration. Define which properties each role can read or write, then exercise the backend without relying on the user interface. This is a standard objective in a web and API penetration test.

Keep evidence at three levels:

• negative: an unauthorised property is rejected and the stored record remains unchanged;
• positive: legitimate profile updates still work;
• observable: the attempt produces an event containing the identity, role, property and authorisation result.

Include alternative representations of the same operation. If the product has multiple API versions, bulk endpoints or a Salesforce integration, correcting one route does not close the class. A regression test should run whenever the user model changes so that a newly introduced privileged property does not silently become client-writable.

The disclosure path deserves an equivalent control. Publish security.txt, define safe-testing boundaries and ensure the security mailbox has an acknowledgement, monitored queue and backup owner. Track time to acknowledgement, routing, reproduction, mitigation and retest—not merely ticket closure. Our guide to vulnerability management as a process connects technical priority to business ownership, while the Breachroad Academy provides a safe foundation for understanding application-security controls.

The final deliverable is therefore more than a patch: it is an explicit authorisation rule, automated regression coverage, an abuse signal and a channel through which the next researcher can warn the company safely.