Ripio

Ripio HackerOne Program - Scope & Exclusions Policy (Logic-Based)

To ensure clear communication and efficient triage, we have defined our scope using strict logic-based rules. Please review these exclusions carefully before submitting.

🏆 ATO Challenge (Special Bounty: $6,000)

Objective: Demonstrate a full Account Takeover by bypassing authentication mechanisms, specifically bypassing 2FA, to obtain a valid user session and perform a critical action.

• Target User: [email protected]
• Password: Sup3rs3cr3t!
• Required Proof: You must demonstrate access to Sensitive Information Disclosure, Wallet Balance, or perform a Minimal Transfer. Merely logging in is not enough if the session is restricted.
• Security Controls: 2FA is ENABLED. You must bypass it.
• Constraint: The email provider itself (@gmail.com) is Out-of-Scope. Do not attempt to compromise the Google account to read codes.
• Prohibited: Brute force attacks and Social Engineering are strictly prohibited.

✅ Qualifying Vulnerabilities (Focus Areas)

While we welcome all valid security vulnerabilities, we are specifically interested in:

📱 Mobile Specific

• Insecure Data Storage: Sensitive data (PII, Credentials) stored in plain text (SharedPrefs, SQLite, External Storage).
• Deep Link / Intent Hijacking: Malicious intents leading to Account Takeover or Sensitive Action execution.
• Biometric Bypass: Bypassing local authentication mechanisms.
• Hardcoded Secrets: Valid API Keys or Credentials found in the binary (must be verified).

🌐 Web & API

• Business Logic Errors: Payment manipulation, unauthorized transfers.
• Broken Access Control: IDOR, Privilege Escalation.
• Injection: SQLi, RCE.

🚫 Hard Exclusions (Auto-Close Rules)

Reports falling into these categories will be closed as N/A (Not Applicable) immediately. We do not accept theoretical arguments for these issues.

Attack Vector Constraints

• Physical & Local Access: Any attack requiring physical access to the victim's device or access to the victim's local network (e.g., MITM, local malware, self-installed certificates).
• Social Engineering: Phishing, Vishing, Smishing, or any attack relying on deceiving employees or users.
• Denial of Service (DoS/DDoS): Any activity that disrupts, degrades, or interrupts service availability.
• Brute Force: Repetitive automated attempts against authentication endpoints.
• Third-Party Flaws: Vulnerabilities in 3rd party providers or integrations, unless they directly compromise Ripio data/infrastructure.

Infrastructure & Configuration

• SSL/TLS Configuration: Missing security headers (HSTS, HPKP), weak ciphers, or certificate issues.
• Email Security Records: Missing or incomplete SPF, DMARC, or DKIM records.
• Information Disclosure (Low Impact):
  • Verbose error messages or stack traces (unless they contain sensitive PII/Credentials).
  • Server banner grabbing / Version disclosure.
  • Publicly accessible files (robots.txt, readme.md, WordPress files) without sensitive data.
• CORS: Cross-Origin Resource Sharing issues without a working PoC demonstrating sensitive data exfiltration.
• COOP: Cross-Origin Opener Policy issues without a working PoC demonstrating sensitive data exfiltration.
• COEP: Cross-Origin Embedder Policy issues without a working PoC demonstrating sensitive data exfiltration.

⚠️ Conditional Exclusions (Proof Required)

These issues are considered N/A UNLESS the specific condition described below is met and demonstrated in the Proof of Concept.

XSS & Client-Side Attacks

• Reflected XSS:
  • Rule: Conditional Exclusion. Reports showing only alert(1) or non-sensitive DOM manipulation are N/A.
  • Exception: Valid ONLY if you demonstrate Account Takeover or Sensitive Action Execution via a clickable link or iframe (e.g., stealing a session token, bypassing CSRF to change email). The impact must be proven, not theoretical.
• Self-XSS:
  • Rule: Out-of-Scope if it requires the user to paste code into the console or address bar.
  • Exception: Valid ONLY if chained with another vulnerability (e.g., CSRF) to execute without user self-sabotage.
• Clickjacking:
  • Rule: Strictly Out-of-Scope on pages without sensitive state-changing actions (e.g., Login, Logout, Static Content).
  • Exception: Valid ONLY if you demonstrate a critical state change (e.g., Transfer Funds, Delete Account, Authorize App).
• Cookie Flags:
  • Rule: Missing Secure or HttpOnly flags are N/A.
  • Exception: Valid ONLY if you provide a working PoC that exploits this specific lack of protection.

