Skroutz Public Managed Bug Bounty
By Skroutz S.A. Bug bounty on Bugcrowd skroutz.gr
- Top reward
- $5,000
- Top severity paid
- Critical
- Assets in scope
- 1
- Public CVEs
- 0
- Last change
At a glance
What to know before you start testing.
- Pays up to $5,000
- for critical bugs, from $100.
- Report on Bugcrowd
- Submit through the program page.
- Full safe harbor
- Good-faith research is authorised; no legal action.
- No public write-ups
- Keep findings private.
Rewards
What Bugcrowd lists as the payout for each severity.
| Severity | Relative size | Reward |
|---|---|---|
| Critical |
|
$5,000 from $4,000 |
| High |
|
$2,000 from $1,000 |
| Medium |
|
$900 from $500 |
| Low |
|
$300 from $100 |
- Safe harbor
-
Full
Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy;
Summarised with AI from the program policy on Bugcrowd, read 12 Nov 2026, and checked word for word against it. Read the original
Earlier reward tables (1)
- 11 Nov 2026 to 11 Nov 2026: Critical up to $5,000
Scope
1 asset you may test.
Web 1
- https://www.skroutz.gr
Rules
What the policy asks of you, and the bug types it won't reward, quoted from Skroutz Public Managed Bug Bounty (via Bugcrowd)'s policy. "We" in these lines means the program, not this site.
While testing
-
Provide clear details of any finding, including detailed steps to replicate, any applicable PoC, potential impact and mitigation recommendations
-
Do your absolute best to act in good faith, avoiding any potential destruction of data and services, excessive disruption of services and any privacy violations
-
Make sure to comply with all relevant & applicable cybersecurity and privacy laws
-
Contact the Skroutz team immediately when you detect any leakage of real customer data that would constitute a privacy breach
-
All submissions must demonstrate actual, verified impact.
-
Do not attempt to complete purchases with your own credit cards or payment methods as we CANNOT guarantee any partial or full refunds.
-
Do not share your credentials with other researchers as you are ultimately responsible for the privacy and security of your account.
-
IP/port scanning
-
Do not attempt to brute force any credentials of any kind
Not accepted
-
Cross-Site Request Forgery (CSRF) issues (Currently aware of all relevant issues)
-
HTTP security headers (Unless they lead to a demonstrable impact on user data/sensitive functions)
-
Browser cookie security flags (Unless they lead to a demonstrable impact on user data/sensitive functions)
-
SSL/TLS related issues (ex. Weak ciphers, certificate strength etc.)
-
Password policy (ex. Low password complexity, expiration, password reset timeout etc.)
-
Session expiration time interval
-
Self-XSS
-
Error messages - Unless they lead to customer private data exposure
-
Clickjacking issues
-
Account lockout policies
-
Absence of security controls (ex. Rate-limiting or WAF)
-
Vulnerability only relevant to users of legacy/obsolete/out-of-date browsers
-
Email server issues - Unless directly exploitable through the web application/API targets
-
Email/Username enumeration (other enumerations are in scope)
-
Out-of-date vulnerable third-party libraries (Unless you can demonstrate exploitability of the vulnerability on the web application)
-
Password Leaks/Dumps on credentials from third-party websites (e.g. Dehashed)
-
Social Engineering - Unless they lead to a feasible and easily reproducible scenario
-
Validation issues on Skroutz Skoop (ex. no validation on address, tax code, mobile number, KYC etc - these are on purpose)
-
Black Friday relevant coupons
-
2FA
Summarised with AI from the program policy on Bugcrowd, read 12 Nov 2026, and checked word for word against it. Read the original
Changes
Tracked since 11 Nov 2026. Last checked 1 hour ago.
No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.
Before we tracked it
Scope and reward changes recorded before this page started tracking it.
-
Rules updated
Added: “<h1>AI Generated submissions</h1>”
Public CVEs
Published vulnerabilities in this vendor's products, from the NVD.
No CVEs matched yet. We match NVD records by vendor name, so products sold under another name can be missing.
Original policy
Copied from bugcrowd.com on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.
Description
Skroutz S.A. is the prime Greek e-commerce and online marketplace platform. We are dedicated to offering our customers and partners top-quality services while maintaining a strong security posture; protecting our customer’s data & privacy is our highest priority. To that end we welcome contributions from security researchers as part of Bugcrowd’s private bug bounty program with the aim of identifying and mitigating any security flaws, gaps and vulnerabilities present in our platform. Security researchers are invited to conduct extensive research on our live production environment (detailed below), to guarantee accuracy and relevance of reported findings. as long as the stability, integrity and availability of the production environment is not severely affected by said research . Ratings/Rewards: For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy . However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority. Testing Guidelines: While aiming to assist security researchers succeed in our bug bounty program, we expect all participants to adhere to some basic guidelines for interacting with and assessing our platform and supporting services as defined here: Provide clear details of any finding, including detailed steps to replicate, any applicable PoC, potential impact and mitigation recommendations Do your absolute best to act in good faith, avoiding any potential destruction of data and services, excessive disruption of services and any privacy violations, reporting any concerns around these topics to the Skroutz team. Make sure to comply with all relevant & applicable cybersecurity and privacy laws Be patient when submitting findings for the Skroutz security team to review and accept as we need to prioritize tasks based on their severity and impact to our platform Contact the Skroutz team immediately when you detect any leakage of real customer data that would constitute a privacy breach AI Generated submissions As we are seeing a growing number of submissions that appear to be generated primarily by AI reviews with reduced to no human verification before submission, we require the researchers to properly check all submissions. Recent reports have described intentional, by-design behaviors (e.g. promotional/voucher mechanisms deliberately not scoped to a single user or cart as Broken Access Control or IDOR) without verification. More precisely: All submissions must demonstrate actual, verified impact. Submissions such as "this parameter is not scoped similarly with X endpoint" will be marked at best as P5 - Informational or even penalized. The same applies for submissions that are mostly security suggestions or improvements. Design inconsistencies are not flaws without verifiable evidence. Differential responses are not a vulnerability without a replay-able attack scenario. Reports that read as AI-generated analysis without human verification, concrete exploitation scenario may be closed as Not Applicable/Not Reproducible. Massive artifact logs without curation will be ignored or downgraded. Consecutive submission spraying with P5 or Not Applicable or Not Reproducible findings may end up in banning a researcher from our program. The researchers are ALWAYS accountable for each submission. As tooling has evolved, and we do not wish to ban AI submissions, use whatever helps you but own it end-to-end. We are more than happy to engage on edge-cases or re-open cases upon new evidence, but high submission volume with low hit-rate cost us human triage time and it affects turnaround for everyone, including well-researched reports. Thank you for continuing to test us, so let's move the bar on verification upwards instead of degrading the quality of our program.
Targets
Testing is only authorized on the targets listed as in scope. Any domain/property of Skroutz not listed in the targets section is out of scope. This includes any/all subdomains not listed above. If you happen to identify a security vulnerability on a target that is not in scope, but it demonstrably belongs to Skroutz, you can report it to this program. However, be aware that it is ineligible for points-based compensation. Target Information: The targets for this engagement are the Skroutz web application and its associated API on the live production environment. The application is built with Ruby on Rails and is a full scale e-commerce web application. The frontend is React. Many of the Skroutz components are built with Open Source Software, some of the components that they use are available at: https://github.com/skroutz . The program will take place in a production environment with live data and must be treated with due care accordingly. Skroutz's main web application uses Greek as the primary language of the website, however we have launched alternative versions of the website with localised content for various European markets (including English), you are free to use any alternative language and/or website flavour. All website flavours serve the same backend code (so it is essentially a single bounty target), so you can test on any of the following flavors : skroutz.gr - main skroutz.de skroutz.bg skroutz.ro skroutz.cy skroutz.eu Note: These flavors are translations of the same main skroutz.gr Skroutz web application. The following are true for the environment: The web applications in scope are served through a HAProxy load-balancer setup that routes traffic to the relevant application servers (unicorn). Security controls might be in place to block certain payloads or common attacks for the bounty environment (ex. WAF). The main web application can be accessed using its normal user registration flow. Researchers can create their own user accounts at will through the default registration process of the application. We strongly suggest that you keep new account registrations at a minimum , as required to test effectively, as to not skew our business metrics and analytics The environment is configured to forward emails to all email addresses. Payments cannot and should not be completed as we do not provide testing credit card numbers or similar functionality. DO NOT attempt to complete purchases with your own credit cards or payment methods as we CANNOT guarantee any partial or full refunds. API Information and Documentation: Full production documentation available here: https://developer.skroutz.gr/api/v3/ . Authentication & Authorization is managed by leveraging the OAuth2 protocol. It requires a client_id & client_secret to issue OAuth2 tokens to be used for all subsequent requests. No client_id & client_secret values are provided to normal production users, the API endpoints are included here for testing from an unauthenticated perspective. Of course you are free to attempt to bypass authentication/authorization of the API endpoints and access their functions without a provided client_id & client_secret. Access: The target web application is our live environment and is, therefore, readily accessible through the Internet. Credentials: As mentioned you can register user accounts to access the main Skroutz application through the normal registration flow. As this bounty program's scope aims to be identical to that of a standard user level attacker, we do not provide any pre-provisioned accounts with additional access rights or other roles. Always keep in mind that this is a live production environment so you should **keep user account registrations, at a minimum and you should protect your accounts as you normally would in any other web application. Do not share your credentials with other researchers as you are ultimately responsible for the privacy and security of your account. Focus Areas: Authentication process API endpoints and their functions Checkout/Payment step workflows - Steps involving credit card details - WITHOUT completing payments Smart Basket Functionality ("Purchase from Skroutz") Purchase directly through our website Including merchants without a website Skroutz Gift Cards (treated as a normal product at checkout but can then be used as coupons on subsequent order). Abusing the Gift Card behaviour would be an important risk to look for. (Assuming you have staging access via Bugcrowd whitelisted IPs you can see the products here : https://www.bounty.skroutz.dev/c/4802/dorokartes.html?o=gift+cards) Email Verification Sign-Up : We recently introduced mandatory email verification for all new signups with normal Skroutz username/password accounts. We are interested to see if we covered all bases in terms of security Skroutz Plus + Friend Referals : Skroutz Plus is our loyalty subscription program and we’ve recently introduced a referral bonus scheme on it and we would like for it to be tested for potential abuse or other security flaws (https://www.bounty.skroutz.dev/account/plus - Requires being logged in first with one of the provided accounts) Skroutz Skoop, our consumer-to-consumer marketplace where you can sell your items and buy other users' items leveraging Skroutz's efficient user journey. We are particularly interested in security vulnerabilities as well as abuses that can bypass our buyer protection guarantees Out-of-Scope Our AI-chatbot agent D/DoS Cross-Site Request Forgery (CSRF) issues (Currently aware of all relevant issues) HTTP security headers (Unless they lead to a demonstrable impact on user data/sensitive functions) Browser cookie security flags (Unless they lead to a demonstrable impact on user data/sensitive functions) SSL/TLS related issues (ex. Weak ciphers, certificate strength etc.) Password policy (ex. Low password complexity, expiration, password reset timeout etc.) Session expiration time interval Self-XSS Error messages - Unless they lead to customer private data exposure Clickjacking issues Account lockout policies Absence of security controls (ex. Rate-limiting or WAF) Vulnerability only relevant to users of legacy/obsolete/out-of-date browsers Email server issues - Unless directly exploitable through the web application/API targets Email/Username enumeration (other enumerations are in scope) Out-of-date vulnerable third-party libraries (Unless you can demonstrate exploitability of the vulnerability on the web application) Password Leaks/Dumps on credentials from third-party websites (e.g. Dehashed) Social Engineering - Unless they lead to a feasible and easily reproducible scenario Validation issues on Skroutz Skoop (ex. no validation on address, tax code, mobile number, KYC etc - these are on purpose) Black Friday relevant coupons 2FA We are currently developing a 2FA mechanism so it is of utmost importance if a bypass or vulnerability is found. Note for the 2FA: The mechanism is not implemented everywhere, but only in specific endpoints / actions. Examples: Not enabled for login. Enabled when changing email address from the user page. Forbidden Activities The following activities are strictly prohibited, will not be eligible for any rewards and may even result in researcher accounts/IP addresses/clients getting banned from the production environment altogether: Denial of Service & Distributed Denial of Service attacks. Do not attempt to interrupt the production environment's stability/availability . If you discover a relevant issue please cease all testing and report it to the program directly for triage. IP/port scanning Attacking the load-balancers that serve the applications and API endpoints directly Attacking the network and/or hosts of the applications and API endpoints directly - unless possible through an application/API vulnerability Excessive aggression on automated scanning tools : always pace your scanning tools to a reasonable amount of concurrent requests against the environment Do not create huge amounts of new database entries via automated means (ex. New accounts) - Only create what is necessary for your testing in a manual or semi-automated manner Do not attempt to brute force any credentials of any kind Safe Harbor: When conducting vulnerability research according to this policy, we consider this research to be: Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy; Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls; Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; and Lawful, helpful to the overall security of the Internet, and conducted in good faith. You are expected, as always, to comply with all applicable laws. If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please inquire via [email protected] before going any further.
Skroutz Public Application (in scope)
You are testing directly on Skroutz's production environment. Behavior that compromises the stability and integrity of the site is strictly forbidden & out of scope. For example, do not target other user's data (use one of your other sets of credentials), delete/remove/edit parts of the site, engage any sort of DoS attack, and/or compromise any target's ability to function for other users. If you believe that you have found a vulnerability of this nature, please cease all further testing and report it immediately.