Kebocoran Data Misi Rakyat: Apa Yang Sebenarnya Didedahkan

Kebocoran Data Misi Rakyat: Apa Yang Sebenarnya Didedahkan

Pada awal September 2026, dakwaan mengenai kebocoran data Misi Rakyat mula tersebar online.

Angka yang disebut memang besar: 300,518 rekod pelanggan dan kira-kira 1.88 juta rekod transaksi. Angka tersebut dilaporkan sebagai sebahagian daripada dakwaan bahawa database Misi Rakyat telah diperoleh dan ditawarkan untuk dijual. Laporan The Rakyat Insight mengenai dakwaan 300,000 data pelanggan dan 1.88 juta transaksi Kosmo — Misi siasat dakwaan kebocoran data lebih 300,000 pelanggan

Tapi terus terang, angka itu bukan perkara yang paling menarik bagi aku.

Aku lebih berminat dengan struktur data yang tersebar.

Daripada sample yang aku semak, data tersebut didakwa merangkumi customer, rider dan vendor. Ada juga configuration material yang merujuk kepada infrastructure aplikasi Misi Rakyat.

Kalau sample itu genuine, ini bukan lagi sekadar cerita pasal nama dan nombor telefon.

Tapi ada satu perkara yang perlu jelas dari awal.

Misi belum mengesahkan dataset tersebut genuine.

Pada 8 September, pengasas Misi, Nur Ahmad Faiz Mohd Azmi, berkata pasukan cybersecurity syarikat telah memulakan siasatan dalaman untuk mengesahkan dakwaan tersebut dan menentukan sama ada berlaku unauthorized access terhadap sistem mereka. Misi turut berkata mereka sedang berhubung dengan pihak berkuasa berkaitan. Kenyataan Misi mengenai siasatan dalaman — Siakap Keli

Jadi buat masa ini, aku akan panggil ini sebagai:

Dakwaan data leak yang sedang disiasat.

Bukan confirmed breach.

Perbezaan itu penting.

---

Apa yang ada dalam sample?

Salah satu sample customer yang aku semak mengandungi field seperti:

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

Kalau field-field ini memang datang daripada dataset sebenar, sensitivity dia jauh lebih tinggi daripada contact list biasa.

Bayangkan satu record yang mempunyai:

name
email
phone
address
latitude
longitude

Kita bukan lagi bercakap tentang seseorang yang boleh dihubungi.

Data itu berpotensi menghubungkan identity seseorang dengan lokasi fizikal.

Yang aku rasa menarik ialah kewujudan dua jenis location information.

Ada profile location.

Ada pula address location.

Itu nampak macam application memang menyimpan konteks lokasi yang berbeza — contohnya lokasi profile dengan delivery address.

Ini salah satu sebab kenapa sample itu nampak lebih seperti application data model berbanding data yang sekadar dikumpulkan daripada public sources.

Source: sample data yang disemak oleh author. Authenticity sample masih belum disahkan secara independent.

---

Data rider pula lebih sensitif

Bahagian rider lebih menarik.

Antara field yang muncul dalam sample:

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

Kalau data ini genuine, ia merangkumi lebih daripada customer information.

Ada identity.

Ada employment information.

Ada vehicle information.

Ada licensing information.

Ada operational information.

Ada location dan performance data.

Yang paling menarik perhatian aku ialah:

rider_ic

Kewujudan field seperti ini jauh lebih sensitif daripada sekadar username atau email.

Tapi aku nak tekankan satu benda.

Ada field rider_ic dalam sample tidak bermaksud setiap nilai dalam field itu sudah terbukti genuine.

Kita masih perlukan verification.

Dalam security analysis, schema dan value ialah dua benda berbeza.

Schema boleh nampak sangat real.

Itu belum cukup untuk membuktikan semua records di dalamnya authentic.

Source: sample data yang disemak oleh author; authenticity belum disahkan secara independent.

---

Vendor pula buka cerita lain

Sample vendor pula mengandungi field seperti:

vendor_name
type
bank_account_holder_name
bank_account_number
bank_swift_code
phone_number
phone_normalized
location
state

Ada juga row yang kelihatan seperti mengandungi Malaysian bank account information dan SWIFT/BIC.

Kalau betul, ini sudah masuk kepada financial information exposure.

Tapi jangan campurkan dua perkara:

database ada bank account number

dengan

banking system telah compromised.

Itu bukan benda yang sama.

Kalau nombor akaun vendor berada dalam database Misi, ia tidak bermaksud attacker telah masuk ke sistem bank.

