AIRON TEAM SL («AIRON») provides a single, public and stable channel for anyone to
report security vulnerabilities in its products and services, and commits to verifiable response times. This page is
the policy URL referenced by our /.well-known/security.txt file (RFC 9116).
1. How to report
- Email: security@airon.team.
- Languages: Spanish and English.
- What to include: affected component and URL, version, description, reproduction steps, estimated impact, a minimal proof of concept, and — if you accessed any data — which data and whether you retained it.
- What NOT to do: do not publish before coordination, do not exfiltrate or retain customer data, do not modify or delete data belonging to others, and do not access more data than strictly necessary to demonstrate the flaw.
2. Scope
In scope: the app.airon.team platform, the public site airon.team and its download areas,
the crm.airon.team CRM, the Android app, the browser extension, the Excel add-in, and AIRON’s APIs and
webhooks.
Also in scope: RON, AIRON’s AI teammate, with its cloud computer (vnc.airon.team) and what it can do on
a person’s behalf. It is a vulnerability if an instruction hidden in an email, a website or a document (prompt
injection) makes the AI act without a person’s approval, bypass the company’s permissions or send data out: test
it only with your own data and connections.
Out of scope because they are not ours: the hosting provider’s infrastructure (report to IONOS) and connected third-party services — Google, Meta, Stripe, Odoo and the like — which should be reported to their owner.
3. Safe harbour for good-faith research
Where the research complies with this policy, AIRON undertakes to:
- not bring or support legal action, civil or criminal, against the reporter;
- treat the activity as authorised for the purposes of laws on unauthorised access to systems and of the service terms of use;
- not suspend the account used for testing, provided it is your own or a test account.
Safe harbour lapses in cases of extortion, early publication, use of third-party data or deliberate damage. The undertaking binds AIRON, not third parties (the hosting provider, model providers).
4. Out of scope
- Denial of service (DoS/DDoS), mass fuzzing or load testing.
- Social engineering against employees, customers or suppliers; phishing; physical access.
- Testing against real customer data or accounts: use your own or a test account.
- Missing hardening headers with no demonstrable impact, SPF/DMARC/DNSSEC reports without exploitation, self-XSS, clickjacking on pages with no sensitive actions.
- Automated scanner output without reproducible exploitation.
- A dependency with a known CVE that is not reachable in the product: we still record it.
5. Time commitments
| Milestone | Deadline |
|---|---|
| Acknowledgement of receipt | 2 working days |
| Triage: validation, severity and scope | 5 working days |
| Remediation — critical (CVSS 9.0–10.0) | 7 calendar days |
| Remediation — high (7.0–8.9) | 30 calendar days |
| Remediation — medium (4.0–6.9) | 90 calendar days |
| Remediation — low (0.1–3.9) | Next planned release |
| Notice to the reporter that the fix is deployed | 5 working days after deployment |
Remediation deadlines run from triage. If they are not met, we tell the reporter why and give a new date.
6. Severity
We use CVSS v3.1 as the base metric, with CVSS v4.0 in addition where the attack chain warrants it. We document the full vector, not just the number. Environmental adjustment for a multi-tenant service: a flaw that allows crossing the boundary between accounts is automatically raised to critical, even if the base CVSS is lower.
7. Coordination, credit and publication
- Coordinated disclosure by default: joint publication after the fix is deployed, or 90 calendar days after acknowledgement if there is no fix, whichever comes first.
- Public credit to the reporter (name or handle) unless anonymity is requested.
- AIRON is not a CVE Numbering Authority. For distributed artefacts we request an identifier from the competent organisation.
- There is no monetary bounty programme at this time.
8. Relationship with incident notification
If a vulnerability is actively exploited, or if a severe incident affects product security, the early-warning (24 h), notification (72 h) and final-report timers of Regulation (EU) 2024/2847 are triggered. Where personal data is involved, the breach procedure runs in parallel: notification to the AEPD within 72 hours and, where applicable, to the data subjects. These obligations are cumulative, not alternative.
The security measures in force are summarised in security measures. For non-urgent matters: info@airon.team.