Misi Rakyat Now Acknowledges Cyberattack: What Changed After the Data Leak Analysis?

On 8 September 2026, I published an analysis of the alleged Misi Rakyat data leak.

At the time, the position was fairly straightforward:

the material appeared serious, but there was not enough public evidence to establish that Misi Rakyat's production systems had been compromised.

One day later, that picture changed.

On 9 September 2026, Misi Rakyat issued an official statement saying that the company had become the target of a malicious cyberattack.

That matters because the statement provides new context for several of the technical findings discussed in my earlier analysis.

But it also creates an important distinction:

Misi Rakyat has now acknowledged malicious cyber activity. That does not automatically confirm every claim surrounding the leaked dataset.

So rather than simply updating the headline, I want to compare what was known before with what Misi Rakyat is saying now.

---

1. What did my earlier analysis actually say?

In my previous article, "Misi Rakyat Data Leak: What the Leaked Samples Actually Reveal", I deliberately avoided calling the incident a confirmed breach.

Why?

Because at that point, Misi Rakyat was still investigating the allegations.

The material I examined contained information that appeared significant from a technical perspective.

The samples appeared to contain categories such as:

• customer-related data;
• rider-related data;
• vendor information;
• location information;
• KYC-related fields;
• operational information;
• application configuration;
• API-related configuration.

There was also configuration material that appeared to reference application endpoints and third-party services.

But I deliberately made a distinction between:

"data that appears to originate from Misi Rakyat-related systems"

and:

"data proven to have been obtained through a compromise of Misi Rakyat's production infrastructure."

Those are not the same thing.

The evidence status at the time was roughly:

That was the evidence position on 8 September.

---

2. What changed on 9 September?

The latest statement changes one important thing.

Misi Rakyat now explicitly describes the activity as a:

"malicious cyberattack."

The company says its technical team conducted an internal investigation and identified patterns in the activity.

This gives us a new layer of information.

Previously:

Misi Rakyat was investigating alleged data leakage.

Now:

Misi Rakyat says it has identified malicious cyber activity targeting the company.

That is a significant development.

But it still does not answer every question surrounding the leaked dataset.

---

3. Does this mean my previous article was wrong?

No.

In fact, the distinction made in the original article becomes even more important now.

The earlier analysis did not say:

"Misi Rakyat was not hacked."

It said:

there was not enough public evidence at the time to establish how the leaked material had been obtained.

That remains different from Misi Rakyat's current statement.

The company has now confirmed, from its own investigation, that it considers the activity to be a malicious cyberattack.

However, several questions remain open.

For example:

Was the leaked dataset obtained through that attack?

That has not been publicly demonstrated in the statement.

---

4. A cyberattack is not automatically a data breach

This distinction is important.

For example:

Attacker
   |
   v
Scanning
   |
   v
Exploit attempt
   |
   v
Blocked

That can constitute malicious cyber activity without necessarily resulting in a personal-data breach.

Compare that with:

Attacker
   |
   v
Unauthorized access
   |
   v
Personal data accessed
   |
   v
Data exfiltrated

That is a very different situation.

This is why I would not automatically describe the incident as a confirmed personal-data breach simply because Misi Rakyat has acknowledged a cyberattack.

We still need evidence establishing what data was actually accessed, whether it was exfiltrated, and whether the leaked material originated from that activity.

---

5. What about the exposed API keys and configuration?

This is one of the more interesting parts of the story.

The material I analysed previously contained configuration that appeared to reference Misi Rakyat-related application infrastructure, including endpoint and credential-like information.

But an important distinction applies:

The existence of an API key does not automatically mean an attacker can access the backend.

What matters is the capability of the credential.

For example:

Still active?
Scope?
Read access?
Write access?
Delete access?
Production?
Development?
IP restricted?

The new Misi Rakyat statement says that the API keys and configurations associated with the older application version have been updated and can no longer be used to access its systems.

From an incident-response perspective, credential rotation and revocation are sensible measures.

However:

credential rotation addresses the exposed credential.

It does not, by itself, explain how the leaked dataset was originally obtained.

---

6. The "old application version" claim matters

Misi Rakyat also says that the application version analysed was an older version that is no longer in use.

If accurate, this is important.

An old application binary may contain:

old API endpoints
old credentials
old configuration
old authentication flows
old third-party integrations
old application logic

