Misi Rakyat Data Leak: What the Leaked Samples Actually Reveal

Misi Rakyat Data Leak: What the Leaked Samples Actually Reveal

A database allegedly belonging to Misi Rakyat started circulating online in Malaysia in early September 2026.

The headline number is already large: 300,518 customer records and claims of approximately 1.88 million transaction records. Those figures have been reported as part of the allegations surrounding the circulating database, not as numbers independently confirmed by Misi. The Rakyat Insight report on the alleged Misi Rakyat database sale Kosmo — Misi investigating alleged leak of 300,000+ customer records

But numbers alone do not tell us whether a breach actually happened.

What makes this case worth examining is the structure of the samples being circulated.

They appear to contain data covering customers, riders and vendors, alongside application configuration material that references Misi's infrastructure.

That does not prove how the data was obtained.

It does, however, make this considerably more interesting than a random list of leaked names and phone numbers.

What Misi has confirmed

Misi has not confirmed that the leaked dataset is genuine.

On 8 September, founder Nur Ahmad Faiz Mohd Azmi said the company's cybersecurity team had started a comprehensive internal investigation to establish whether the allegations were authentic and whether there had been unauthorised access to its systems.

Misi also said it was engaging with relevant authorities and advised users to be cautious of suspicious calls, emails and messages claiming to come from Misi. Siakap Keli — Misi launches internal investigation into data-leak allegations

That distinction matters.

For now, the correct description is:

An alleged data breach under investigation.

Not:

A confirmed Misi Rakyat breach.

---

The leaked customer schema

One circulating sample contains fields resembling:

entity_type
name
email
phone_number
phone_normalized
profile_username
profile_location_name
profile_latitude
profile_longitude
address_primary
address_city
address_state
address_zip
address_country
address_latitude
address_longitude

If authentic, this is significantly more sensitive than a conventional contact list.

The combination of:

name
email
phone
address
latitude
longitude

can potentially connect a person's identity with a physical location.

The presence of both profile coordinates and address coordinates is also notable.

It suggests that the underlying application may distinguish between a user's general profile location and a stored delivery address.

That is an application-level data model, not merely information somebody could easily scrape from a public webpage.

Source: sample data reviewed by the author. The authenticity of the sample has not been independently established.

---

Rider data is considerably more sensitive

The rider sample contains a much larger set of fields.

Among the fields allegedly exposed are:

rider_id
rider_ic
rider_status
rider_rating_avg
rider_employment_type
rider_vehicles_count
vehicle_list
rider_roadtax_expiry_date
rider_license_expiry_date
rider_gdl_expiry_date
rider_max_pickup_distance_km
rider_max_delivery_distance_km
rider_opening_time
rider_closing_time
rider_rating_count
rider_is_active
rider_current_zone_id

This is no longer ordinary customer information.

If genuine, it could represent a combination of:

• identity data
• employment information
• operational information
• vehicle information
• licensing information
• location information
• performance data

The alleged presence of rider_ic is particularly serious because identity-document information has substantially higher abuse potential than a normal username or email address.

However, the field's presence in a circulating sample is not by itself proof that every corresponding value is genuine.

That still needs independent verification.

Source: sample data reviewed by the author. The authenticity of the values has not been independently established.

---

Vendor records contain another layer

The vendor sample contains fields such as:

vendor_name
type
bank_account_holder_name
bank_account_number
bank_swift_code
phone_number
phone_normalized
location
state

Some circulating rows also contain what appear to be Malaysian bank account and SWIFT/BIC information.

We should be careful with terminology here.

This is evidence of alleged financial information exposure.

It is not evidence that the banking systems themselves were compromised.

Those are very different things.

A database containing a vendor's bank account number does not mean an attacker obtained access to the bank.

It means the information may have been exposed from whichever system was storing it.

Source: sample data reviewed by the author. The authenticity and provenance of the records have not been independently established.

---

Then there is the .env file

This is one of the more technically interesting parts of the material being circulated.

A configuration sample allegedly associated with the application contains references to:

BASE_ENDPOINT=https://app.misirakyat.com/
ENDPOINT=https://app.misirakyat.com/api/
APP_LINK_URL=https://link.misirakyat.com/
WEBSOCKET_ENDPOINT=wss://misirakyat.com

SECRET_KEY=[REDACTED]
FEEDBACKNEST_API_KEY=[REDACTED]
RADAR_PUBLISHABLE_KEY=[REDACTED]

The actual secret values should not be republished.

Even with the values removed, the configuration is useful as evidence because it references application infrastructure and third-party services.