Mobile & Native Apps

• Obfuscation / Binary Protection:
  • Rule: Lack of obfuscation, anti-debugging, or binary protection is N/A.
  • Exception: Valid ONLY if you can reverse engineer hardcoded secrets (API Keys, Credentials) that grant unauthorized access.
• SSL Pinning / Root Detection:
  • Rule: Bypassing client-side controls (Pinning, Root/Jailbreak detection) on your own device is N/A.
  • Exception: Valid ONLY if the bypass allows server-side exploitation that affects other users.
• Local Data Leaks (Snapshots/Pasteboard):
  • Rule: Application snapshots or keyboard cache/pasteboard leakage are N/A.
  • Exception: Valid ONLY if it exposes high-impact sensitive data (e.g., Credit Card numbers, Passwords) in a shared context.
• Tapjacking / Overlay Attacks:
  • Rule: N/A by default.
  • Exception: Valid ONLY if on a critical sensitive action (e.g., Confirm Transfer) with no other confirmation step.

🧪 Test Plan & Rules

• Header: Include X-H1-traffic: <username> in all requests.
• Accounts: Use your @wearehackerone.com alias.
• Unrelated Issues vs. Exploit Chains:
  • Do not group unrelated vulnerabilities in a single report.
  • Exception: You MUST chain vulnerabilities if necessary to demonstrate impact (e.g., chaining Self-XSS with CSRF). This is considered a single "Exploit Chain".
• Safe Harbor: Activities conducted consistent with this policy are authorized. We will not initiate legal action against you.

🤐 Disclosure Policy

• Default: This program follows HackerOne's Coordinated Disclosure Policy.
• Public Disclosure: We generally agree to public disclosure after a fix has been deployed and verified.
• Mutual Agreement: Requests for disclosure will be reviewed on a case-by-case basis. Do not disclose any details publicly without our explicit written consent.

📝 Submission Quality Standards

To help us validate your report faster:

1. Structured Steps: Use the numbered steps in the submission form. Do not write paragraphs.
2. Video PoC: Highly recommended for complex UI bugs.

🌉 Web3 / Smart Contracts Scope

Ripio's Web3 program covers the WFIAT wrapped-fiat stablecoin contracts (wARS, wMXN, wBRL, wCOP, wCLP, wPEN, USDar), the LimitedMinter contracts, and the associated cross-chain bridge infrastructure. Only the addresses listed in the table below are in scope. Any other contract deployed by Ripio and not included here is considered out of scope.

Important — Upgradable Contracts: WFIAT token contracts are upgradable and use the UPGRADER_ROLE access-control role. "In scope" refers to the current implementation deployed to the proxy addresses listed below. Vulnerabilities found in prior implementations that have already been upgraded out are not eligible for a reward. Researchers should verify the implementation currently pointed to by each proxy at submission time.

Canonical WFIAT Contract Addresses

All WFIAT token contracts share the same address across chains (CREATE2 deployment). Verify each contract on the block explorer corresponding to the target network.

Token Contracts (same address across all listed chains)

Cross-Chain Bridge Infrastructure (same address across all listed chains)

LimitedMinter (address varies by chain)

Chain IDs (EIP-155): Ethereum 1 · Base 8453 · World Chain 480 · Gnosis 100 · BNB Smart Chain 56 · Polygon 137

Ripio Web3 Severity & Reward Schedule

Rewards for Web3 findings are determined by the business and financial impact of the vulnerability, evaluated by Ripio on a case-by-case basis. The schedule below represents maximum rewards; the final amount depends on exploit feasibility, proof-of-concept quality, and the scope of affected users or funds.

✅ Qualifying Web3 Vulnerabilities

Severity is assigned by demonstrated impact, not by vulnerability class.

Critical (Smart Contracts)

• Direct theft of user funds held by the contract, whether at rest or in transit
• Unauthorized minting of WFIAT tokens beyond the intended supply mechanism or beyond the daily limits enforced by the LimitedMinter
• Unauthorized burning of another user's token balance
• Permanent freezing of user funds with no admin recovery path
• Protocol insolvency or accounting errors resulting in value loss for users
• Bypass of access controls (DEFAULT_ADMIN_ROLE, MINTER_ROLE, PAUSER_ROLE, UPGRADER_ROLE) leading to any of the above
• Cross-chain bridge exploits resulting in double-minting, theft of deposits, or unauthorized withdrawal

