Ackaia Corporation Responsible Disclosure Policy#

Ackaia Corporation v1.00.00 April 27, 2026 1233 York Avenue, Apt. 301 New York, NY 10065 United States of America www.ackaia.com

Effective Date: April 27, 2026

Publisher: Ackaia Corporation, 1233 York Avenue, New York, NY 10065, United States

(“Ackaia”, “Ackaia Corp.”, “we”, “our”, “us”)

Applies To: Ackaia One, Ackaia ID, Ackaia Cloud Services (“ACS”), Ackaia websites, public

repositories, APIs, and related services, unless a separate security policy applies.

Revision History#

1. Purpose#

Ackaia builds privacy-first infrastructure. Our products are designed to protect user data, reduce unnecessary access to sensitive information, and provide transparent security architecture where possible. Security researchers, developers, users, and the broader community play an important role in helping us identify and fix vulnerabilities. This Responsible Disclosure Policy explains how to report security issues to Ackaia safely, lawfully, and constructively. We welcome good-faith vulnerability research that helps improve the security of Ackaia services. At the same time, research must not harm users, access data that does not belong to the researcher, disrupt availability, bypass safety systems for abusive purposes, or publicly expose unresolved vulnerabilities in a way that increases risk. This Policy is intended to create a clear, respectful process for receiving, validating, remediating, and disclosing security issues.

2. Scope#

This Policy applies to security research involving Ackaia-owned or Ackaia-operated systems, including:

• Ackaia One;

• Ackaia One Storage;

• Ackaia ID;

• Ackaia Cloud Services;

• Ackaia-owned websites and dashboards;

• Ackaia-operated APIs;

• Ackaia public or source-available repositories;

• Ackaia cryptographic documentation and public protocol descriptions;

• Ackaia-controlled subdomains;

• authentication, session, account, billing, and public sharing flows.

Ackaia may publish separate scope definitions for specific programs, repositories, or products. If a separate scope document exists, the more specific scope controls. Systems operated by third parties are not automatically in scope, even if Ackaia uses or links to them.

3. Out of Scope#

The following are generally out of scope unless Ackaia expressly authorizes them in writing:

• third-party services not controlled by Ackaia;

• payment processor infrastructure;

• hosting provider infrastructure not directly controlled by Ackaia;

• social media accounts;

• third-party GitHub actions, package registries, or CDN systems not controlled by Ackaia;

• denial-of-service testing;

• spam testing;

• physical attacks;

• social engineering;

• phishing against Ackaia employees, contractors, users, or customers;

• attempts to access, modify, delete, or exfiltrate user data;

• malware deployment;

• attacks against end-user devices;

• attempts to bypass the Risk Assessment Engine for the purpose of uploading, distributing, or concealing prohibited content;

• testing involving child sexual abuse material, illegal content, stolen data, live malware, or real credentials that do not belong to you.

If you are unsure whether a target or technique is in scope, contact Ackaia before testing.

4. Safe Harbor#

Ackaia will not pursue legal action against good-faith security research conducted in accordance with this Policy, provided that you:

• act to improve Ackaia security;

• avoid harm to users, third parties, and Ackaia infrastructure;

• do not access, exfiltrate, modify, delete, or disclose data that does not belong to you;

• do not disrupt, degrade, or impair the Service;

• do not use social engineering, phishing, extortion, coercion, or threats;

• report the vulnerability promptly and privately to Ackaia;

• give Ackaia a reasonable opportunity to investigate and remediate before public disclosure;

• stop testing immediately if you encounter personal data, user content, secrets, tokens, keys, or confidential information;

• comply with applicable law.

This safe harbor does not authorize illegal activity. It also does not bind third parties, law enforcement, regulators, payment processors, infrastructure providers, or other entities outside Ackaia’s control.

5. Research Rules#