But there is an important caveat:

A leaked .env file does not automatically prove that the values were production secrets, nor does it prove that they were still valid when leaked.

That requires verification from the system owner and the relevant service providers.

Source: configuration sample reviewed by the author. Credential values have been deliberately redacted.

---

SECRET_KEY is the most interesting item

The name alone does not tell us what the key can do.

Depending on the application's implementation, a secret with this name could potentially be used for:

• session signing
• JWT signing
• application-level cryptography
• token generation
• other security-sensitive operations

Therefore, it would be irresponsible to claim:

"The attacker can now log in as anyone."

We do not know that.

The correct question is:

Where is this secret consumed by the application?

If it signs authentication tokens, the impact could be severe.

If it is only used for an unrelated internal function, the impact could be much smaller.

---

The third-party API key needs the same treatment

The configuration also contains an API key associated with a feedback service.

An API key does not automatically have unlimited access.

The important questions are:

Is the key still active?
What scopes does it have?
Can it read data?
Can it write data?
Can it delete data?
Is it restricted by IP?
Was it a production key?

Only the service owner can answer those questions with confidence.

The presence of a key is evidence that a credential-like value was present in the configuration.

It is not evidence of what an attacker could actually do with it.

---

The Radar key looks different

The leaked configuration also contains a Radar key that appears to identify itself as a test/publishable key.

That distinction matters.

A publishable client-side key is not equivalent to a private server credential.

If it is genuinely a test publishable key, its exposure may be comparatively low risk.

Again, the important question is not simply:

"Was a key leaked?"

It is:

What capability did that key actually provide?

Capability matters more than the fact that a key exists.

Source: configuration sample reviewed by the author. The test/publishable classification is based on the apparent key format and should still be verified with the provider.

---

There are signs of a structured application export

One of the stronger technical clues is the consistency between the datasets.

Customer records contain common profile and address fields.

Rider records appear to extend that user structure with rider-specific fields.

Vendor records follow a different but equally structured model.

There are also fields such as:

entity_type
user_id
rider_id
current_zone_id
vendor_name_matched

This looks more like an application-level data model or export than a random collection of scraped public information.

That is an important clue.

It is not proof of the intrusion method.

But it raises several possibilities:

• internal database export
• backup exposure
• compromised application environment
• privileged account access
• third-party data exposure
• another internal data source

Without logs or forensic evidence, none of those scenarios should be presented as fact.

---

The scientific notation problem

Some bank account values in the circulating CSV appear in forms such as:

1.13E+14
1.63E+11

That could simply be CSV handling.

Spreadsheet software frequently converts long numeric strings into scientific notation.

If the original values were numeric-looking account numbers, opening and saving the CSV through spreadsheet software could produce this kind of transformation.

This may therefore tell us something about the handling of the leaked file, rather than the database itself.

It is another reason why the original artifact matters.

If the file has been opened, converted and resaved multiple times, some of the original metadata and formatting may already have been lost.

---

What we know versus what we don't

The distinction is deliberate.

A security investigation should not turn an unverified sample into a confirmed incident simply because the sample looks convincing.

---

The bigger question: where did the data come from?

There are several plausible scenarios.

Scenario 1: Database compromise

An attacker gained access to an application database and exported the data.

This would explain the structured relational-looking records.

But database logs, access records or other forensic evidence would be needed to establish that this actually happened.

Scenario 2: Backup exposure

An old or current database backup was exposed through storage, a server, a CI/CD artifact or another system.

This could produce a very clean dataset without requiring direct database exploitation.

Scenario 3: Application/server compromise

An attacker obtained access to the application environment and extracted both application data and configuration.

This becomes more interesting if the .env material is genuine and originated from the same environment.

But that remains a hypothesis.

Scenario 4: Third-party compromise

A vendor, integration or service provider could theoretically have had access to some of the same information.

The dataset structure would need to be compared with what each third party actually receives.

Scenario 5: Fabricated or partially fabricated material

This cannot be dismissed until the samples are independently validated.

A convincing CSV is not automatically proof of a real breach.

---

What would prove the case?

The most useful evidence would be:

1. A cryptographic hash of the original leaked archive.
2. Database export metadata.
3. Timestamps inside the dataset.
4. Records that can be independently verified by Misi.
5. Evidence showing whether supposedly current records actually exist in the live system.
6. Server, database and API logs around the suspected access period.
7. Cloud/storage access logs.
8. CI/CD artifact history.
9. Secret rotation history.
10. Authentication and token issuance logs.

