QC VDP

{
  "id": "3d6dfea5-b7f6-4bca-98a3-a1c6b8a4c7dd",
  "name": "QC VDP",
  "company_handle": "quadcode",
  "handle": "qcvdp",
  "url": "https://www.intigriti.com/programs/quadcode/qcvdp/detail",
  "status": "open",
  "confidentiality_level": "public",
  "tacRequired": false,
  "twoFactorRequired": false,
  "min_bounty": {
    "value": 0,
    "currency": "EUR"
  },
  "max_bounty": {
    "value": 0,
    "currency": "EUR"
  },
  "targets": {
    "in_scope": [
      {
        "type": "other",
        "endpoint": "Trading Scope",
        "description": "## Description\n\nA trading platform with open self-registration. This scope covers security issues affecting trading-related and billing operations — exchange, deposit, withdrawal, refund, bonuses, and identity verification (KYC).\n\n- Registration: https://eu.iqoption.com/en/register\n\n## Assets\n\n```\niqoption.com\n*.iqoption.com\n```\n\n## What this scope covers\n\nThis scope is about flaws in the **trading, payment, and verification logic itself** — business-logic, flow, and architectural issues that let a user perform monetary or verification operations which deviate from the intended behaviour and can cause financial or regulatory harm to the company. Typical impact: creating or inflating funds out of nothing, moving money out in ways the flow should not allow, abusing bonuses, or bypassing KYC.\n\n> **The vulnerability must reside in the money/verification flow itself.** A monetary loss achieved through otherwise legitimate functionality after a separate compromise — for example, taking over an account via XSS, CSRF, IDOR, or leaked credentials and then using the normal withdrawal feature — is classified under the scope of that underlying vulnerability (e.g. Main Scope), not here. In this scope the unexpected movement of money or bypass of verification **is** the vulnerability, not merely its impact.\n\nIn short, we are looking for cases where an attacker can:\n\n1. Circumvent verification processes for deposits, refunds, or withdrawals.\n2. Manipulate system logic to bypass restrictions (e.g. the withdrawal block for non-verified users).\n3. Gain unauthorized access to funds or perform operations contrary to the intended flow — e.g. balance inflation, bonus abuse, double-spending, or rounding/arithmetic flaws affecting monetary calculations.\n\n## User & verification model\n\n**Non-verified users** — identity not confirmed (no KYC).\n- Allowed: deposit funds (no limit); refund deposited funds to the original card.\n- Restricted: all withdrawals other than card-based refunds are blocked; winnings cannot be withdrawn without triggering verification.\n\n**Verified users** — identity confirmed via official documents (e.g. passport).\n- All operations (deposit, withdrawal, refund) are gated by verification, starting from the first deposit.\n\n## In-scope vulnerability classes\n\n### Document integrity\n- Forged, AI-generated, or altered documents passing verification undetected, including repeated submission of modified versions of the same document.\n- Tampering with uploaded document metadata to bypass manual review.\n\n### Deposits\n- Inflating account balance without an actual payment (tampering with transaction requests/responses).\n- Using a verification-required payment method — or one disabled in the UI for a given country — via direct API calls.\n- Duplicate / replayed deposit transactions, or modified deposit amounts.\n\n### Withdrawals\n- Withdrawing funds (including winnings) to a card other than the deposit card without triggering verification where it should be required.\n- Withdrawing or refunding funds beyond the amount eligible — e.g. a non-verified user getting back more than was deposited, or before a refund is completed.\n- Inconsistencies between client-side and server-side enforcement of withdrawal blocks.\n- Altering withdrawal limits or changing the beneficiary account/card via the API.\n\n### Refunds\n- Issuing multiple refunds for a single deposit (double refunds), or refunding more than the original deposit amount.\n- Using the refund flow to cash out funds unrelated to the original deposit (e.g. winnings).\n- Manipulating another account's transaction ID to trigger an unauthorized refund, or redirecting a refund to an unauthorized account/card.\n- Triggering refunds without the proper KYC checks.\n\n### Bonuses & promo codes\n- Any use of bonuses or promo codes outside their intended scenario that produces a monetary or security impact. This includes, but is not limited to: reuse or replay of single-use codes, multi-accounting / self-referral to farm bonuses, stacking promotions that should not combine, inflating a bonus value, and claiming a promotion the user is not eligible for.\n\n### Authorization on monetary operations\n- Missing or broken ownership / authorization checks on monetary endpoints that allow a user to act on another user's funds or account — for example, an IDOR or parameter swap (user_id, account_id, card_id, transaction_id) that withdraws, refunds, or moves another user's balance, or operates on their billing data. The vulnerability is the absent authorization on the money operation itself, not access obtained through a separate compromise.\n\n### Business logic & payment-gateway integrity\n- Manipulating communication between the platform and the payment gateway, or failed/declined payments still being credited to the account.\n- Double-spending / duplicate processing of the same transaction (e.g. replaying a transaction ID).\n- Rounding or arithmetic errors that create or destroy value.\n- Combining otherwise-legitimate flows to reach an unintended outcome (e.g. using the refund mechanism to circumvent the withdrawal block).",
        "impact": "No Bounty"
      },
      {
        "type": "other",
        "endpoint": "Main Scope",
        "description": "## Description\n\nThis scope covers general application-security vulnerabilities on the platform that do **not** reside in the trading, payment, or verification (KYC) flows. Issues whose core defect is in the money or verification logic belong to Trading Scope.\n\n## Assets\n\n```\niqoption.com\n*.iqoption.com\n```\n\nThe scope applies to the root domain and all sub-domains, except those listed in the Out of Scope section.\n\n## What this scope covers\n\nTechnical web-application vulnerabilities affecting the confidentiality, integrity, or availability of the platform and its users, where the flaw is not in a monetary or verification operation itself. Typical classes include (non-exhaustive): XSS, SSRF (reaching internal resources or cloud metadata), injection (SQLi, command, template, etc.), authentication / session / authorization flaws, IDOR on non-monetary objects, access-control bypass, and sensitive-data exposure.\n\n## Relationship to Trading Scope\n\nWhere a vulnerability in this scope produces a monetary or verification impact through otherwise-legitimate functionality — e.g. taking over an account via XSS, IDOR, or leaked credentials and then using the normal withdrawal or refund feature — the finding is classified here, under the underlying vulnerability, not under Trading Scope. Trading Scope is reserved for cases where the unexpected movement of money or bypass of verification **is** the vulnerability.\n\n> **Note:** Account takeover via the `ssid` cookie — arising from the lack of the `HttpOnly` attribute — is a known and accepted issue. A report will not gain additional severity from chaining this vector (e.g. XSS → `ssid` theft → ATO → withdrawal). The underlying vulnerability (e.g. the XSS itself) is still assessed on its own merits.",
        "impact": "No Bounty"
      },
      {
        "type": "other",
        "endpoint": "Corporate Scope",
        "description": "## Description\n\nThe Quadcode corporate website, presenting company information, mission, and solutions.\n\n## Assets\n\n```\nquadcode.com\n*.quadcode.com\n```\n\nThe scope is currently limited to the domains listed above.\n\n## What this scope covers\n\nThe same technical web-application vulnerability classes as Main Scope (XSS, SSRF, injection, authentication / session / authorization flaws, IDOR, access-control bypass, sensitive-data exposure, etc.), as they apply to the corporate website.",
        "impact": "No Bounty"
      },
      {
        "type": "other",
        "endpoint": "Asset, Data & Secret Exposure",
        "description": "## Description\n\nA scope for high-impact findings that fall outside Trading, Main, and Corporate Scope — typically the exposure of Quadcode-owned assets, data, secrets, or infrastructure on systems that are not among the listed in-scope domains. A demonstrated security impact is mandatory; severity is assessed by that impact, as described below.\n\n## What this scope covers\n\nExposure of Quadcode assets, data, or secrets outside the listed scope, **where a concrete security impact can be demonstrated**, including but not limited to:\n\n- Leaked or exposed Quadcode credentials, API keys, tokens, or other secrets — including valid credentials found in breached or leaked databases — where the access or capability they grant is demonstrated.\n- Container images pushed to public registries (e.g. Docker Hub) that expose secrets or other sensitive internal details.\n- Misconfigured or open cloud storage (e.g. S3 buckets) containing Quadcode data.\n- Other comparable exposures with a realistic, serious security impact on Quadcode or its customers.\n\n## Impact, severity, and eligibility\n\n- **A demonstrated security impact is mandatory.** The mere existence of exposed material — a credential string, a token, a public artifact — is **not** sufficient on its own. Findings without a demonstrated impact are out of scope.\n- For reports involving exposed secrets specifically, you must demonstrate that:\n  - the secret belongs to Quadcode;\n  - the secret is currently valid; and\n  - it grants access to non-public resources or data.\n- Demonstrate impact only to the **minimum** extent necessary (e.g. confirm that authentication succeeds); do not go further (see the rules below).\n- Severity reflects the sensitivity of the exposed asset/account and the real, demonstrated impact on Quadcode's infrastructure and customers — not the mere existence of access. Valid credentials or access that pose no direct risk to our customers' data (e.g. those belonging to B2B partners) are treated accordingly.\n- Before reporting, confirm the asset actually belongs to Quadcode. Findings on third-party or unrelated assets are out of scope.\n- We reserve the final right to determine the scope and severity of findings in this area.\n\n## Rules for this scope\n\nThese reinforce the global Rules of Engagement and apply strictly here:\n\n- **Demonstrate impact only to the minimum required, then stop.** Confirm the exposure is real and exploitable (e.g. that a credential authenticates), but do not access, download, or extract data beyond that minimum.\n- Do not pivot, escalate, or use any discovered access to reach further systems.\n- Report immediately and do not retain copies of any exposed data or secrets.",
        "impact": "No Bounty"
      }
    ],
    "out_of_scope": [
      {
        "type": "wildcard",
        "endpoint": "*.cpa.iqoption.com",
        "description": null,
        "impact": "Out of scope"
      }
    ]
  }
}