GREE's Vulnerability Disclosure Announcement
Regarding GREE's Security Updates
In order to protect our customers, GREE will not disclose security issues until investigations are completed and comprehensive patches or release versions are ready. This announcement outlines information about recently patched vulnerabilities, along with their impact scope and the corresponding remedies.
If you believe you have identified security or privacy vulnerabilities in GREE products, please directly send security issues to:
For the vulnerabilities you submit, the corporate reviewer will try to complete the confirmation within 3 business days. Security updates for "critical security issues" will be released within 7 business days, while security updates for software-related "high-risk security issues" and "medium-risk security issues" will be released within 30 business days. Security updates for security vulnerabilities concerning firmware and hardware of smart products will be released within 180 business days. Please refer to the GREESRC Vulnerability Remediation Process and Grade Rating Criteria for vulnerability grading criteria.
Obtain the latest software update from GREE:
Download the link for the latest app version:
Please update your application promptly, as this is one of the most crucial steps in maintaining the security of GREE products.
Vulnerability Grade Rating Criteria
The vulnerability grading criteria are based on CVSS v3 (Common Vulnerability Scoring System), and vulnerabilities are categorized into five grades, namely [Critical], [High-risk], [Medium-risk], [Low-risk], and [No Impact], according to the impact of vulnerabilities on system confidentiality (C), integrity (I), and availability (A).
1. Vulnerabilities that can directly access core system privileges (server/client permissions), including but not limited to uploading Web Shells, arbitrary code execution, remote command execution, SQL injection to access core system privileges, etc.;
2. Critical information leakage vulnerabilities in the core system, including but not limited to SQL injection in core DB, extensive sensitive user identity information leakage (at least 3 sensitive fields: name/ID card, bank card information, phone number/email, passwords, address), internal core data leakage of enterprises, etc.;
3. Critical defects in the logical design or process of the core system, including but not limited to payment vulnerabilities allowing bulk modification of any account passwords, arbitrary account fund consumption, arbitrary amount modification, etc.;
4. Vulnerabilities critically impacting the availability of the core system, such as vulnerabilities of denial of service that can directly cause paralysis of core system business;
1. Vulnerabilities that can directly access important business system privileges (server/client permissions), including but not limited to arbitrary command execution, uploading Web Shells, arbitrary code execution, SQL injection to access core system privileges, etc.;
2. Vulnerabilities directly leading to the leakage of important information, including but not limited to SQL injection vulnerabilities in important DBs; leakage of extensive important business source codes; and SSRF vulnerabilities that enable access to internal networks and access sensitive information.
3. Critical unauthorized access, including but not limited to bypassing authentication to access important system backends; and operations such as unauthorized access, modification, and deletion of sensitive user information.
1. Vulnerabilities requiring interaction to access user identity information, including but not limited to stored XSS vulnerabilities in core and important systems; and CSRF for sensitive operations (payment, account information, etc.);
2. Arbitrary file operation vulnerabilities, including but not limited to arbitrary file reading, writing, deletion, uploading, downloading, etc.;
3. Ordinary unauthorized access, including but not limited to bypassing restrictions to modify user profiles, perform user operations, read user information; and bypassing restrictions to access non-core business system backends;
4. Moderately critical information leakage vulnerabilities, including but not limited to SQL injection and unauthorized access not involving important data; limited-range sensitive file leakage (e.g., DB connection passwords) and weak passwords for accounts (e.g., regular users, test users).
1. Reflective XSS; and non-critical system stored XSS;
2. Limited-harm unauthorized operations (e.g., unauthorized emptying/adding to cart);
3. Minor information leakage, including but not limited to Phpinfo; non-core system SVN information leakage; non-important information leakage (e.g., unusable DB connection passwords); and local SQL injection in client applications;
4. Vulnerabilities that are difficult to exploit but pose security risks, including but not limited to difficult-to-exploit SQL injection points; local denial of service in clients; and vulnerabilities under specific conditions or environments (e.g., SMS, email bomb, URL redirection);
5. Vulnerabilities that pose security risks but require extremely stringent conditions for exploitation, including but not limited to vulnerabilities only triggered on a specific version of a browser, and vulnerabilities requiring special configurations to trigger.
No Impact
1. Vulnerabilities not related to security issues, including but not limited to defects in website product functionality, garbled pages, mixed styles, URL skip at login, etc.
2. Vulnerabilities that cannot be exploited, replicated, or result in actual harm.
3. Other issues that have no impact on GREE's business.
Other issues not categorized within specific types will be comprehensively evaluated based on their actual harm and CVSS.
Vulnerability Remediation Process
GREESRC Vulnerability Remediation Process is as follows:
1.[Vulnerability Submitting]
The white hat logs in to the Butian account and submits vulnerability reports. Once a vulnerability is submitted, it cannot be edited or modified. Please ensure the accuracy of the vulnerability information before submitting it. After successful submission, the vulnerability status will be displayed as [Under Review].
2. [Vulnerability Review]
The corporate reviewer will conduct a preliminary review of the vulnerabilities within 3 business days (the review speed may slow down during statutory holidays or in the event of a vulnerability outbreak). Vulnerabilities that do not pass the preliminary review will be ignored or requested to provide additional information. White hats can supplement the information or engage in discussions below the vulnerability. If there are repeated vulnerabilities within the same time period, only the first complete report will be considered. For repeated vulnerabilities in different time periods, the first submission will be considered. Vulnerabilities that pass this stage will be displayed as [Pending Confirmation] in the status.
3.[Vulnerabilities Confirmation]
The corporate reviewer will confirm the vulnerabilities within 7 business days (extended during statutory holidays), and white hats will receive corresponding rewards once the vulnerabilities are confirmed. If there are any disputes regarding the confirmation level, a vulnerability appeal can be initiated within a validity period of 3 days, and the Butian platform will intervene and negotiate the resolution. During this stage, the status of the vulnerabilities will be displayed as [Pending Remediation].
4.[Vulnerability Remediation]
Vulnerability Remediation Platform:
Remediation Process:
((1) The asset owner receives a vulnerability notification email and simply needs to click on the vulnerability link in the email to be redirected to the vulnerability detail page for review. If not registered, after registering an account, the asset owner can review the number of vulnerabilities and detailed reports corresponding to the vulnerability status in the [My Vulnerability Management] menu.
(2) After reviewing the vulnerability report, the asset owner needs to click on the [Please Confirm Acknowledgment of the Vulnerability] button at the top or bottom of the vulnerability report page. Upon clicking, the vulnerability status will change from "New Notification" to "In Remediation". If the "Please Confirm Acknowledgment of the Vulnerability" button is not clicked, the vulnerability status will remain as "New Notification". The platform will send new vulnerability reminder emails to the relevant personnel every business day at 9:30 a.m.
(3) After remediating the vulnerability, the asset owner can open the [In Remediation] vulnerability report in [My Vulnerability Management] and then click on the [Apply for Retesting] button to access the application for the retesting page. After filling in the remediation method, the asset owner can submit the retesting application. The platform will automatically send a vulnerability retesting request email to the security personnel, and the vulnerability status will change to [Retesting in Progress]. If the asset owner is aware of the vulnerability but decides not to remediate it, they need to submit the "Vulnerability Risk Acceptance" process on the review platform. After the information security officer agrees to not remediate the vulnerability, the vulnerability remediation process is concluded.
(4) After receiving the retesting notification email, the security personnel retest the vulnerability. Once the retesting is completed, they can click on the [Submit Retesting Results] button on the platform to access the retesting result submission page. After the security personnel have completed the retesting, the platform will automatically send an email to inform the asset owner whether the vulnerability remediation has been verified. If it is verified, the vulnerability status will change to [Completed]. If it is not verified, the vulnerability status will change to [In Remediation]. The asset owner can continue with the remediation process and apply for retesting again.
5. [Vulnerability Closed]
The enterprises confirm vulnerability remediation completion and close the vulnerability. Vulnerability remediation process is complete.
To submit a GREESRC vulnerability, white hats must accept the Butian User Service Agreement and observe the White Hat Code of Conduct. Without the manufacturer's permission, it is strictly prohibited to publicly disclose any vulnerabilities submitted to GREESRC (including ignored vulnerabilities). Violators will have their awarded rewards deducted and shall be subject to legal consequences depending on the severity of the situation.