If those components have genuinely been retired, their current production risk may be significantly lower.

But an old application version can still be valuable during security research.

Reverse engineering an old binary can reveal:

• historical architecture;
• endpoint structures;
• authentication assumptions;
• backend behaviour;
• third-party integrations;
• historical credentials;
• implementation patterns.

Therefore, saying that the application is old does not automatically make the analysis irrelevant.

It means we need to establish which findings still apply to the current production environment.

---

7. Misi Rakyat is also rejecting the implication that its current systems remain accessible

This is actually consistent with the cautious position taken in the earlier analysis.

I did not state:

"The API key is still active."

The earlier analysis classified the status of the production credential as unknown.

Misi Rakyat has now provided its position:

the relevant credentials and configurations have been updated and can no longer be used to access its systems.

So the evidence table can now be updated:

This is considerably more accurate than simply saying:

"The API key leaked, therefore the attacker could access the system."

We do not have enough evidence to make that conclusion.

---

8. But the VPS claim needs some technical context

Misi Rakyat says the party involved used a VPS to conceal its real identity.

Technically, a VPS can certainly be used as an intermediary to conceal the origin of activity.

But:

using a VPS is not, by itself, evidence of malicious intent.

VPS infrastructure is also routinely used by:

• security researchers;
• penetration testers;
• developers;
• automation systems;
• crawlers;
• CI/CD infrastructure;
• attackers.

The more useful evidence would be what happened from that infrastructure.

For example:

source IPs
timestamps
request logs
user agents
authentication attempts
attack paths
payloads
exploit signatures
correlated events

Those provide considerably stronger evidence than simply identifying a VPS.

---

9. The alleged motive is also still an assessment

Misi Rakyat says it believes the purpose was not to sell user data, but to damage the company's reputation.

That may be correct.

But this is an assessment of motive, rather than an independently established fact.

In forensic investigations, I prefer to separate:

Observed behaviour
        |
        v
Technical evidence
        |
        v
Attribution
        |
        v
Motive

The further down the chain we go, the more evidence is generally required.

We can observe malicious activity without knowing who performed it.

We can identify infrastructure without knowing who controlled it.

And even if an operator is identified, determining their actual motive can still require additional evidence.

So the motive described by Misi Rakyat should currently be treated as the company's assessment.

---

10. What about the suspicious website?

Misi Rakyat has also warned users not to enter personal information into a website it says is unrelated to the company.

The warning itself is reasonable.

However, the fact that a website is not "regulated by an authority" does not, by itself, establish that the website is malicious.

The stronger question is:

What does the website actually do?

For example:

Does it request a Misi Rakyat password?
Does it request an OTP?
Does it request an identity-card number?
Does it request payment information?
Does it transmit credentials elsewhere?
Does it impersonate Misi Rakyat?

Those behaviours would provide substantially stronger evidence of phishing or malicious data collection.

---

11. There is also historical context

This is not the first time Misi Rakyat has faced public scrutiny over alleged data leakage.

In July 2023, the Personal Data Protection Department (JPDP) investigated allegations of personal-data leakage involving Misi Rakyat.

The Sun and The Star reported that JPDP received a report from MyCERT on 4 July 2023, contacted Bangsa Bertauhid Sdn. Bhd. for confirmation and data samples, and instructed the company to conduct an internal investigation and complete a Data Breach Notification form.

The company's founder was also called for a statement, while JPDP worked with CyberSecurity Malaysia during the investigation.

That history is relevant when looking at the 2026 incident.

But we should not automatically assume that the 2026 incident is a continuation of the 2023 incident.

There is currently no sufficient public evidence to establish that connection.

The relationship could be:

2023 incident
      |
      X
      |
2026 incident

or:

2023 incident
      |
      ?
      |
2026 incident

That connection needs evidence.

It should not be assumed.

---

12. From an incident-response perspective, several of Misi Rakyat's stated actions make sense

The new statement says the company has:

• tightened access controls;
• reviewed and updated system credentials;
• strengthened encryption;
• increased security monitoring;
• investigated suspicious activity;
• preserved evidence;
• cooperated with authorities;
• initiated notification processes with JPDP.

These are all reasonable components of a security incident response.

But there is an important caveat:

these are actions reported by Misi Rakyat itself.

They are not independent forensic findings.

