1. Basic Principles

1.1 Akuvox attaches great importance to the security of its products and business. We encourage external security researchers and experts to report vulnerabilities to improve business security and protect user information. We commit that every security disclosure will be evaluated and analyzed by dedicated personnel, with timely feedback on the latest progress.

1.2 Akuvox supports responsible vulnerability disclosure and handling. We pledge to thank and reward, to the reasonable extent at our discretion, external security researchers and experts who help Akuvox protect user interests and enhance security quality.

1.3 Akuvox opposes and condemns any hacking activities that use vulnerability testing as a pretext to exploit security flaws for malicious purposes, including but not limited to stealing user privacy and virtual assets, invading business systems, unauthorized access to system (business) data, data theft, or maliciously spreading vulnerabilities or data. Please do not discuss or disclose product vulnerabilities or intelligence details on any public occasion or platform without the permission from Akuvox. We reserves the right to pursue legal responsibility for such actions.

1.4 The Cybersecurity Law of the People's Republic of China and The Regulations on the Management of Security Vulnerabilities in Network Products have been officially enacted in China. We urge white hat hackers to comply with these regulations to avoid unnecessary legal risks.

1.5 Akuvox believes that effective vulnerability management and the advancement of the security industry depend on collaborative efforts. We are committed to strengthening partnerships with industry peers, security firms, and researchers to collectively safeguard information security.

2. Vulnerability Handling Process

Vulnerability Submission

Reporters should send emails to asrc@akuvox.com to report discovered security vulnerabilities.

Vulnerability Review Stage

Within three working days, the Akuvox Security Response Center (ASRC) will acknowledge receipt of the report and begin an initial assessment. A full evaluation and response will be provided within five working days. If needed, we will engage with reporters to request further information or assistance.

Vulnerability Remediation Stage

Once a vulnerability is confirmed, the relevant department will initiate remediation. The timeline for fixes depends on the severity and complexity of the issue, with some repairs aligned to version release schedules. Critical or high-impact vulnerabilities will be promptly addressed through urgent security advisories.

3. General Vulnerability Severity Ratings

Vulnerabilities are categorized into five severity levels based on their impact: Critical, High, Medium, Low, and Ignored.

Critical

• Direct compromise of core system privileges (server or client), including but not limited to command injection, remote command execution, WebShell upload, SQL injection leading to system-level access, remote kernel code execution, or other remote code execution vulnerabilities caused by logic flaws.

• Severe logic design flaws, including but not limited to severe problems affecting critical business systems, such as arbitrary account login, unauthorized password changes, unauthorized fund transfers, order manipulation, or payment processing vulnerabilities.

• Significant information leakage, including but not limited to large-scale extraction of sensitive data through SQL injection or privilege escalation via interfaces.

High

• Vulnerabilities that can directly compromise user identity information, such as stored XSS on critical pages or SQL injection on common sites.

• Unauthorized access issues, including but not limited to authentication bypass to admin backends, weak admin passwords exposing sensitive data, or front-end tampering.

• High-risk information disclosures, including but not limited to leaks of source code archives.

• High-risk SSRF vulnerabilities—supporting multiple protocols—capable of probing internal services to steal critical internal data or obtaining internal server privileges.

• Critical logic flaws like bypassing SMS/email verification or brute forcing verification codes, potentially enabling arbitrary login or password reset.

Medium

• Vulnerabilities requiring user interaction to compromise information, including but not limited to reflected XSS (including reflected DOMXSS), CSRF attacks that can steal sensitive data or privileges, and stored XSS in standard business functions.

• Common information leaks, including but not limited to compressed files containing sensitive data like database passwords.

• Typical unauthorized operations, including but not limited to improper direct object references.

• Standard logic flaws, including but not limited to bypassing verification in non-authentication modules or brute forcing verification codes.

• SQL injection vulnerabilities in non-critical business areas with higher exploitation difficulty.

Low

• Minor information leaks, including but not limited to path disclosures, SVN information, log files, accounts and passwords of internal systems, or non-sensitive source code or passwords exposed on GitHub.

• Issues that are difficult to exploit but may pose potential risks, including but not limited to Self-XSS, file parsing vulnerabilities, plaintext password transmission over HTTP, or session tokens not invalidated after logout.

• Denial of service vulnerabilities, such as vulnerabilities that can cause website denial of service without requiring a large amount of resources.

• Unauthorized access to non-sensitive management systems or test databases without further exploit potential.

Ignored

• Issues without actual security impact, including but not limited to product defects, garbled pages, styling inconsistencies, or non-sensitive error messages that cannot be reproduced.

• Unexploitable or low-value vulnerabilities, including but not limited to meaningless directory traversal, 401 basic auth phishing, non-exploitable encoding flaws, Self-XSS, harmless CSRF, trivial information leaks, false positives from scanners, JSON hijacking without sensitive data, files limited to JS or images, general logcat information, plaintext username transmission, iframe phishing, or missing SSL/TLS best practices.

• Other non-vulnerability concerns, including but not limited to user speculation, test pages without sensitive data, SSRF without access to internal servers, Simply access dnslog, theoretical vulnerabilities without practical exploits, use of vulnerable libraries without direct exploitability, or suboptimal security configurations.

• Non-core client local denial of service (DoS) vulnerabilities, including but not limited to DoS caused by unvalidated component parameters; unauthorized access to ordinary operation and maintenance management systems without access to sensitive data or other exploitable resources; Slowhttptest attacks with no actual impact; and distributed denial of service (DDoS) attacks requiring significant resources or cost to execute. Web-based man-in-the-middle (MITM) hijacking issues are also included. Scan results from third-party tools or online platforms cannot be accepted as definitive proof of vulnerabilities if they lack specific descriptions, verification methods, and impact assessments. Reports indicating that a site uses HTTP instead of HTTPS are not considered security issues. Similarly, reports of open ports without demonstrated exploitation methods, such as open MySQL services without proof of exploitability, are not valid. Vulnerabilities that cannot be reproduced are excluded.