Itu cuma bermaksud maklumat itu mungkin telah exposed daripada sistem yang menyimpannya.

Source: sample data yang disemak oleh author; authenticity dan provenance belum disahkan secara independent.

---

Kemudian ada .env

Ini antara bahagian yang paling menarik dari sudut technical analysis.

Dalam material yang tersebar, terdapat configuration sample yang didakwa berkaitan dengan aplikasi:

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]

Aku sengaja tak letakkan actual secret value.

Tak ada sebab untuk publish credential orang lain semata-mata nak membuktikan kita jumpa benda itu.

Apa yang menarik ialah configuration itu memberikan petunjuk tentang application endpoints dan third-party services yang digunakan.

Tapi .env yang bocor tidak automatik bermaksud semua value di dalamnya ialah production secrets.

Ia juga tidak memberitahu kita sama ada key itu masih aktif ketika material itu tersebar.

Untuk tahu perkara itu, kita perlukan verification daripada system owner atau provider yang berkaitan.

Source: configuration sample yang disemak oleh author. Nilai credential sengaja diredact.

---

SECRET_KEY bukan bermaksud attacker boleh terus login

Ini antara perkara yang paling senang disalah faham.

Nampak:

SECRET_KEY

terus ramai akan fikir:

“Habis. Boleh login sebagai semua orang.”

Belum tentu.

Nama variable sahaja tak cukup untuk mengetahui capability sesuatu secret.

Bergantung kepada implementation, ia mungkin digunakan untuk:

• session signing
• JWT signing
• token generation
• application-level cryptography
• fungsi security yang lain

Kalau secret itu digunakan untuk sign authentication token, memang impact boleh jadi serius.

Kalau ia digunakan untuk fungsi lain yang tidak berkaitan dengan authentication, ceritanya mungkin berbeza.

Soalan sebenar bukan:

“Ada SECRET_KEY?”

Soalan sebenar ialah:

“Application guna secret itu untuk apa?”

Itu yang perlu disiasat.

---

API key pun sama

Configuration itu turut mengandungi API key yang kelihatan berkaitan dengan third-party feedback service.

API key tidak semestinya mempunyai capability yang sama.

Benda yang perlu diperiksa ialah:

Masih aktif?
Scope apa?
Read access?
Write access?
Delete access?
Production atau test?
IP restricted?

Tanpa maklumat itu, kita tak boleh terus kata:

“API key bocor = semua data third-party service boleh diakses.”

Itu terlalu jauh.

Capability lebih penting daripada kewujudan key itu sendiri.

---

Radar key nampak berbeza

Satu lagi key yang muncul dalam configuration ialah Radar key yang kelihatan seperti test/publishable key.

Kalau memang publishable client-side key dan berada dalam test environment, risk profile dia tidak sama dengan private server credential.

Ini contoh kenapa security analysis tak boleh berhenti pada:

“Ada key bocor.”

Kita kena tengok:

Key itu boleh buat apa?

Kalau capability dia rendah, impact mungkin rendah.

Kalau private credential dengan broad permissions, cerita lain.

Source: configuration sample yang disemak oleh author. Classification sebagai test/publishable dibuat berdasarkan format key yang kelihatan dan masih perlu disahkan oleh provider.

---

Struktur data nampak macam application export

Ini mungkin antara clue yang lebih menarik.

Bila tengok customer, rider dan vendor secara berasingan, setiap dataset mempunyai struktur yang agak konsisten.

Customer mempunyai profile dan address fields.

Rider nampak macam mempunyai additional fields yang berkait dengan user itu.

Vendor pula menggunakan model berbeza tetapi masih structured.

Antara field yang muncul termasuk:

entity_type
user_id
rider_id
current_zone_id
vendor_name_matched

Sebab itu aku lebih cenderung melihat material ini sebagai sesuatu yang menyerupai application-level export berbanding koleksi data rawak daripada public sources.

Tapi sekali lagi:

Ini bukan bukti bagaimana data itu diperoleh.

Ia cuma memberi beberapa kemungkinan.

Contohnya:

• database export
• backup exposure
• compromised application environment
• privileged account access
• third-party system
• sumber dalaman lain

Tanpa logs atau forensic evidence, kita tak boleh pilih satu scenario dan panggil ia fakta.

---

CSV yang tukar nombor kepada scientific notation

Ada satu lagi benda kecil tetapi menarik.

Sesetengah nilai yang kelihatan seperti bank account number dalam CSV muncul dalam bentuk:

1.13E+14
1.63E+11

Ini boleh berlaku apabila data dibuka atau diproses menggunakan spreadsheet software.