When conducting research, you must follow these rules. 5.1 Do Not Harm Users You must not intentionally access, read, copy, alter, delete, lock, encrypt, disclose, or exfiltrate data that belongs to another user. If you accidentally encounter data that does not belong to you, stop immediately, do not save or share the data, and report the issue to Ackaia. 5.2 Do Not Disrupt the Service You must not perform denial-of-service testing, stress testing, resource exhaustion, bandwidth draining, mass account creation, spam, public-link abuse, automated destructive scanning, or any activity that could impair service availability. 5.3 Do Not Target People You must not conduct social engineering, phishing, vishing, smishing, impersonation, physical intrusion, bribery, harassment, coercion, or credential theft against Ackaia employees, contractors, users, customers, vendors, or partners. 5.4 Do Not Use Real Illegal or Harmful Material You must not use CSAM, exploitative content, live malware, stolen credentials, stolen personal data, payment-card data, or other illegal or harmful material as part of testing. If your research involves content safety systems, use benign test files and contact Ackaia for guidance. 5.5 Use Your Own Accounts and Data Testing should be performed only against accounts, files, keys, links, devices, and data that you own or are expressly authorized to use. 5.6 Minimize Data and Impact Use the least intrusive method possible to prove a vulnerability. Avoid persistence, lateral movement, privilege escalation beyond what is necessary for proof, automated high-volume testing, and any action that increases risk. 5.7 Preserve Confidentiality Do not publicly disclose details, proof-of-concept code, exploit chains, screenshots, logs, secrets, or vulnerability information until Ackaia has had a reasonable opportunity to remediate and coordinate disclosure.

6. Vulnerabilities We Want to Know About#

Ackaia welcomes reports involving vulnerabilities such as:

• authentication bypass;

• account takeover;

• authorization failures;

• access to another user’s files or metadata;

• public link access-control bypass;

• insecure direct object references;

• cross-site scripting with meaningful security impact;

• cross-site request forgery with meaningful security impact;

• server-side request forgery;

• SQL injection;

• remote code execution;

• command injection;

• file upload vulnerabilities;

• insecure deserialization;

• sensitive data exposure;

• secret leakage;

• API authorization flaws;

• session fixation or session invalidation failures;

• privilege escalation;

• cryptographic implementation errors;

• incorrect key wrapping or key derivation behavior;

• AES-GCM nonce or IV reuse risks;

• flaws in encrypted sharing logic;

• local key storage vulnerabilities with practical exploitation path;

• bypasses of security-critical rate limits;

• vulnerabilities in source-available cryptographic components.

For Ackaia One specifically, we are especially interested in reports involving:

• ability for Ackaia servers to decrypt user files unexpectedly;

• exposure of plaintext file keys;

• exposure of master keys;

• cross-account file access;

• public share link bypass;

• metadata leakage beyond documented behavior;

• broken AES-GCM IV uniqueness;

• flawed key derivation or key wrapping;

• unsafe browser key persistence;

• XSS that can steal local cryptographic material;

• upload/download logic that corrupts or misdecrypts files;

• attacks that bypass zero-knowledge assumptions.

7. Lower-Priority or Generally Non-Qualifying Issues#

The following may be considered low priority or non-qualifying unless they demonstrate a clear, practical security impact:

• missing security headers without exploitability;

• clickjacking on pages with no sensitive actions;

• logout CSRF without meaningful impact;

• self-XSS requiring a user to paste code into their own console;

• rate limits that do not protect a security-sensitive action;

• username or email enumeration without additional impact;

• SPF, DKIM, or DMARC issues without demonstrated abuse path;

• outdated software version banners without exploitability;

• theoretical cryptographic concerns without practical exploitability;

• reports generated solely by automated scanners without validation;

• social engineering hypotheticals;

• issues requiring full compromise of the user’s device unless the vulnerability makes that compromise materially worse;

• local attacks requiring root/admin access to the user’s device;

• public information disclosure that is intentionally published;

• duplicate reports of already known issues.

Ackaia may still review and fix lower-priority issues at its discretion.

8. How to Report a Vulnerability#

Please report security issues to: Security Contact: security@ackaia.com Your report should include:

• a clear description of the vulnerability;

• affected product, domain, endpoint, repository, or component;

• steps to reproduce;

• proof of concept, if safe and non-destructive;

• expected behavior;

• actual behavior;

• security impact;

• whether user data, keys, sessions, or metadata may be affected;

• screenshots, logs, or videos if helpful and safe;

• suggested remediation, if available;