---

13. The JPDP notification is particularly significant

Misi Rakyat's reference to JPDP also has a clear regulatory context.

Malaysia's current Personal Data Protection framework includes a formal Data Breach Notification mechanism.

JPDP's DBN process requires organisations to provide information such as:

• when the breach was discovered;
• how it was detected;
• whether personal data was accessed without authorisation;
• whether data was exfiltrated;
• suspected cause;
• affected systems;
• categories of affected data;
• number of affected data subjects;
• risks to data subjects;
• containment and recovery measures.

Where the notification criteria are met, the framework provides for notification to the Commissioner within the prescribed timeframe, including the 72-hour requirement.

This means the statement about notifying JPDP is not merely a public-relations statement.

If the incident meets the relevant criteria, it forms part of the regulatory response.

---

14. So what is the relationship between my previous article and this statement?

The relationship can be summarised like this:

8 Sep 2026
Alleged data leak
        |
        v
Data samples + configuration
        |
        v
HEJES technical analysis
        |
        v
"Serious, but not confirmed"
        |
        v
9 Sep 2026
Misi Rakyat statement
        |
        +--> acknowledges malicious cyber activity
        |
        +--> says attacker used VPS infrastructure
        |
        +--> says evidence has been preserved
        |
        +--> says analysed application was an old version
        |
        +--> says keys/configuration were rotated
        |
        +--> says no suspicious activity has been detected
        |
        +--> says JPDP notification process is underway

The new statement therefore reduces one area of uncertainty:

Does Misi Rakyat itself consider there to have been malicious cyber activity?

Now we have an answer:

Yes.

But several questions remain unanswered:

Was the leaked dataset obtained through that attack?

Which system produced the dataset?

Was the production database actually accessed?

Was data exfiltrated?

When was the data obtained?

Is there a relationship between the 2023 and 2026 incidents?

Were any credentials found in the leaked material actually used by the attacker?

What was the actual attack vector?

Those questions remain open.

---

15. What should happen to the original HEJES article?

I would not rewrite the original article as if it never existed.

The article represents the evidence state on 8 September.

Instead, add an update notice at the top.

Something like:

Update — 9 September 2026: Misi Rakyat has now issued an official statement describing the activity as a malicious cyberattack targeting the company. Misi Rakyat also states that the application analysed was an older version and that associated credentials and configurations have been updated. This changes the status of some claims from "under investigation" to "acknowledged malicious cyber activity", but the statement does not publicly establish that the entire leaked dataset was obtained through a compromise of the company's production database.

This preserves the historical record while keeping the article current.

---

16. My conclusion

The most interesting part of this incident is not simply:

"Misi Rakyat was hacked."

That is too simplistic.

The more important issue is the gap between three things:

What was leaked
       +
What can be technically analysed
       +
What the organisation confirms

On 8 September, those three layers did not fully overlap.

On 9 September, Misi Rakyat confirmed that it considers itself the target of a malicious cyberattack.

But there is still not enough publicly available evidence to conclude:

"The leaked dataset was definitely obtained through a compromise of Misi Rakyat's production database."

That is the boundary I would still maintain.

And maintaining that boundary does not mean defending Misi Rakyat.

It does not mean accusing them either.

It means separating:

claims, evidence and conclusions.

Misi Rakyat is entitled to provide its account of the incident.

Security researchers are entitled to examine the technical evidence.

And readers deserve to know which statements are:

confirmed, claimed, observed, or still unknown.

That distinction is the most important part of this story.

Sources

• Misi Rakyat official statement, 9 September 2026 — primary source provided for this analysis (company claims reported as attributed throughout; no public URL available at time of writing).
• HEJES previous analysis: "Misi Rakyat Data Leak: What the Leaked Samples Actually Reveal".
• The Sun and The Star reporting on the 2023 JPDP investigation into alleged Misi Rakyat personal-data leakage.
• JPDP Data Breach Notification Guideline (notification criteria, 72-hour timeframe, DBN form and process).

Sources

• HEJES.MY: Misi Rakyat Data Leak: What the Leaked Samples Actually Reveal
• The Sun Malaysia: JPDP investigating alleged hacking of Misi Rakyat website
• The Star: JPDP to investigate alleged hacking incident on local Misi Rakyat website
• PDPC Malaysia: Data Breach Notification Guideline