• Violations of security design principles without demonstrated exploitation methods—such as weak password policies, unsuccessful brute force attempts, static file XSS, harmless open actuator endpoints such as prometheus, and low concurrency issues—are also not considered valid vulnerabilities.

• Non-critical account-related issues with limited impact, including but not limited to username or phone number enumeration, zombie account registrations, captcha failures, credential stuffing, mail or SMS flooding, and vulnerabilities confirmed as unreproducible by the ASRC.

4. IoT Vulnerability Severity Ratings

Vulnerabilities are classified into five levels based on their impact: Critical, High, Medium, Low, and Ignored.

Critical

• Vulnerabilities enabling remote command execution or arbitrary code execution without user interaction, allowing full remote control of the device and theft of private information stored on it.

• Vulnerabilities causing permanent remote denial of service (DoS), including but not limited to attacks that render the device completely unusable or require a full operating system reflash.

Note: Proof of exploit (PoC) or demonstration of vulnerability feasibility is required.

High

• Vulnerabilities allowing remote acquisition of non-privileged system access, including but not limited to remote command execution, arbitrary code execution, or non-interactive command execution within a local network that exposes private device information.

• Note: Proof of exploit (PoC) or demonstration of vulnerability feasibility is required.

• Vulnerabilities causing device denial of service, including but not limited to permanent DoS from local attacks (device rendered unusable or requiring OS reflash) and temporary DoS from remote attacks (device hang or reboot).

• Remote privilege escalation vulnerabilities including but not limited to vulnerabilities that bypass user consent or initiation requirements to perform sensitive operations.

• Privilege bypass vulnerabilities, including but not limited to deep kernel-level protection bypass, exploitation of mitigation flaws, local bypass of user-function restrictions to modify developer or security settings, or full bypass of application sandboxing and OS protections.

• Local vulnerabilities enabling system privilege escalation, including but not limited to local privilege escalation vulnerabilities.

Medium

• Vulnerabilities involving command execution within a local network that require user interaction or authorization and can only be triggered under strict conditions, with significant impact potential.

• Vulnerabilities causing temporary denial of service, including but not limited to those triggered by local attacks.

• Privilege bypass vulnerabilities, including but not limited to deep user-level protection bypass, exploitation of mitigation flaws in privileged processes, or bypassing device protection mechanisms.

• Local unauthorized operation vulnerabilities, including but not limited to those bypassing user consent or initiation to perform sensitive operations.

• Remote unauthorized access to non-sensitive controlled data.

Low

• Unsafe configurations (issues that are difficult to exploit or have minimal impact will be disregarded). Low-risk information leaks that require physical access and cause only information disclosure or pose security risks; denial of service (DoS) within a local network, or DoS that requires user interaction to exploit.

• Privilege bypass vulnerabilities, including but not limited to deep user-level protection bypass, exploitation of mitigation flaws in non-privileged processes, or local bypass of system permission controls to access non-sensitive controlled user data.

• Local unauthorized operation vulnerabilities, including but not limited to invoking hidden system functions without user interaction, causing actual user inconvenience or loss.

Ignored

• Low-impact denial of service issues: software functional errors without security impact, application-level crashes, simple prompt dialogs, temporary framework restarts.

• Missing certificate pinning; transmission of sensitive data within TLS-protected URLs or request messages.

• Sensitive information storage inaccessible to apps with normal privileges; logs or system test data with no actual user impact.

• User data stored unencrypted on external storage (except for app logs containing sensitive information and user data promised to be encrypted).

• Apps lacking code obfuscation protection, APKs that can be repackaged, apps containing hardcoded or recoverable keys, or lacking binary protection controls.

• Attacks that require physical contact to damage device hardware integrity.

• Attacks launched in developer mode (exceptions may be made for significant issues such as privilege escalation).

• Open-source or third-party vulnerabilities affecting multiple industry devices (exceptions may be made for vulnerabilities with significant device impact).

• Vulnerabilities that require certain permissions to be successfully exploited and cause impact, where those permissions themselves already allow the same effect.

• Reports that only mention the possibility of a vulnerability without describing exploitation methods, scanner results without proof of actual harm, or vulnerability reports based on illegally obtained confidential information.

5.General Evaluation Principles

• The evaluation criteria apply exclusively to Akuvox’s products and services. Vulnerabilities unrelated to Akuvox are not eligible for rewards.

• Multiple vulnerabilities stemming from the same root cause will be counted as a single issue. Examples include multiple problems caused by a specific server configuration, a global feature of an application framework, the same file or template, or wildcard domain resolution.

• Vulnerabilities whose technical details (e.g., proof of concept) have been publicly disclosed prior to submission—including but not limited to on websites, social media, mailing lists, public talks, or instant messaging groups—are ineligible for the bug bounty program.

• For duplicate submissions of the same vulnerability scenario or root cause by different individuals or the same reporter, only the first valid submission will be accepted; subsequent reports will be disqualified. Due to the extended patch cycles for hardware, system, and architecture-related vulnerabilities (including n-day vulnerabilities), re-acceptance of such vulnerabilities will be based on the internal security ticket closure date.

• Vulnerabilities in non-critical business system websites may be downgraded in severity based on their impact scope, while vulnerabilities affecting critical business systems with broad impact may be upgraded accordingly.

• Exploiting vulnerabilities under the guise of testing to harm user interests, disrupt business operations, disclose vulnerabilities before fixes, or steal user data will result in disqualification from rewards. Akuvox reserves the right to pursue further legal actions in such cases.