[{"id":3764901,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt these links [[1]](https://t.me/indrive_bbp/68),[[2]](https://t.me/indrive_bbp/86) you will find a CSV files containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#Update to the Scope Policy (from 09/09/2025)\n\ninDrive is not only about ride-hailing - we also contribute to education, sports, environmental initiatives, and other social projects.\nTo make our bug bounty program clearer, we divide the scope into Core and Non-core services:\n- **Core services** are directly connected to our main app infrastructure (backend, frontend resources). E.g., `no-gw-cf.\u003cregion\u003e.aws.indriverapp.com, couriers.indrive.com`. They can be identified by using the filter `Technology: Core` in the [Scope page](https://hackerone.com/indrive/policy_scopes). Rewards for vulnerabilities are listed in the **“Price (for Core services)”** column in the Reward payment section.\n- **Non-core services** are additional projects of inDrive, such as web resources related to social, non-profit, experimental initiatives and partner integrations. They can be identified by using the asset filter `Technology: Non-core` in the [Scope page](https://hackerone.com/indrive/policy_scopes). Rewards for vulnerabilities are listed in the **“Price (for Non-core services)”** column in the Reward payment section.\n\nIf you are unsure, or cannot find the relevant asset in our scope, please submit your report anyway. Our team will review it during triage and clarify whether the service belongs to Core or Non-core.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price (for Core services) | Price (for Non-core services) | Severity|\n| ----------- | ----------- |----------- |----------- |\n| Remote code execution (RCE) in not isolated environment| 15000 | 8000 |Critical|\n| Remote code execution (RCE) in an isolated environment| 8000 | 4000 |High|\n| Injections (SQLi or equivalent)| 4000-8000 | 2000-4000 |High-Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions| 4000 | 2000| High-Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|4000|1000-2000|High|\n|SSRF, blind, except dedicated proxies|1500|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|5000|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|2000|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|1000|500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of low-sensitivity client/infrastructure data (non-covered by other categories)|500|250|Medium|\n|Admin / support interface authentication bypass|3000|1000-1500|High|\n|Admin / support interface blind XSS|2000|500-1000|Medium-High|\n|Account takeover of customer accounts (without user interaction)|2000|500-800|Medium-High|\n|Account takeover of customer accounts (with user interaction)|1000|400|Medium-High|\n|Authorization/Authentication bypass (e.g., issues with JWT/passkey/OTP/OAuth)|1000|500|High|\n|Cross-Site Scripting (XSS)*|300-400|150-200|Medium|\n|Subdomain takeover**|100|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-10-21T12:57:05.996Z"},{"id":3762677,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt these links [[1]](https://t.me/indrive_bbp/68),[[2]](https://t.me/indrive_bbp/86) you will find a CSV files containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#Update to the Scope Policy (from 09/09/2025)\n\ninDrive is not only about ride-hailing - we also contribute to education, sports, environmental initiatives, and other social projects.\nTo make our bug bounty program clearer, we divide the scope into Core and Non-core services:\n- **Core services** are directly connected to our main app infrastructure (backend, frontend resources). E.g., `no-gw-cf.\u003cregion\u003e.aws.indriverapp.com, couriers.indrive.com`. They can be identified by using the filter `Technology: Core` in the [Scope page](https://hackerone.com/indrive/policy_scopes). Rewards for vulnerabilities are listed in the **“Price (for Core services)”** column in the Reward payment section.\n- **Non-core services** are additional projects of inDrive, such as web resources related to social, non-profit, experimental initiatives and partner integrations. They can be identified by using the asset filter `Technology: Non-core` in the [Scope page](https://hackerone.com/indrive/policy_scopes). Rewards for vulnerabilities are listed in the **“Price (for Non-core services)”** column in the Reward payment section.\n\nIf you are unsure, or cannot find the relevant asset in our scope, please submit your report anyway. Our team will review it during triage and clarify whether the service belongs to Core or Non-core.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price (for Core services) | Price (for Non-core services) | Severity|\n| ----------- | ----------- |----------- |----------- |\n| Remote code execution (RCE)| 15000 | 8000 |Critical|\n| Injections (SQLi or equivalent)| 8000 | 4000 |Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions| 4000 | 2000| Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|4000|2000|High|\n|SSRF, blind, except dedicated proxies|1500|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|5000|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|2000|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|1000|500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of low-sensitivity client/infrastructure data (non-covered by other categories)|500|250|Medium|\n|Admin / support interface authentication bypass|3000|1500|High|\n|Authorization/Authentication bypass (e.g., issues with JWT/passkey/OTP/OAuth)|1000|500|High|\n|Admin / support interface blind XSS|2000|1000|High|\n|Cross-Site Scripting (XSS)*|300|150|Medium|\n|Subdomain takeover**|100|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-09-12T08:34:47.684Z"},{"id":3762548,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt this [link](https://t.me/indrive_bbp/68) you will find a CSV file containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#Update to the Scope Policy (from 09/09/2025)\n\ninDrive is not only about ride-hailing - we also contribute to education, sports, environmental initiatives, and other social projects.\nTo make our bug bounty program clearer, we divide the scope into Core and Non-core services:\n- **Core services** are directly connected to our main app infrastructure (backend, frontend resources). E.g., `no-gw-cf.\u003cregion\u003e.aws.indriverapp.com, couriers.indrive.com`. They can be identified by using the filter `Technology: Core` in the [Scope page](https://hackerone.com/indrive/policy_scopes). Rewards for vulnerabilities are listed in the **“Price (for Core services)”** column in the Reward payment section.\n- **Non-core services** are additional projects of inDrive, such as web resources related to social, non-profit, experimental initiatives and partner integrations. They can be identified by using the asset filter `Technology: Non-core` in the [Scope page](https://hackerone.com/indrive/policy_scopes). Rewards for vulnerabilities are listed in the **“Price (for Non-core services)”** column in the Reward payment section.\n\nIf you are unsure, or cannot find the relevant asset in our scope, please submit your report anyway. Our team will review it during triage and clarify whether the service belongs to Core or Non-core.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price (for Core services) | Price (for Non-core services) | Severity|\n| ----------- | ----------- |----------- |----------- |\n| Remote code execution (RCE)| 15000 | 8000 |Critical|\n| Injections (SQLi or equivalent)| 8000 | 4000 |Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions| 4000 | 2000| Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|4000|2000|High|\n|SSRF, blind, except dedicated proxies|1500|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|5000|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|2000|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|1000|500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of low-sensitivity client/infrastructure data (non-covered by other categories)|500|250|Medium|\n|Admin / support interface authentication bypass|3000|1500|High|\n|Authorization/Authentication bypass (e.g., issues with JWT/passkey/OTP/OAuth)|1000|500|High|\n|Admin / support interface blind XSS|2000|1000|High|\n|Cross-Site Scripting (XSS)*|300|150|Medium|\n|Subdomain takeover**|100|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-09-09T13:59:04.709Z"},{"id":3762546,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt this [link](https://t.me/indrive_bbp/68) you will find a CSV file containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#Update to the Scope Policy (from 09/09/2025)\n\ninDrive is not only about ride-hailing - we also contribute to education, sports, environmental initiatives, and other social projects.\nTo make our bug bounty program clearer, we divide the scope into Core and Non-core services:\n- **Core services** are directly connected to our main app infrastructure (backend, frontend resources). E.g., `no-gw-cf.\u003cregion\u003e.aws.indriverapp.com, couriers.indrive.com`. They can be identified by using the filter `Technology: Core` in the Scope section. Rewards for vulnerabilities are listed in the **“Price (for Core services)”** column in the Reward payment section.\n- **Non-core services** are additional projects of inDrive, such as web resources related to social, non-profit, experimental initiatives and partner integrations. They can be identified by using the asset filter `Technology: Non-core` in the Scope section. Rewards for vulnerabilities are listed in the **“Price (for Non-core services)”** column in the Reward payment section.\n\nIf you are unsure, or cannot find the relevant asset in our scope, please submit your report anyway. Our team will review it during triage and clarify whether the service belongs to Core or Non-core.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price (for Core services) | Price (for Non-core services) | Severity|\n| ----------- | ----------- |----------- |----------- |\n| Remote code execution (RCE)| 15000 | 8000 |Critical|\n| Injections (SQLi or equivalent)| 8000 | 4000 |Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions| 4000 | 2000| Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|4000|2000|High|\n|SSRF, blind, except dedicated proxies|1500|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|5000|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|2000|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|1000|500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of low-sensitivity client/infrastructure data (non-covered by other categories)|500|250|Medium|\n|Admin / support interface authentication bypass|3000|1500|High|\n|Authorization/Authentication bypass (e.g., issues with JWT/passkey/OTP/OAuth)|1000|500|High|\n|Admin / support interface blind XSS|2000|1000|High|\n|Cross-Site Scripting (XSS)*|300|150|Medium|\n|Subdomain takeover**|100|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-09-09T13:06:16.216Z"},{"id":3762545,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt this [link](https://t.me/indrive_bbp/68) you will find a CSV file containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#Update to the Scope Policy (from 09/09/2025)\n\ninDrive is not only about ride-hailing - we also contribute to education, sports, environmental initiatives, and other social projects.\nTo make our bug bounty program clearer, we divide the scope into Core and Non-core services:\n- **Core services** are directly connected to our main app infrastructure (backend, frontend resources). E.g., `no-gw-cf.\u003cregion\u003e.aws.indriverapp.com, couriers.indrive.com`. They can be identified by using the filter `Technology: Core` in the Scope section. Rewards for vulnerabilities are listed in the **“Price (for Core services)”** column in the Reward payment section.\n- **Non-core services** are additional projects of inDrive, such as web resources related to social, non-profit, experimental initiatives and partner integrations. They can be identified by using the asset filter `Technology: Non-core` in the Scope section. Rewards for vulnerabilities are listed in the **“Price (for Non-core services)”** column in the Reward payment section.\n\nIf you are unsure, or cannot find the relevant asset in our scope, please submit your report anyway. Our team will review it during triage and clarify whether the service belongs to Core or Non-core.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price (for Core services) | Price (for Non-core services) | Severity|\n| ----------- | ----------- |----------- |----------- |\n| Remote code execution (RCE)| 15000 | 8000 |Critical|\n| Injections (SQLi or equivalent)| 8000 | 4000 |Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions| 4000 | 2000| Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|4000|2000|High|\n|SSRF, blind, except dedicated proxies|1500|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|5000|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|2000|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|1000|500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of low-sensitivity client/infrastructure data (non-covered by other categories)|500|250|Medium|\n|Admin / support interface authentication bypass|3000|1500|Critical|\n|Authorization/Authentication bypass (e.g., issues with JWT/passkey/OTP/OAuth)|1000|500|High|\n|Admin / support interface blind XSS|2000|1000|High|\n|Cross-Site Scripting (XSS)*|300|150|Medium|\n|Subdomain takeover**|100|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-09-09T12:58:03.854Z"},{"id":3758957,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt this [link](https://t.me/indrive_bbp/68) you will find a CSV file containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|High|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of low-sensitivity client/infrastructure data (non-covered by other categories)|250|Medium|\n|Admin / support interface authentication bypass|1500|Critical|\n|Authorization/Authentication bypass (e.g., issues with JWT/passkey/OTP/OAuth)|500|High|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-07-14T07:37:23.916Z"},{"id":3758952,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt this [link](https://t.me/indrive_bbp/68) you will find a CSV file containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#Partner integrations\n\ninDrive has recently partnered with [Ryadom](https://ryadom.kz/) company from Kazakhstan, and their service is now accessible via the inDrive app (minumum app version: 5.128.0) . As part of this collaboration, we welcome security researchers to test the integration and report vulnerabilities that could affect inDrive users, infrastructure or data (issues with integration services, deeplinks etc).\nTo start testing the integration with **Ryadom**, please update your user profile and set the city to **Astana** or **Almaty**. Once set, you should see the icon **\"Grocery\"** appear on the main screen of the inDrive app.\n\n**Important note**:\n\nIf a vulnerability affects **only the partner’s app, service, or backend**, and does not impact inDrive’s infrastructure or users, it will be considered **out of inDrive's direct scope**. However, we will still review the report and coordinate with our partner to evaluate its relevance and potential impact. **Any decision regarding a bounty for such findings will be made in collaboration with the partner.**\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|High|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of low-sensitivity client/infrastructure data (non-covered by other categories)|250|Medium|\n|Admin / support interface authentication bypass|1500|Critical|\n|Authorization/Authentication bypass (e.g., issues with JWT/passkey/OTP/OAuth)|500|High|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-07-14T03:42:20.346Z"},{"id":3756088,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt this [link](https://t.me/indrive_bbp/68) you will find a CSV file containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|High|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of low-sensitivity client/infrastructure data (non-covered by other categories)|250|Medium|\n|Admin / support interface authentication bypass|1500|Critical|\n|Authorization/Authentication bypass (e.g., issues with JWT/passkey/OTP/OAuth)|500|High|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-05-22T09:48:34.666Z"},{"id":3744898,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nAt this [link](https://t.me/indrive_bbp/68) you will find a CSV file containing the endpoints to be scanned. \n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|High|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|500|High|\n|Admin / support interface authentication bypass|1500|Critical|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-20T08:28:27.727Z"},{"id":3700196,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|High|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data(Automated bulk collection of available information requiring no complex operation/user interaction)|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive client/infrastructure data (non-covered by other categories)|500|High|\n|Admin / support interface authentication bypass|1500|Critical|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-21T14:03:53.257Z"},{"id":3699968,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|High|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards)|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of protected personal data or sensitive client information|1000|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive application or infrastructure data|500|High|\n|Admin / support interface authentication bypass|1500|Critical|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-08-16T11:44:33.412Z"},{"id":3698414,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|High|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards, e-mail messages)|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of protected personal data or sensitive client information|1500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive application or infrastructure data|500|High|\n|Admin / support interface authentication bypass|1500|Critical|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-07-18T07:44:16.826Z"},{"id":3698413,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|High|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards, e-mail messages)|2500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of protected personal data or sensitive client information|1500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive application or infrastructure data|500|High|\n|Admin / support interface authentication bypass|1500|High|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-07-18T07:08:04.475Z"},{"id":3698366,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price | Severity|\n| ----------- | ----------- |----------- |\n| Remote code execution (RCE)| 8000 |Critical|\n| Injections (SQLi or equivalent)|4000|Critical|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|Critical|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|Critical|\n|SSRF, blind, except dedicated proxies|750|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards, e-mail messages)|2500|Critical|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of protected personal data or sensitive client information|1500|High|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive application or infrastructure data|500|High|\n|Admin / support interface authentication bypass|1500|High|\n|Admin / support interface blind XSS|1000|High|\n|Cross-Site Scripting (XSS)*|150|Medium|\n|Subdomain takeover**|50|Low|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-07-17T13:47:17.929Z"},{"id":3690127,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nAlso, subscribe to our news channel on [Telegram](https://t.me/indrive_bbp).\n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price |\n| ----------- | ----------- |\n| Remote code execution (RCE)| 8000 |\n| Injections (SQLi or equivalent)|4000|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|\n|SSRF, blind, except dedicated proxies|750|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards, e-mail messages)|2500|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of protected personal data or sensitive client information|1500|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive application or infrastructure data|500|\n|Admin / support interface authentication bypass|1500|\n|Admin / support interface blind XSS|1000|\n|Cross-Site Scripting (XSS)*|150|\n|Subdomain takeover**|50|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-29T11:17:06.189Z"},{"id":3689629,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price |\n| ----------- | ----------- |\n| Remote code execution (RCE)| 8000 |\n| Injections (SQLi or equivalent)|4000|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|2000|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|2000|\n|SSRF, blind, except dedicated proxies|750|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards, e-mail messages)|2500|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of protected personal data or sensitive client information|1500|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive application or infrastructure data|500|\n|Admin / support interface authentication bypass|1500|\n|Admin / support interface blind XSS|1000|\n|Cross-Site Scripting (XSS)*|150|\n|Subdomain takeover**|50|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-06-19T22:12:42.628Z"},{"id":3684127,"new_policy":"Security is a top priority at inDrive. If you believe you've found a security bug in our in-scope applications or infrastructure, we are happy to work with you to resolve the issue promptly and ensure you are fairly rewarded for your discovery.\n\nThe scope of this inDrive’s Vulnerability Disclosure Program Policy is limited to searching for technical vulnerabilities in the company's services and official mobile applications.\n\n#We will not pay a reward (and we will be really upset) if we detect:\n\n* Social engineering directed at the company's employees\n* Attempt to access arbitrary user's account or data or another vulnerability post- exploitation not required to demonstrate the bug presence\n* Distributed network/request flooding and other resource exhaustion attacks. Automated scanning tools must be limited to 5 request per second (300 requests per minute) to one target host summing up all tools and threads running in parallel and must not exceed 5 parallel requests at the same time (5 threads).\n\nPlease use your own accounts, phone numbers, etc to conduct your research. Do not try to gain access to others' accounts or any confidential information. When testing the feedback functionality, sending a message to technical support, etc., be sure to specify the subject `Test` and use [hacker email alias](https://docs.hackerone.com/hackers/hacker-email-alias.html)\n\n#We do not initiate security investigations regarding:\n\n* Messages from security scanners and other automated systems without clear PoC and impact;\n* Vulnerability reports based on software/protocol versions not indicating the actual usage/exploitation;\n* Reports about the absence of a protection mechanism or non-compliance with recommendations (for example, the absence of a CSRF token) without indicating real negative consequences;\n* Self-XSS;\n* Framing;\n* Social engineering;\n* Clickjacking;\n* SPF/DKIM/DMARC issues;\n* Man-in-the-Middle attacks\n* Vulnerabilities in partner services and products that do not directly affect the security of the company's services.\n* Infrastructure vulnerabilities, including:\n      * Server configuration issues (e.g. open ports, TLS versions, etc.)\n      * Issues related to SSL certificates\n      * DNS configuration issues\n* Google API key(for google maps)\n\n#Strictly prohibited actions:\n\n* DoS / DDoS attacks;\n* Threats/harm to company employees.\n\n#How do I submit a bug report?\n\nA bug report must give a detailed description of the discovered vulnerability and brief steps to reproduce it, or a working proof-of-concept. Video and screenshots can illustrate bug report, but can not replace it.\n\nIf you do not describe the vulnerability in sufficient detail, the discovery process is significantly prolonged and that doesn't help anybody. It's also very desirable if researcher can explain how exactly he or she found a given vulnerability.\n\n#How are bug reports examined?\n\nReports about vulnerabilities are examined by our security analysts. Our analysis is always based on worst case exploitation of the vulnerability, as is the reward we pay.\n\nReports are reviewed within 15 days (this is a maximum period - we'll probably respond sooner). If you prefer to remain anonymous, we recommend using an alias when submitting bug reports.\n\n#Participating reports\n\nOnly reports reported via bug bounty platform interface may be considered for a bounty. A date/time of report on bug bounty platform is considered as a date/time of the report.\n\n#Duplicate reports\n\nDifferent exploitation vectors for the same bug or similar bugs may be considered duplicating if the security team believes information provided for a single vector/bug is enough to fix all vectors or bugs reported.\n\nReport for known or duplicating vulnerability is considered as Duplicate. Duplicate reports are not eligible for monetary reward. Report can be either a duplicate of another report from any bug bounty platform or a duplicate of the problem internally tracked by inDrive security team. Usually, access to the original report or some information from the internal task tracker is provided to the reporter of Duplicate. In some cases information may not be provided, if a Duplicate contains less information or less critical exploitation vector than the original report.\n\nThe report is considered as a duplicated to another report from any bug bounty platform, if there is original report is in \"New\" or \"Triaged\" state with an earlier report date/time or lower report number of if it updates the report in \"N/A\" or \"Need more info\" state and original report is in \"N/A\" or \"Need more info\" state for less than 1 week or sufficient information is provided in original report by researcher since the report is transferred to \"N/A\" or \"Need more info\" state.\n\nThe report is considered as a duplicate to an internal task if there is a task in the internal task tracker which is tracked by the inDrive security team at the time of the duplicate report.\nAlso, public 0-day/1-day vulnerabilities may be considered as a duplicate within a few days after vulnerability details publication, if the vulnerability is known to our team from public sources and we are working to mitigate or patch it.\n\n#Invalid reports\n\nReport in \"N/A\" or \"Need more info\" state which is stale in this state for more than a week without sufficient new information provided is considered as invalid and does not participate in bug bounty.\n\n#Reward payment\n\nWe will pay you a reward if you are the first person to report a given vulnerability.\n\nThe bounty decision will be made within 30 days after triage (this is a maximum period - we'll probably award sooner). A message will appear in your bug report, indicating that the vulnerability you reported has been confirmed and a reward has been granted.\n\nPayments are made through [HackerOne](https://docs.hackerone.com/hackers/payments.html).\n\n| Vulnerability      | Price |\n| ----------- | ----------- |\n| Remote code execution (RCE)| 6000 |\n| Injections (SQLi or equivalent)|2000|\n|Local files access and manipulation (LFR, RFI, XXE) without jail/chroot/file type restrictions|1500|\n|SSRF, non-blind (with ability to read reply text), except dedicated proxies|1000|\n|SSRF, blind, except dedicated proxies|300|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of application critical or highly confidential data (e.g. sessions, accounts, passwords, 1000 credit cards, e-mail messages)|1500|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of protected personal data or sensitive client information|750|\n|Serverside vulnerability with information disclosure (e.g. memory Leaks / IDORs) of sensitive application or infrastructure data|300|\n|Admin / support interface authentication bypass|1000|\n|Admin / support interface blind XSS|600|\n|Cross-Site Scripting (XSS)*|100|\n|Subdomain takeover**|50|\n\n\\*self-XSS, XSS specific to non-common browsers (e.g. IE), blocked by CSP and another vectors without proven script execution are usually accepted without bounty. Unused subdomain takeover is considered under same severity / conditions as parent domain XSS.\n\n\\**We temporarily do not accept reports on Social Media links(instagram, twitter, facebook)  \n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-02-27T15:58:27.679Z"}]