Nombor yang panjang kadang-kadang dipaparkan sebagai scientific notation.

Jadi perkara ini mungkin tidak banyak memberitahu kita tentang database asal.

Sebaliknya, ia mungkin memberi clue tentang bagaimana leaked file itu pernah diproses.

Sebab itu original artifact penting.

Kalau yang kita ada cuma CSV yang sudah beberapa kali dibuka, disimpan dan ditukar format, sebahagian metadata asal mungkin sudah hilang.

---

Jadi, apa yang kita tahu?

Setakat material yang ada sekarang, aku akan pisahkan macam ini:

Aku sengaja buat distinction ini.

Sebab dalam security, “nampak real” dan “telah disahkan” bukan benda yang sama.

---

Jadi data ini datang dari mana?

Buat masa ini, kita boleh fikirkan beberapa kemungkinan.

Database compromise

Attacker mungkin mendapat access kepada database dan membuat export.

Kalau itu berlaku, struktur data yang kita nampak memang masuk akal.

Tapi kita perlukan database atau access logs untuk mengesahkannya.

Backup exposure

Mungkin bukan live database pun.

Ia boleh jadi backup yang tersimpan dalam cloud storage, server, CI/CD artifact atau tempat lain yang tidak sepatutnya accessible.

Backup yang terdedah boleh menghasilkan dataset yang sangat lengkap tanpa perlu attacker exploit database secara direct.

Application/server compromise

Kalau seseorang mendapat access kepada application environment, mereka secara teori boleh mendapat kedua-dua application data dan configuration.

Ini menjadi lebih menarik jika .env itu memang datang daripada environment yang sama.

Tetapi sekali lagi, itu masih hypothesis.

Third-party exposure

Ada kemungkinan sebahagian data pernah dihantar kepada vendor atau third-party integration.

Kalau begitu, source sebenar mungkin bukan Misi production database.

Untuk tahu, struktur leaked dataset perlu dibandingkan dengan data yang memang dihantar kepada third parties.

Dataset palsu atau sebahagiannya dimanipulasi

Kemungkinan ini pun tak boleh diketepikan.

CSV yang nampak sangat meyakinkan masih bukan cryptographic proof bahawa database breach berlaku.

Sebab itu independent verification penting.

---

Apa yang boleh mengesahkan kes ini?

Kalau nak move daripada speculation kepada evidence, beberapa benda akan sangat membantu.

Antaranya:

1. Hash untuk archive asal.
2. Metadata daripada database export.
3. Timestamp dalam dataset.
4. Sample records yang boleh disahkan oleh Misi.
5. Confirmation bahawa supposedly current records memang wujud dalam live system.
6. Server dan database logs.
7. API access logs.
8. Cloud atau object-storage logs.
9. CI/CD artifact history.
10. Authentication dan token issuance logs.

Satu contoh evidence yang sangat kuat ialah controlled verification.

Contohnya, Misi mengambil satu random record daripada dataset itu dan mengesahkan:

“Record ini memang wujud dalam internal database kami.”

Kalau ada timestamp atau metadata yang sepadan sekali, lagi kuat.

Pada masa itu barulah perbincangan mula bergerak daripada:

“Ada orang claim database Misi bocor.”

kepada:

“Ada evidence bahawa data itu memang berasal daripada sistem Misi.”

---

Ini bukan kali pertama nama Misi Rakyat muncul dalam isu data

Ada historical context yang patut disebut.

Pada Julai 2023, Jabatan Perlindungan Data Peribadi (JPDP) mengumumkan bahawa ia sedang menyiasat dakwaan insiden ketirisan data peribadi melibatkan laman web Misi Rakyat milik Bangsa Bertauhid Sdn. Bhd.

JPDP berkata ia menerima laporan insiden ketirisan daripada MyCERT pada 4 Julai 2023. Pada hari yang sama, JPDP menghubungi syarikat itu untuk mendapatkan pengesahan mengenai insiden dan sample data yang terlibat. JPDP turut mengarahkan syarikat menjalankan siasatan dalaman dan melengkapkan borang Data Leakage Notification (DBN). Pengasas Misi Rakyat juga dipanggil untuk prosedur rakaman percakapan. Laporan RTM mengenai siasatan JPDP terhadap Misi Rakyat pada 2023

Perkara itu bukan sekadar muncul dalam laporan media.

Dalam Hansard Dewan Negara bertarikh 31 Julai 2024, insiden ketirisan data Misi Rakyat pada tahun sebelumnya turut disebut ketika perbahasan mengenai perlindungan data peribadi. Hansard Dewan Negara, 31 Julai 2024