The strongest evidence would be a controlled verification by Misi.

For example:

"Here is a random record from the alleged dataset. We confirm that it exists in our internal database and was last modified on X."

That would move the discussion from speculation to evidence.

---

Previous security history makes the investigation more interesting

There is also historical context.

In July 2023, Malaysia's Personal Data Protection Department (JPDP) said it had opened an investigation into allegations of a personal-data leak involving the Misi Rakyat website, owned by Bangsa Bertauhid Sdn. Bhd.

JPDP said it received an incident report from MyCERT on 4 July 2023. On the same day, JPDP contacted the company to obtain confirmation of the incident and samples of the affected data. The company was also instructed to conduct an internal investigation and submit a Data Leakage Notification. Misi Rakyat's founder was subsequently called to give a statement. JPDP said it was working with CyberSecurity Malaysia on the investigation. RTM — JPDP investigates alleged Misi Rakyat data leak

The incident was also mentioned in the Dewan Negara Hansard of 31 July 2024, during debate on personal-data protection. Hansard Dewan Negara, 31 July 2024

That historical incident is relevant context.

But I would not connect it to the 2026 allegations without technical evidence.

There is currently no basis for saying that the 2026 dataset is simply the same material from the 2023 incident.

Old data being recycled is possible.

So is a completely separate incident.

Those are questions for forensic verification, not assumptions.

---

What users should do now

Until the investigation is complete, users should assume that exposed contact information could potentially be used for phishing or impersonation.

Misi itself has advised users to be cautious about suspicious calls, emails and messages and not to share personal information or passwords. Misi's user-safety guidance via Siakap Keli

If you use Misi:

• Be suspicious of unexpected calls claiming to be Misi.
• Do not disclose OTPs or passwords.
• Do not click unexpected payment or account-recovery links.
• Be especially cautious if a caller knows your name, phone number or delivery address.
• Use unique passwords for every service.

A data leak does not necessarily end with the leaked database.

The follow-up phishing and impersonation attempts can sometimes be the more practical threat to ordinary users.

---

What the .env exposure means for the operator

If the configuration originated from a real production environment, the response should not stop at deleting the file.

Any credential-like value that may have been exposed should be treated as compromised until proven otherwise.

That means:

• rotate application secrets
• revoke exposed API keys
• invalidate sessions if relevant signing material was exposed
• inspect authentication logs
• inspect API access logs
• review CI/CD variables and build artifacts
• search Git history for previous copies
• check backups and object storage
• verify third-party integrations
• review access permissions
• confirm whether test and production environments were separated

If a secret was ever committed to Git, deleting it from the latest commit is not enough.

The value may still exist in:

Git history
fork
clone
CI artifact
cache
backup

The secret must be rotated.

---

The important takeaway

The interesting part of this incident is not simply the alleged number of records.

It is the breadth of the alleged data model.

The samples circulating online appear to cover three different populations:

CUSTOMERS
   |
   +-- identity
   +-- contact
   +-- address
   +-- location

RIDERS
   |
   +-- identity
   +-- KYC
   +-- vehicle
   +-- licence
   +-- operations
   +-- location

VENDORS
   |
   +-- identity
   +-- contact
   +-- location
   +-- banking information

And alongside those samples, a configuration file allegedly exposes application endpoints and security-sensitive configuration.

If independently verified, that would represent a serious multi-domain data exposure, not merely another list of leaked phone numbers.

But as of 8 September 2026, the responsible conclusion remains:

The samples are serious enough to warrant investigation, but the breach itself remains unconfirmed by Misi.

Misi has said its cybersecurity team is investigating whether the allegations are authentic and whether unauthorised access occurred. Misi data-leak investigation report — Siakap Keli

That distinction is important.

Security analysis should follow the evidence, not the size of the headline.

This article intentionally does not reproduce passwords, API credentials, identity numbers, bank account numbers, addresses, coordinates or other sensitive information from the circulating material.

Sources

• The Rakyat Insight: 300,000 Data Pelanggan, 1.88 Juta Transaksi Misi Rakyat Didakwa Dijual Di Pasaran Gelap (8 Sep 2026)
• Kosmo: Misi siasat dakwaan kebocoran data lebih 300,000 pelanggan (8 Sep 2026)
• Siakap Keli: Dakwaan Kebocoran Data, Misi Jalankan Siasatan Dalaman (8 Sep 2026)
• RTM: Kebocoran data peribadi — JPDP siasat laman sesawang Misi Rakyat (2023)
• Parlimen Malaysia: Hansard Dewan Negara, 31 July 2024