\n| Critical<\/td>\n | 9.0\u201310.0<\/td>\n | \u20ac2,500\u2013\u20ac4,000<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n The reward grid displays the maximum reward for each severity level. Within the applicable range, the reward is calculated from the confirmed CVSS v3.1 Base Score using the formula below and rounded to the nearest \u20ac10:<\/p>\n reward = band minimum + (confirmed score \u2212 lowest score of band) \/ (highest score of band \u2212 lowest score of band) \u00d7 (band maximum \u2212 band minimum)<\/code><\/pre>\nExamples:<\/p>\n \n\n\n| Severity<\/th>\n | CVSS score<\/th>\n | Reward<\/th>\n<\/tr>\n<\/thead>\n | \n\n| Medium<\/td>\n | 4.0<\/td>\n | \u20ac200<\/td>\n<\/tr>\n | \n| Medium<\/td>\n | 5.5<\/td>\n | \u20ac410<\/td>\n<\/tr>\n | \n| Medium<\/td>\n | 6.9<\/td>\n | \u20ac600<\/td>\n<\/tr>\n | \n| High<\/td>\n | 7.0<\/td>\n | \u20ac600<\/td>\n<\/tr>\n | \n| High<\/td>\n | 8.0<\/td>\n | \u20ac1,600<\/td>\n<\/tr>\n | \n| High<\/td>\n | 8.9<\/td>\n | \u20ac2,500<\/td>\n<\/tr>\n | \n| Critical<\/td>\n | 9.0<\/td>\n | \u20ac2,500<\/td>\n<\/tr>\n | \n| Critical<\/td>\n | 9.8<\/td>\n | \u20ac3,700<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nReward calculation<\/h3>\n\n- OneFixOneReward<\/b> determines whether a report is eligible for a separate reward (including fix bypasses, see \"Fix bypasses\").<\/li>\n
- Base reward<\/b> is calculated from the confirmed CVSS v3.1 score using the reward ranges above.<\/li>\n
- Systemic issue<\/b> percentages are applied to the base reward.<\/li>\n
- Impact Bonus<\/b>, if granted, is calculated on the reward after step 3.<\/li>\n<\/ol>\n
How severity is determined<\/h2>\n1. CVSS scoring<\/h3>\nThe severity of a valid report is determined by its CVSS v3.1 Base Score, using Base Metrics only and the scoring conventions defined below.<\/p>\n The CVSS score is initially assessed by the YesWeHack triage team and then reviewed and confirmed by the MediaMarktSaturn security team. The confirmed score determines the severity and is used to calculate the reward.<\/p>\n Researchers may suggest their own CVSS vector. If the confirmed vector differs from the suggested or initial vector, MediaMarktSaturn will explain which metrics were changed and why. The confirmed assessment is final, subject to the disagreement process described below.<\/p>\n 2. Demonstrated impact<\/h3>\nSeverity is based on demonstrated impact<\/b>. CVSS metrics are assessed based on the security impact demonstrated by the proof of concept, rather than on hypothetical impact or escalation paths.<\/p>\n Any claimed impact must be supported by sufficient evidence. This includes, for example, account takeover, access to other customers' data, price, order or payment manipulation (see \"Integrity (I)\" under CVSS scoring conventions), or remote code execution. Unproven escalation paths are not considered when determining the CVSS score.<\/p>\n Researchers must not increase the scope or impact of exploitation solely to demonstrate a higher severity. If further exploitation would violate the testing rules, affect real customers or systems, or create unnecessary risk, MediaMarktSaturn may accept technically conclusive evidence of the impact instead. If you are unsure whether further exploitation is permitted, ask in the report before proceeding.<\/p>\n 3. Scoring conventions<\/h3>\nThe CVSS v3.1 Base Metrics are applied according to the program-specific scoring conventions below. These conventions define how MediaMarktSaturn assesses the relevant CVSS metrics in the context of this program.<\/p>\n 4. No downgrades based on business impact<\/h3>\nOnce the CVSS v3.1 Base Score has been confirmed, the resulting severity and calculated reward will not be reduced based on business considerations.<\/p>\n Exceptional business impact may increase the final reward through an Impact Bonus<\/b>.<\/p>\nCVSS scoring conventions<\/h2>\nScope (S)<\/h3>\n Scope describes whether the impact of a vulnerability remains within the same security boundary or extends to a separately controlled security context.<\/p>\n \n- Unchanged (S:U):<\/b> The vulnerability and its impact remain within the same security authority.<\/li>\n
- Changed (S:C):<\/b> Successful exploitation crosses a security-authority boundary and allows the attacker to affect a component or resource controlled by a different security authority.<\/li>\n<\/ul>\n
A different component or system does not automatically result in Changed<\/b>. What matters is whether the vulnerability crosses a security-authority boundary.<\/p>\n For example, XSS executing within the same origin and security authority as the vulnerable application is normally scored Unchanged<\/b>. A vulnerability that allows an attacker to escape an application's security boundary and compromise resources controlled by a separate security authority may be scored Changed<\/b>.<\/p>\nConfidentiality (C)<\/h3>\n Confidentiality measures the extent to which a vulnerability allows unauthorized access to information.<\/p>\n \n- High (C:H):<\/b> Demonstrated unauthorized access to sensitive information, such as another customer's PII, order or payment data, credentials, authentication tokens, or session tokens.<\/li>\n
- Low (C:L):<\/b> Demonstrated unauthorized access to limited non-public information with limited security impact.<\/li>\n
- None (C:N):<\/b> No unauthorized disclosure of non-public information. Access to public product, price, store, or equivalent publicly available data does not constitute a confidentiality impact.<\/li>\n<\/ul>\n
Integrity (I)<\/h3>\nIntegrity measures the extent to which a vulnerability allows unauthorized modification of protected data or system state.<\/p>\n \n- High (I:H):<\/b> Demonstrated unauthorized modification with significant security or financial impact, such as modification of another customer's order, payment or account data, or manipulation of prices or payment amounts that is accepted by the backend and successfully carried through the complete order or payment process.<\/li>\n
- Low (I:L):<\/b> Demonstrated unauthorized modification with limited security or financial impact.<\/li>\n
- None (I:N):<\/b> No effective unauthorized modification of protected data or system state.<\/li>\n<\/ul>\n
For price, order or payment manipulation, frontend or client-side changes alone do not constitute Integrity impact. The manipulated value must be accepted by the backend, successfully carried through the complete relevant process, and reflected in the final order, payment, transaction, or equivalent backend evidence. Intermediate states such as a checkout confirmation or temporary order creation are not sufficient if the manipulation is later rejected, corrected, or cancelled.<\/p>\n The following are not considered a valid price, order or payment manipulation:<\/p>\n \n- manipulated prices, quantities or discounts that are displayed on the client side but not charged<\/li>\n
- orders that are rejected, corrected or automatically cancelled by backend validation<\/li>\n
- orders for which no order confirmation email is sent<\/li>\n<\/ul>\n
To demonstrate a valid manipulation, the report must include the order confirmation email showing the manipulated amount, evidence that this amount was charged, and the order number. Please cancel any test order immediately after documenting it.<\/p>\n Availability (A)<\/h3>\nAvailability measures the impact of a vulnerability on the accessibility or operation of a system or service. Denial-of-service testing is out of scope. Availability impact may only be considered where it can be demonstrated without violating the program's testing rules.<\/p>\n \n- None (A:N):<\/b> No availability impact on other users is demonstrated.<\/li>\n
- Low (A:L):<\/b> A limited or temporary reduction in availability or performance for other users is demonstrated.<\/li>\n
- High (A:H):<\/b> A significant loss of availability for other users is demonstrated.<\/li>\n<\/ul>\n
Privileges Required (PR)<\/h3>\nPrivileges Required measures whether the attacker must already have access to an account or other privileges before exploiting the vulnerability.<\/p>\n \n- None (PR:N):<\/b> The vulnerability can be exploited without authentication or any existing privileges.<\/li>\n
- Low (PR:L):<\/b> Exploitation requires authentication with a regular customer account, including an account that anyone can create through the standard registration process.<\/li>\n
- High (PR:H):<\/b> Exploitation requires elevated or administrative privileges.<\/li>\n<\/ul>\n
User Interaction (UI)<\/h3>\nUser Interaction measures whether successful exploitation requires an action by another user.<\/p>\n \n- None (UI:N):<\/b> Exploitation succeeds without any action by another user.<\/li>\n
- Required (UI:R):<\/b> Successful exploitation requires another user to perform an action, such as clicking a link, opening attacker-controlled content, visiting a specific page, or otherwise interacting with the attack.<\/li>\n<\/ul>\n
Attack Complexity (AC)<\/h3>\nAttack Complexity measures whether successful exploitation depends on conditions beyond the attacker's control.<\/p>\n \n- Low (AC:L):<\/b> Exploitation does not depend on special conditions beyond the attacker's control. The attacker can reliably create or repeat the conditions required for exploitation.<\/li>\n
- High (AC:H):<\/b> Exploitation depends on conditions beyond the attacker's control, such as a specific victim configuration, a race condition, or other prerequisite conditions that the attacker cannot reliably create.<\/li>\n<\/ul>\n
The requirement to obtain, discover, or identify information does not by itself result in High<\/b> Attack Complexity. What matters is whether successful exploitation depends on conditions outside the attacker's control.<\/p>\nImpact Bonus<\/h2>\n MediaMarktSaturn may award an Impact Bonus of up to 50% where a finding demonstrates exceptional business impact that is not adequately reflected by the CVSS v3.1 Base Score.<\/p>\n Examples may include significant compromise of payment or checkout integrity, or impact affecting a large number of customers without requiring user interaction.<\/p>\n The Impact Bonus is separate from the CVSS severity assessment and does not change the CVSS score or severity of the report. For example, a High-severity vulnerability remains High even if an Impact Bonus results in a reward above the normal amount for its CVSS score.<\/p>\n The Impact Bonus is awarded at MediaMarktSaturn's discretion and can only increase the reward. The bonus is calculated as described under \"Reward calculation\" (step 4).<\/p>\n Fix bypasses<\/h2>\nIf a fix can be bypassed while the original report is still open, the bypass is treated as part of the original report and is not rewarded separately.<\/p>\n If a bypass is found after the original report has been closed as resolved, it can be submitted as a new report and will be assessed under the current program rules.<\/p>\n The OneFixOneReward rule still applies (see \"Reporting\").<\/p>\n If you disagree with the rating<\/h2>\nIf you disagree with the confirmed CVSS score or reward, submit your reasoning and any additional evidence in a single consolidated comment on the report.<\/p>\n The MediaMarktSaturn security team will re-evaluate the disputed metrics or reward decision and provide an explanation of the outcome.<\/p>\n The decision following this re-evaluation is final. Please keep rating and reward discussions within the report rather than reopening the same dispute through other channels.<\/p>\n REPORTS OF LEAKS AND EXPOSED CREDENTIALS<\/h2>\nIn the context of this program, we do not intend to encourage, accept or reward reports of leaks that are not applicable to our program\u2019s scope and identified outside of our program\u2019s scope, such as:<\/p>\n \n- Exposed credentials in\/from an out-of-scope asset\/source<\/li>\n
- Sensitive information exposed in\/from an out-of-scope asset\/source<\/li>\n<\/ul>\n
Also, in order not to encourage dark and grey economies, in particular the purchase, resale and trade of identifiers or stolen information, as well as all types of dangerous behaviour (e.g. social engineering, ...), we will not accept or reward any report based on information whose source is not the result of failure on the part of our organization or one of our employees\/service providers.<\/p>\n This excludes, but is not limited to:<\/p>\n |
|