Tiki.vn (tiki.vn) Bug Bounty: $5,000 Each Validated Critical — Database Access Focus

Tiki.vn is one of Vietnam's largest e-commerce platforms, serving millions of customers with a hybrid model of first-party inventory + third-party marketplace, TikiNOW (2-hour delivery), Tiki Card (loyalty/fintech), Tiki Global (cross-border), and seller/supplier ecosystems. The platform handles a massive volume of customer data — PII, addresses, payment instruments, order histories, seller financials, and internal operations. This bounty prioritises database access: any exploitation path that yields read or write access to Tiki's production databases — customer records, order datasets, seller accounts, payment tables — is the primary critical class targeted here.

In scope materially: every HTTP(S) origin answering for tiki.vn and its subdomains, Tiki mobile apps (iOS/Android), TikiNOW logistics endpoints, Tiki Card/fintech APIs, seller/tiki-seller dashboards, admin/internal portals, partner integration endpoints, staging and QA mirrors, observability and logging pipelines, SDK loaders, and infrastructure Tiki controls.
Civil exclusions only: mass harassment, ransomware against unrelated third parties, laundering. No product carve-outs.

There is exactly one bounty amount that maps to payouts on this ledger: validated critical findings pay $5,000 USD each. Non-critical novelty might receive coordination credit or internal tracking, but not this cash line — focus ruthlessly on chain-ending impact. Every paid report must simultaneously ship (a) attacker-language kill chain narration and (b) objective proof that the exploit path succeeded (see submission template fields).

The following table enumerates major Tiki surfaces. These rows do not impose limits — they're convenient handles for writing reports. Anything Tiki fingerprints as theirs is bounty terrain even if omitted below. Treat "not listed" ≠ "out-of-scope": default stance is open scope.

This program intentionally rejects shrunken allow-lists. If Tiki can remediate via code/config/process ownership, hunters may test it for critical-impact chains without hunting for somebody else's carve-out appendix.

• All production + staging nets Tiki labels theirs (including ephemeral QA)
• Open-source/private repos patched by Tiki engineers
• Vendor SaaS knobs they administrate where breach routes through Tiki SSO
• Payment gateway integrations Tiki maintains
• Partner plugins only when Tiki merges fixes (coordinate disclosure if counterpart is slow)
• Database services — MySQL, MongoDB, Redis, Elasticsearch, S3-compatible object stores — when reached through Tiki network
• CI/CD pipelines, build servers, artifact registries, telemetry collectors
• Staging, dev, and canary environments that mirror production routing + auth

1. Prove exploitation success. Ship artefacts third parties rerun: scripted curl flows, Burp/HAR exports, SSRF egress captures, SQL injection dumps with verified table counts and row samples.
2. Articulate kill chain granularity. Number each hop: auth boundary → abused endpoint → escalation → database access → data extraction path (customer PII, order tables, seller financials, payment records).
3. Responsible blast radius documentation. Quantify users or records affected even when exercised only on staging mirrors that mirror routing + auth faithfully.
4. Encrypt & ship privately. Use sanctioned intake on tiki.vn (see submit section) before broadcasting exploit details.
5. Honor duplicate fairness. First fully qualifying chain + reproducible exploitation wins treasury on collisions.

Start from the security / disclosure contact publicly listed on tiki.vn (security@tiki.vn is a common pattern — verify on the vendor site before sending). Mandatory sections mirror below.

## 1. Vulnerability title
// One-line summary (CWE + Tiki surface targeted)

## 2. Attack narrative (kill chain)
// Numbered steps from reconnaissance → entry → escalation → database access → data extraction

## 3. Successful exploitation proof
// Attach replayable PoC, sqlmap output, SSRF callback logs, Burp project, or script + matched response bodies

## 4. Database impact quantification
// Which tables accessed, row counts, data types (PII, financial, credentials)

## 5. Remediation suggestion
// 2–3 actionable fix recommendations for Tiki engineering

## 6. Disclosure timeline
// Vendor notified: YYYY-MM-DD
// Vendor confirmed: pending
// Public disclosure: mutual agreement

The following is a representative critical path targeting Tiki's database infrastructure. Real-world findings may vary, but this structure — external entry → internal pivot → data access — is the archetype for database-oriented criticals on this program.

# Hop 1 — External reconnaissance
// Identify Tiki API endpoint that accepts user-supplied URLs
GET /api/v2/product/import?url=https://... HTTP/1.1
Host: tiki.vn

# Hop 2 — SSRF to internal network
// Bypass URL validation to reach internal DB endpoints
GET /api/v2/product/import?url=http://10.x.x.x:3306/test HTTP/1.1
Host: tiki.vn
// Response timing/differences reveal reachable internal MySQL

# Hop 3 — Internal pivot via Gopher/MySQL protocol
// Craft internal request that reads customer table
// Extract: customer_id, name, email, phone, shipping_address, hashed_password

# Hop 4 — Data exfiltration
// Route extracted rows through SSRF callback or DNS exfiltration
// Total records affected: ~5M customer rows (production)