Security
Security & responsible disclosure
XMAKYNA accepts good-faith reports of suspected security vulnerabilities affecting XMAKYNA-controlled assets. Use the minimum testing necessary to establish an issue, avoid harm, and do not include passwords, access tokens, private keys or unnecessary personal data in the initial report.
Reporting a security issue
Use the security address below for vulnerability reports, responsible disclosure and external security reports. Use a clear subject line identifying the affected asset.
If you believe there is active exploitation, imminent material harm or a currently exposed credential, key or other secret, identify the message as urgent. If sensitive evidence is genuinely required, ask us to arrange an appropriate exchange method.
What to include
Identify the affected XMAKYNA asset, product, page, endpoint, version or component; describe the vulnerability and its likely security impact; and provide concise reproduction steps or a minimal proof of concept.
Relevant request or response details, screenshots, logs or timestamps can be useful where secrets and unrelated personal data have been removed or redacted. A report does not need to be perfectly formatted; clear, reproducible and proportionate evidence is more useful than intrusive testing or a large data dump.
Scope
This policy applies to XMAKYNA-controlled applications, websites on xmakyna.com and other digital assets that XMAKYNA owns or operates, together with any additional asset that XMAKYNA expressly identifies as in scope.
Third-party platforms, cloud providers, app stores, telecommunications networks and other infrastructure that XMAKYNA does not control are not authorised testing targets under this policy. If an issue appears to arise from XMAKYNA's own configuration or integration with a third party, demonstrate only what can safely be established from the XMAKYNA side and avoid testing the third party's systems.
If you are unsure whether an asset is in scope, contact security@xmakyna.com before testing beyond ordinary public interaction.
Good-faith research
Act to avoid harm to users, XMAKYNA and third parties. Use the minimum testing necessary to establish that a vulnerability exists, and stop and report promptly if you encounter personal data, confidential information, credentials, secrets or data belonging to another person.
Do not retain, alter, delete, publish or unnecessarily copy data that is not yours. Do not establish persistence or maintain access after demonstrating an issue. Avoid activity that could degrade a service or cause operational disruption, and give XMAKYNA a reasonable opportunity to investigate and remediate before public disclosure.
Prohibited or unsafe testing
Denial-of-service, distributed denial-of-service, resource-exhaustion attacks, social engineering, phishing, impersonation, malware deployment, destructive activity, credential stuffing, password spraying, physical intrusion, unnecessary data access or exfiltration, and testing of third-party systems are not authorised by this policy.
Bulk unsolicited messaging, automated scanning that materially degrades a service and excessive traffic generation are also outside the scope of authorised testing.
If you encounter data, credentials or secrets
If testing unexpectedly exposes personal data, confidential Company information, credentials, access tokens, keys or other secrets, stop at the minimum point necessary to establish the issue.
Do not use the information for another purpose or retain unnecessary copies. Where possible, describe what was exposed without sending the underlying sensitive material. XMAKYNA may ask for a limited sample or arrange a safer exchange method if that is genuinely necessary to verify the issue.
Response targets
We aim to acknowledge a credible report within five business days and provide an initial substantive assessment within fifteen business days where the report contains enough information to investigate.
An initial assessment may confirm that the issue is being investigated, request further information, or explain that the report is out of scope, a duplicate, not reproducible or not considered a security vulnerability.
For an accepted report under active investigation, we will provide material updates where appropriate and will notify the reporter when the issue is resolved, mitigated or otherwise dispositioned.
These are communication targets, not security-triage, remediation or statutory-reporting deadlines. XMAKYNA may escalate a report immediately where it indicates active exploitation, exposed credentials or secrets, compromise of personal data, a severe security incident or another urgent risk.
Public vulnerability-disclosure timelines do not extend, pause or replace any applicable legal or regulatory deadline. Where applicable, this includes shorter security, privacy or regulatory reporting periods. Those obligations are handled independently of the timetable for communicating with the security reporter.
These targets are not contractual guarantees. Complexity, reproduction difficulty, third-party dependencies, legal obligations or the need for a safer coordinated fix may require a different timetable.
Triage and remediation
XMAKYNA assesses reports according to the actual security risk, including impact, exploitability, affected systems or users, data sensitivity, required privileges, attack complexity, exposure, evidence of active exploitation and the availability of practical mitigations.
A report may be closed as not reproducible, informational, intended behaviour, a duplicate, out of scope or not a security vulnerability. Where appropriate, we will explain the disposition.
Remediation may involve a code change, configuration change, dependency update, access-control change, compensating control, feature change, documentation change or another proportionate treatment of the identified risk.
Coordinated disclosure
For accepted vulnerabilities, our normal aim is to coordinate remediation and any public disclosure within ninety calendar days where reasonably practicable.
A shorter period may be appropriate where active exploitation, widespread public knowledge or another urgent safety consideration makes earlier disclosure necessary. A longer period may be appropriate where a complex fix, dependency, coordinated upstream change or other genuine technical constraint requires additional time.
We ask reporters not to publicly disclose vulnerability details while active coordination is continuing without first discussing the timing with XMAKYNA. We do not require a reporter to sign a non-disclosure agreement as a condition of submitting or initially discussing a good-faith vulnerability report.
If a report is valid and you would like public credit, tell us. Any acknowledgement is discretionary, subject to your consent, and may be delayed until disclosure is safe.
Legal position on good-faith research
Where you act in good faith, stay within this policy, take reasonable steps to avoid privacy or security harm, promptly report the issue and comply with applicable law, XMAKYNA LTD will not initiate legal action solely because of that compliant security research, to the extent that the relevant claim is within XMAKYNA's control.
If your activity accidentally exceeds this policy, stop the activity, avoid further access or collection and tell us what happened. We will consider the circumstances and your good-faith efforts to minimise harm.
This statement does not bind third parties, service providers, regulators or law-enforcement authorities. It does not authorise conduct prohibited by applicable law, grant access to third-party systems, waive rights unrelated to compliant research, or create an employment, agency or contractual relationship with the reporter.
Rewards
XMAKYNA does not operate a standing monetary bug-bounty programme under this policy. Submission of a report does not create a right to payment, compensation, reimbursement or another reward. Any reward or recognition would require separate express agreement by XMAKYNA.
Privacy of security reports
Submitting a security report is a voluntary interaction with XMAKYNA and is not part of the normal use of XMAKYNA products or a general user-data collection process.
A security report may nevertheless contain information such as the reporter's contact details, technical identifiers, logs, screenshots or incident evidence. XMAKYNA uses that information where necessary for security triage, investigation, remediation, coordination, accountability and the establishment, exercise or defence of legal rights.
Access is restricted to people and advisers who need the information for those purposes. Please minimise personal data in reports and avoid sending unrelated personal information.
The general principles governing XMAKYNA's handling of personal information, including retention and individual rights, are explained in Privacy at XMAKYNA.
For privacy and data-protection enquiries or rights requests, privacy@xmakyna.com is the preferred contact route. A privacy request will not cease to be a privacy request merely because it is received through another XMAKYNA contact address.
Statutory escalation
Where a security report provides credible evidence of an event that may trigger a legal or regulatory reporting obligation, XMAKYNA will escalate it through the applicable security, privacy and regulatory processes without waiting for the ordinary vulnerability-disclosure timetable.
This may require notification to regulators, authorities or affected users before investigation, remediation or coordinated public disclosure is complete. XMAKYNA will preserve relevant awareness times and evidence so that applicable reporting periods can be assessed and met.
Public acknowledgement, investigation and coordinated-disclosure targets do not replace or extend any shorter statutory reporting or user-notification obligation that applies to a particular event.