• your contact information;

• whether you intend to request public credit.

Do not include sensitive user data, secrets, private keys, access tokens, passwords, CSAM, illegal content, or third-party confidential information in your report. If you believe your report requires encrypted communication, use Ackaia’s published PGP key or ask for a secure reporting channel.

9. What Happens After You Report#

Ackaia aims to handle security reports through the following process. 9.1 Acknowledgment Ackaia will attempt to acknowledge receipt of your report within a reasonable period, typically within 3 business days. 9.2 Triage Ackaia will review the report, attempt to reproduce the issue, assess severity, determine affected systems, and evaluate potential impact. Ackaia may ask for clarification or additional details. 9.3 Remediation If the report is valid, Ackaia will work to remediate the issue based on severity, complexity, exploitability, user impact, and operational risk. Possible remediation may include:

• code changes;

• configuration changes;

• key rotation;

• session revocation;

• access-control fixes;

• cryptographic protocol migration;

• account-level mitigation;

• infrastructure hardening;

• documentation changes;

• user notification where appropriate or legally required.

9.4 Verification Ackaia may ask you to verify that the fix addresses the issue, provided that testing can be done safely and within this Policy. 9.5 Coordinated Disclosure Ackaia supports coordinated disclosure. Public disclosure should occur only after Ackaia has remediated the issue or after a mutually agreed disclosure timeline.

10. Severity Assessment#

Ackaia may consider the following factors when assessing severity:

• whether user file contents can be accessed;

• whether encryption keys can be exposed;

• whether accounts can be taken over;

• whether cross-account data access is possible;

• whether public links can be bypassed;

• whether billing or subscription controls can be bypassed;

• whether security systems can be disabled;

• whether the vulnerability is remotely exploitable;

• whether exploitation requires user interaction;

• whether exploitation is scalable;

• whether the issue affects production or only a development/test environment;

• whether the issue affects confidentiality, integrity, or availability;

• whether the issue affects child-safety, abuse-prevention, or legal compliance systems.

For Ackaia One, vulnerabilities affecting cryptographic keys, encrypted file confidentiality, public sharing access control, account takeover, or server-side ability to decrypt files unexpectedly are treated as especially serious.

11. Cryptography-Specific Reports#

Because Ackaia publishes or may publish source-available cryptographic components, we welcome cryptography-focused reports. Examples include:

• AES-GCM IV reuse;

• insufficient randomness;

• weak KDF parameters;

• flawed key wrapping;

• incorrect AAD handling;

• unsafe metadata encryption;

• file key exposure;

• master key exposure;

• share-link key leakage;

• downgrade attacks;

• insecure legacy compatibility behavior;

• decryption oracle risks;

• predictable salts or nonces;

• key persistence risks that exceed documented behavior;

• mismatch between public security claims and implementation.

Cryptographic reports should include enough detail for Ackaia to understand the risk, reproduce the issue, and evaluate impact. Please distinguish between:

• theoretical improvement suggestions;

• implementation bugs;

• protocol design weaknesses;

• documentation inaccuracies;

• vulnerabilities with practical exploit paths.

12. Risk Assessment Engine and Abuse-Prevention Systems#

Ackaia may operate systems such as the Risk Assessment Engine to detect severe abuse, including CSAM, malware, fraud, and other prohibited content. Research into these systems must be handled with exceptional care. You may not:

• upload CSAM or illegal content;

• test with real exploitative material;

• attempt to bypass safety systems for abusive purposes;

• intentionally trigger child-safety systems with illegal material;

• disclose methods that enable evasion of abuse-prevention systems;

• disrupt safety systems;

• use malware or stolen data in tests.

If you believe you have found a vulnerability in abuse-prevention or safety systems, report it privately without providing evasion instructions beyond what is necessary for Ackaia to understand and remediate the issue. Ackaia may withhold public details about vulnerabilities in abuse-prevention systems where disclosure would enable harm, evasion, exploitation, or child-safety risk.

13. Public Disclosure Rules#

You must not publicly disclose a vulnerability until:

• Ackaia has confirmed remediation;

• Ackaia has stated that disclosure is acceptable; or