Tapi aku tak akan campurkan incident 2023 dengan dakwaan 2026.

Setakat evidence yang aku ada sekarang, tak ada bukti yang menghubungkan sample 2026 dengan incident 2023.

Mungkin berkaitan.

Mungkin juga langsung tak berkaitan.

Kalau ada orang kata dataset 2026 sebenarnya cuma data lama yang dikitar semula, dia juga perlu tunjuk evidence.

Buat masa ini, incident 2023 lebih sesuai dianggap sebagai historical context, bukan explanation untuk dataset yang sedang tersebar sekarang.

---

Apa pengguna patut buat?

Sementara siasatan masih berjalan, pengguna patut anggap contact information yang mungkin terdedah sebagai sesuatu yang berpotensi digunakan untuk phishing atau impersonation.

Misi sendiri meminta pengguna berhati-hati dengan panggilan, email dan mesej mencurigakan yang mendakwa datang daripada Misi, serta tidak berkongsi maklumat peribadi atau password. Kenyataan Misi mengenai langkah berjaga-jaga pengguna — Siakap Keli

Kalau kau pernah guna Misi:

• Jangan beri OTP kepada sesiapa.
• Jangan beri password melalui phone atau chat.
• Jangan klik account-recovery atau payment link yang tiba-tiba muncul.
• Kalau caller tahu nama, nombor telefon atau delivery address kau, jangan terus anggap dia memang daripada Misi.
• Gunakan password yang unik untuk setiap service.

Phishing selepas data leak kadang-kadang lebih berbahaya daripada leak itu sendiri.

Attacker tak semestinya perlukan password kau daripada database.

Kadang-kadang mereka cuma perlukan cukup maklumat untuk nampak convincing.

---

Kalau .env itu genuine, operator kena buat lebih daripada delete file

Ini bahagian yang lebih practical untuk operator.

Kalau configuration itu memang berasal daripada production environment, credential-like values yang mungkin telah exposed patut dianggap compromised sehingga dibuktikan sebaliknya.

At minimum:

• rotate application secrets
• revoke exposed API keys
• invalidate sessions jika signing material terlibat
• review authentication logs
• review API access logs
• check CI/CD variables
• check build artifacts
• search Git history
• review backup storage
• check object storage permissions
• review third-party integrations
• audit access permissions
• verify separation antara test dan production

Dan satu perkara yang selalu orang terlepas:

Kalau secret pernah masuk Git, delete daripada latest commit tidak cukup.

Secret itu mungkin masih ada dalam:

Git history
fork
clone
CI artifact
cache
backup

Sebab itu secret perlu di-rotate, bukan sekadar dipadam.

---

Kesimpulan

Bagi aku, bahagian paling menarik dalam kes ini bukan angka 300,518.

Ia ialah berapa luas data model yang kelihatan dalam sample.

Secara kasar, material itu kelihatan merangkumi:

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

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

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

Kemudian ada pula configuration material yang merujuk kepada application endpoints dan third-party services.

Kalau semua ini disahkan sebagai genuine dan current, impact dia memang jauh lebih besar daripada sekadar “phone number leak”.

Tapi kita belum sampai tahap itu.

Setakat 8 September 2026, Misi masih menyiasat dakwaan itu dan belum mengesahkan unauthorized access atau kesahihan keseluruhan dataset. Laporan siasatan Misi — Siakap Keli, 8 September 2026

Jadi kesimpulan aku buat masa ini mudah:

Sample ini cukup serius untuk disiasat. Tetapi kita masih belum mempunyai bukti awam yang cukup untuk mengatakan dengan pasti bagaimana data itu diperoleh atau bahawa production system Misi telah compromised.

Itu beza antara buat security analysis dengan sekadar ikut headline.

Artikel ini sengaja tidak menerbitkan password, API credentials, identity numbers, nombor akaun bank, alamat, coordinates atau maklumat sensitif lain daripada material yang tersebar.

Sources

• Siakap Keli — Dakwaan Kebocoran Data, Misi Jalankan Siasatan Dalaman
• Kosmo — Misi siasat dakwaan kebocoran data lebih 300,000 pelanggan
• RTM — Kebocoran data peribadi: JPDP siasat laman sesawang Misi Rakyat
• Hansard Dewan Negara, 31 Julai 2024 — Parlimen Malaysia
• The Rakyat Insight — 300,000 Data Pelanggan, 1.88 Juta Transaksi Misi Rakyat Didakwa Dijual

Sumber

• 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 Julai 2024