High (Smart Contracts)

• Theft or permanent freezing of protocol-owned funds
• Temporary freezing of user funds for a material duration (> 1 hour)
• Bypass of access controls without direct fund impact, where the bypass produces a configuration change affecting a listed in-scope contract, its supply, or other users' funds (e.g., altering the daily mint limit, mint destination, or registry entry of a listed WFIAT token). A bypass whose only effect lands on attacker-supplied or attacker-deployed contracts — including registry entries keyed on a contract the researcher deployed — does not qualify; see Web3-Specific Hard Exclusions below.

Medium (Smart Contracts)

• Griefing attacks with demonstrable damage to users or the protocol but no profit motive for the attacker
• Unbounded gas consumption reachable by arbitrary callers
• Theft of gas or forced-transaction revert denial-of-service

Low (Smart Contracts)

• Edge cases where the contract fails to deliver expected behavior without direct value loss

Web / dApp — bridge.ripio.com

• Critical: arbitrary transaction signing from connected wallets without user consent; mass account takeover; exfiltration of private keys or seed phrases
• High: execution of arbitrary JavaScript in the dApp origin with account-takeover impact; subdomain takeover chained to wallet interaction
• Medium: CSRF or authenticated state-changing flaws with limited impact; sensitive data disclosure (non-secret but material)

🚫 Web3-Specific Hard Exclusions

In addition to the program-wide exclusions, the following are considered N/A by default for Web3 assets:

Smart Contracts

• Issues documented in any audit report attached to this program — findings Ripio has accepted as residual risk are not eligible
• Centralization risks inherent to the design: admin keys, pausable roles, upgradable proxies, mint/burn permissions held by privileged accounts, and multisig-controlled operations are accepted design choices
• Gas optimization suggestions with no security impact
• Best-practice violations without a demonstrated exploit (missing events, floating pragma, naming conventions, unused code)
• Compiler bugs in mainstream Solidity versions
• MEV, frontrunning, and sandwich attacks — these are inherent to public blockchains and are not considered vulnerabilities
• User-configurable slippage losses
• Oracle price deviations within the tolerance thresholds documented by the oracle provider
• Theoretical reentrancy without a working PoC exploiting actual state changes
• Attacks requiring compromised admin or multisig keys — key compromise is a governance matter, not a smart-contract vulnerability
• Bugs in third-party libraries (OpenZeppelin contracts, standard token implementations) unless Ripio's specific integration or customization introduces the vulnerability
• Registry pollution with attacker-supplied contracts — reports whose demonstrated end state is the creation, mutation, or non-removability of LimitedMinter / LimitedMinterBridge tokenConfigs entries keyed on a contract the researcher deployed. This includes the onlyExternalAdmin(address token) pattern delegating its role lookup to the caller-supplied token address. Minting of any listed WFIAT token is gated independently by MINTER_ROLE on that token contract, not by tokenConfigs, and entries keyed on real WFIAT addresses cannot be created or altered by unprivileged callers. Ripio tracks this as an accepted defense-in-depth item. To qualify, a report must demonstrate an effect on a listed contract's configuration, supply, or user balances.

Web / dApp

• Issues caused by the user's wallet provider (MetaMask, WalletConnect, Ledger, etc.)
• Lookalike or phishing domains — report to the domain registrar / provider
• Frontend-only issues (missing headers, cosmetic UI) without on-chain or wallet impact

🧪 Web3 Testing Rules

• No testing on mainnet or public testnets is permitted. All proofs of concept must be reproducible on a local fork using tools such as Foundry, Hardhat, Anvil, or Tenderly.
• Flash-loan simulations are allowed on local forks.
• Do not interact with production contracts in ways that could affect real user funds or protocol state. Do not attempt to front-run, extract value from, or manipulate production; such activities are considered attacks, not research, and fall outside Safe Harbor.
• A runnable PoC is mandatory for all Web3 submissions (Foundry test, Hardhat script, or equivalent). Reports without a working PoC will be closed as Not Applicable.
• PoCs must include: affected contract and function references, the exploit transaction sequence, and the on-chain state changes demonstrating impact. ⭐️

💰 Payout Conditions

• Payouts are processed via HackerOne in USD.
• KYC may be required for payouts exceeding $500, following HackerOne's standard flow.
• Vulnerabilities previously documented in audit reports attached to this program — whether fixed, in progress, or accepted as residual risk — are not eligible for a reward.