• a coordinated disclosure timeline has expired and you have made reasonable efforts to work with Ackaia.

A standard disclosure timeline may be: 90 days after validated report. However, Ackaia may request additional time for complex issues, cryptographic migrations, infrastructure changes, legal constraints, or issues that create serious risk if disclosed too early. For vulnerabilities involving CSAM detection, abuse-prevention systems, active exploitation, user data exposure, cryptographic key exposure, or severe infrastructure risk, public disclosure may require additional coordination or redaction. Ackaia may publicly credit researchers who follow this Policy and request recognition.

14. Rewards and Bounties#

Unless Ackaia publishes a separate bug bounty program, this Policy does not guarantee payment, bounty, reward, employment, contract work, or compensation for reports. Ackaia may, at its discretion, provide recognition, public credit, swag, compensation, or other rewards for high-quality reports, but is not obligated to do so unless a separate written bug bounty program states otherwise. Do not demand payment in exchange for withholding disclosure. Demands, threats, extortion, or coercive behavior are not permitted and are not protected by this Policy.

15. Public Credit#

If you would like public credit, include the preferred name, handle, organization, or link in your report. Ackaia may provide credit in release notes, security advisories, repository acknowledgments, or a security hall of fame. Ackaia may decline or delay public credit where:

• disclosure would create risk;

• the report involved prohibited conduct;

• the vulnerability is still under investigation;

• legal or safety constraints apply;

• the researcher requests anonymity;

• the report is duplicate, invalid, or low-impact.

16. Confidentiality#

Security reports and communications with Ackaia should be treated as confidential until disclosure is coordinated. You must not share vulnerability details with third parties, publish proof-of-concept exploit code, post screenshots, disclose affected endpoints, or describe exploitation steps before coordinated disclosure. Ackaia will also make reasonable efforts to handle your report confidentially, subject to legal obligations, safety needs, remediation requirements, and disclosure to necessary service providers, advisors, or authorities.

17. Legal Requests and Illegal Content#

If your report involves suspected illegal content, child exploitation, stolen data, malware, or active abuse, do not download, copy, redistribute, or include the content in your report. Provide only the minimum necessary information, such as:

• URL or object identifier;

• account or public link, if known;

• timestamps;

• description of the issue;

• why you believe abuse is occurring.

Do not send CSAM or illegal content to Ackaia. Ackaia may preserve and report relevant information to appropriate authorities or organizations where required or appropriate.

18. Termination of Safe Harbor#

Ackaia may determine that your conduct falls outside this Policy if you:

• access, modify, delete, or disclose data that does not belong to you;

• disrupt the Service;

• use threats, extortion, or coercion;

• perform social engineering;

• use illegal content or live malware;

• continue testing after being asked to stop;

• publicly disclose before coordination;

• act in bad faith;

• violate applicable law;

• attempt to monetize the vulnerability through pressure or unauthorized disclosure;

• use the vulnerability for personal gain beyond responsible reporting.

If safe harbor no longer applies, Ackaia may take appropriate action to protect users, systems, and legal rights.

19. No Permission to Violate Other Policies#

This Responsible Disclosure Policy does not grant permission to violate:

• Ackaia’s Terms of Service;

• Ackaia’s Privacy Policy;

• Ackaia’s Acceptable Use & Abuse Policy;

• applicable law;

• third-party terms;

• user privacy;

• child-safety protections;

• intellectual property rights.

Where there is a conflict, this Policy permits only narrow good-faith security testing that complies with its rules.

20. Changes to This Policy#

Ackaia may update this Policy from time to time to reflect changes in products, systems, legal requirements, security practices, disclosure processes, or research scope. When changes are material, Ackaia may provide notice through its website, repository, security page, or other appropriate means. The version in effect at the time of your testing applies to your research, unless Ackaia expressly agrees otherwise.

21. Contact#

Ackaia Corp.​ Security Contact: security@ackaia.com​ Legal Contact: legal@ackaia.com​ Website: www.ackaia.com​ Address: 1233 York Avenue, New York, NY 10065, United States of Amerrica For abuse, CSAM, or child-safety reports, use the appropriate abuse or child-safety contact instead of attaching illegal material to a security report. End of Policy