Security and Vulnerability Disclosure
This policy provides a clear route for reporting potential security vulnerabilities affecting Veyra websites, software and services while protecting users, data and production availability.
Who receives security reports?
This policy is published by:
- Legal name
- [[LEGAL NAME OF THE WEBSITE AND SOFTWARE OPERATOR]]
- Trading name
- Veyra Apps
- Business address
- [[PUBLIC BUSINESS OR PROFESSIONAL ADDRESS]]
- Country of establishment
- Spain
- Security contact
- [[SECURITY CONTACT EMAIL]]
- Temporary fallback
- support@veyraapps.com
Confirm the legal operator, public address and dedicated security inbox. Keep the fallback only until the security address and routing have been tested.
Supporting responsible vulnerability reporting
Security weaknesses can remain unresolved when researchers and users cannot find a reliable reporting channel. This policy explains where to send a report, what systems are covered, what conduct Veyra considers responsible and how coordinated disclosure should work.
The objective is to make it easier to diagnose and remedy genuine security problems before detailed information creates additional risk for users or systems.
This policy does not grant unlimited permission to access Veyra infrastructure or third-party systems. Any testing must remain within the explicit scope and behavioural limits described below.
Systems covered by this policy
Only assets expressly identified below or in the current `security.txt` file are in scope. A service should not be treated as authorised merely because it contains the Veyra name or links to the Veyra website.
Public website
In scopePublic routes and forms served from `veyraapps.com`, excluding infrastructure or functionality operated entirely by third parties.
Published Veyra software
In scopeOfficial releases of Veyra plugins, themes or applications obtained from a channel identified by Veyra as official.
Official APIs and services
Only when listedAPI hosts, update endpoints or hosted applications are in scope only after the exact hostname or service is published in this policy or `security.txt`.
Explicitly excluded assets
Out of scopeDevelopment machines, local environments, private repositories, unrelated domains and third-party platforms are excluded unless written authorisation says otherwise.
Replace broad descriptions with the production asset list: [[VEYRAAPPS.COM ROUTES]], [[API HOSTNAMES]], [[OFFICIAL REPOSITORIES]], [[PLUGIN OR THEME IDENTIFIERS]] and [[EXPLICIT EXCLUSIONS]].
Testing methods that are not authorised
The following activities are outside this policy unless Veyra has provided prior written authorisation for a specific test:
- Denial-of-service, distributed denial-of-service, resource-exhaustion or load testing against production systems.
- Social engineering, phishing, pretexting, impersonation or targeting employees, contractors, customers or service providers.
- Physical intrusion, device theft, office access or attacks against personal equipment and home networks.
- Malware deployment, persistence, ransomware, destructive payloads or intentional alteration or deletion of data.
- Accessing, downloading, retaining or exposing personal, confidential or customer information beyond the minimum evidence necessary.
- Automated scanning at a volume that creates service degradation, noise, account lockouts or operational burden.
- Testing payment providers, hosting platforms, email services, WordPress.org, GitHub or other third-party systems without their own permission.
- Public disclosure, sale or transfer of an unresolved vulnerability before reasonable coordination has occurred.
- Using a discovered weakness to obtain commercial advantage, extort payment or demand compensation.
- Reports limited to missing best-practice headers, generic scanner output or theoretical issues without a meaningful security impact.
Rules for minimising risk
What makes a report actionable?
A useful report enables Veyra to reproduce, assess and resolve the issue without requesting multiple rounds of basic information.
Affected asset
The exact hostname, URL, product, plugin version, repository, API route or component where the issue appears.
Vulnerability description
A concise explanation of the weakness, the security property affected and the conditions required to trigger it.
Reproduction steps
Numbered steps, minimal requests, proof-of-concept code or screenshots sufficient to reproduce the behaviour safely.
Impact and severity
The realistic consequence, affected users or data, required privileges, user interaction and any limiting factors.
Environment
Relevant browser, WordPress, PHP, server, database, plugin, theme or application versions.
Researcher contact
An email address for coordination, preferred attribution and any disclosure deadline already under consideration.
Reports should avoid including live credentials, unnecessary personal data or unredacted database content. Where evidence contains sensitive information, describe it first and ask how Veyra prefers to receive it securely.
How to report a vulnerability
Use a dedicated, private subject line
Begin the subject with “Security vulnerability” and identify the affected product or hostname. Do not send the report through social media, public issue trackers or general comments.
Use encrypted communication when the report must contain sensitive technical evidence and a supported public key is available.
What happens after a report is received?
Acknowledgement
The report is logged, protected and checked for enough information to begin assessment.
Reproduction and triage
Veyra attempts to reproduce the issue, confirm scope and assess likely severity and affected versions.
Fix and testing
A mitigation, patch, configuration change or provider escalation is prepared and tested according to risk.
Release and disclosure
The reporter is updated where practical and any public advisory is coordinated after protection is available.
Veyra may request clarification, additional evidence or a retest. Not every report will qualify as a vulnerability, and severity may differ from the reporter’s initial assessment.
Response targets—not guaranteed deadlines
Targets should reflect the resources realistically available to Veyra. They indicate intended communication rather than a guarantee that every issue can be resolved within a fixed period.
[[ACKNOWLEDGEMENT TARGET, FOR EXAMPLE WITHIN 5 BUSINESS DAYS]]
[[INITIAL ASSESSMENT TARGET, FOR EXAMPLE WITHIN 10 BUSINESS DAYS]]
[[UPDATE CADENCE OR “WHEN A MATERIAL CHANGE OCCURS”]]
No universal deadline. Priority depends on severity, exploitability, affected users, product lifecycle, provider dependencies and the complexity of a safe fix.
Publishing details after users can be protected
Researchers are asked to keep vulnerability details confidential while Veyra validates the issue and prepares reasonable protection for affected users.
Disclosure timing should consider severity, active exploitation, availability of a patch or mitigation, affected third parties and the risk created by publishing technical detail.
Where appropriate, Veyra and the reporter may coordinate:
- The content and publication date of a security advisory.
- Affected products and versions.
- Mitigation, upgrade or configuration guidance.
- Researcher attribution.
- Whether coordination with a vendor, WordPress.org, INCIBE-CERT or another appropriate coordinator is needed.
- Whether a CVE identifier should be requested and by whom.
Insert the normal coordination model after the operational process is tested: [[CASE-BY-CASE / TARGET WINDOW / ACTIVE-EXPLOITATION EXCEPTION / THIRD-PARTY COORDINATION RULES]].
How Veyra intends to treat compliant research
Veyra does not intend to pursue claims solely for accidental, good-faith research that follows this policy.
This position applies where the researcher acts to improve security, remains within the stated scope, avoids prohibited activity, minimises impact, protects data and reports the issue privately without using it for coercion or commercial leverage.
This statement is not legal advice, does not bind third parties and does not excuse conduct that is reckless, harmful, unlawful or outside the policy. Veyra cannot authorise testing against systems it does not own or control.
Where there is uncertainty about whether a proposed test is permitted, request written clarification before performing it.
Review the good-faith language against the final operator, jurisdictions, asset ownership and desired authorisation model before publication.
No automatic entitlement to payment
This policy is a vulnerability-disclosure channel, not a public bug-bounty programme. Submitting a report does not create a right to payment, compensation, free products, employment or another commercial benefit.
Veyra may choose to thank or credit a researcher after a valid issue has been resolved, subject to the researcher’s preference and any confidentiality or legal constraints.
[[NO MONETARY REWARDS / DISCRETIONARY RECOGNITION / FUTURE BUG BOUNTY PROGRAMME]].
Handling information contained in a report
Security reports may contain the researcher’s contact details, technical evidence, IP addresses, logs, screenshots and information needed to validate the issue.
Veyra will use that information to receive, investigate, remediate, document and coordinate the report, protect systems and users, and establish or defend legal claims where necessary. More information is available in the Privacy Policy.
Researchers should redact unrelated personal data and avoid retaining copies. If personal data is exposed accidentally, stop testing, do not access further records, document the minimum needed to identify the issue and report it immediately.
Services Veyra does not own or control
Hosting, email, payment, WordPress.org, repository, analytics, CDN and other providers operate under their own vulnerability-disclosure policies and legal terms.
Do not test a third-party system under the assumption that this Veyra policy authorises it. Report the issue to the provider through its official process. A copy may also be sent to Veyra where the issue materially affects a Veyra integration or users.
Veyra may coordinate with the provider or an appropriate national or sector coordinator where remediation requires multiple parties.
security.txt
Veyra intends to publish a machine-readable security contact file so researchers and automated tools can locate the current reporting channel.
Contact: mailto:[[SECURITY CONTACT EMAIL]] Expires: [[RFC 3339 EXPIRY DATE]] Canonical: https://veyraapps.com/.well-known/security.txt Policy: https://veyraapps.com/legal/security/ Preferred-Languages: en, es Encryption: [[PGP PUBLIC KEY URL — REMOVE IF UNUSED]] Acknowledgments: [[SECURITY ACKNOWLEDGMENTS URL — REMOVE IF UNUSED]]
The file should be served over HTTPS with a current expiry date. Optional fields should be removed rather than left with placeholders when the corresponding resource does not exist.
Changes to this policy
This policy may be updated when Veyra publishes new products, activates APIs or hosted applications, changes reporting channels, introduces a bounty programme or modifies the systems included in scope.
Researchers should review the current policy and `security.txt` file before testing or submitting a report. The version applicable to a report is the version published when the relevant activity occurred, subject to mandatory law.
Security reporting details
- Security email: [[SECURITY CONTACT EMAIL]]
- Temporary fallback: support@veyraapps.com
- Policy owner: [[LEGAL NAME OF THE WEBSITE AND SOFTWARE OPERATOR]]
- Address: [[PUBLIC BUSINESS OR PROFESSIONAL ADDRESS]]
- security.txt: https://veyraapps.com/.well-known/security.txt
Ordinary product support and non-security bug reports should use the routes available from Support.