Request a Demo

Vulnerability Disclosure Policy

How to responsibly report security vulnerabilities: channels, response times, scope, and what to expect from the Webmaster360 team.

Last updated: July 24, 2026

1. Purpose

TAGMOOD S.R.L. considers collaboration with researchers, users and security professionals who report possible vulnerabilities relating to Webmaster360 in good faith to be important.

This policy describes:

  • which systems fall within the scope;
  • how to submit a report;
  • which activities are permitted;
  • which activities are not authorized;
  • how TAGMOOD handles reports;
  • the conditions applicable to coordinated disclosure.

This policy does not constitute a bug bounty program and does not automatically provide for monetary rewards or other compensation.

2. Reporting Contact

Vulnerabilities may be reported to:

webmaster360@tagmood.it

Recommended subject:

[SECURITY] Webmaster360 vulnerability report

Where the report also concerns a possible personal data breach, you may copy:

privacy@tagmood.it

TAGMOOD does not currently publish a dedicated PGP key. Do not send personal data, credentials, tokens, dumps, private keys or other unnecessary sensitive content in the first email.

3. Scope

The following fall within the scope:

  • the Webmaster360 CMS and back-end;
  • front-ends generated or directly managed by the platform;
  • the Webmaster360 APIs;
  • services and subdomains attributable to Webmaster360 and directly managed by TAGMOOD;
  • authentication, authorization and account management mechanisms;
  • publication, import, automation and content management features;
  • integrations developed and directly controlled by TAGMOOD;
  • infrastructure configurations directly controlled by TAGMOOD.

For Customer websites, the report falls within the scope only where the issue originates from the Webmaster360 platform or from a component directly managed by TAGMOOD.

4. Out-of-Scope Items

The following are excluded, unless otherwise confirmed in writing by TAGMOOD:

  • third-party systems, services and domains;
  • accounts, infrastructures or applications not controlled by TAGMOOD;
  • vulnerabilities present exclusively in content or configurations introduced by the Customer;
  • personal devices, networks or accounts of employees, collaborators or Customers;
  • services of the suppliers listed on the sub-processors page;
  • the public corporate website, where the issue does not concern a Webmaster360 service or a system controlled by TAGMOOD.

Vulnerabilities relating to third-party suppliers should be reported directly to the responsible party. TAGMOOD may nonetheless be informed where the issue produces a concrete impact on the Webmaster360 services.

5. Information to Include

A useful report should include, where possible:

  • clear description of the vulnerability;
  • affected URL, endpoint, function or component;
  • necessary prerequisites;
  • minimum steps to reproduce the issue;
  • potential impact;
  • any conditions that limit or amplify the impact;
  • approximate date and time of the tests;
  • IP address used for the tests, if the reporter wishes to communicate it;
  • screenshots or brief technical excerpts without third-party data;
  • possible mitigation measures;
  • contact address to receive updates.

It is preferable to submit one report per vulnerability, unless multiple issues are part of the same attack chain.

6. Good Faith Testing Principles

Tests must be proportionate and limited to what is strictly necessary to demonstrate the existence of the vulnerability.

The reporter must:

  • use their own accounts and data, where possible;
  • avoid accessing other people’s or organizations’ data;
  • immediately stop the test if third-party data is displayed;
  • not modify, delete, copy or publish data not belonging to them;
  • not compromise the availability, performance or stability of the service;
  • not install software, backdoors or persistence mechanisms;
  • not use the vulnerability to obtain advantages other than technical verification;
  • securely store the information collected;
  • delete accidentally obtained data after receiving confirmation from TAGMOOD that it is no longer needed;
  • keep the report confidential during the coordinated management process.

A proof of concept must demonstrate the issue with the minimum level of access, data and interaction necessary.

7. Unauthorized Activities

The following are not authorized:

  • intentional service interruptions or denial-of-service attacks;
  • unagreed load testing;
  • social engineering, phishing or impersonation;
  • physical access attempts;
  • brute force, password spraying or credential stuffing;
  • use of credentials obtained unlawfully or from third-party breaches;
  • deliberate access to Customer or user data;
  • exfiltration, mass download or retention of data;
  • modification or deletion of content;
  • sending of malware;
  • installation of persistent tools;
  • high-intensity automated scans;
  • alteration of logs or evidence;
  • publication of the vulnerability before coordination with TAGMOOD;
  • threats, extortionate requests or making confidentiality conditional on payment of a sum.

Reports based exclusively on the output of automated tools, without verification of the impact and without reproducible elements, may receive a lower priority.

8. Accidental Access to Personal or Confidential Data

If the reporter accidentally accesses personal data, credentials, non-public content or confidential information, they must:

  1. immediately cease any further access;
  2. not copy, download, share or use the data;
  3. inform TAGMOOD in the report;
  4. indicate in general terms the type and quantity of data viewed, without including it in the email;
  5. follow the instructions received for the secure deletion of any local copies.

TAGMOOD may request additional information to assess a possible incident, avoiding as far as possible the further transmission of the data concerned.

9. Report Handling

TAGMOOD aims to:

  • acknowledge receipt of the report, where possible, within 5 working days;
  • carry out an initial assessment and communicate the initial outcome, where possible, within 10 working days;
  • keep the reporter informed of relevant developments;
  • assign priority based on impact, exploitability and prevalence;
  • adopt mitigation or correction measures according to the risk and technical complexity;
  • communicate, where possible, the conclusion of the handling.

The timeframes are operational targets and do not constitute SLAs or contractual guarantees.

Resolution may require different timescales based on:

  • severity and complexity;
  • need to involve suppliers or Customers;
  • risk of regressions;
  • availability of a safe mitigation;
  • legal or confidentiality obligations.

TAGMOOD may group duplicate reports and limit updates where the disclosure of details could increase the risk.

10. Coordinated Disclosure

The reporter must not make the vulnerability public before:

  • TAGMOOD has had reasonable time to analyze and mitigate it;
  • a disclosure date has been agreed; or
  • TAGMOOD has communicated that it does not intend to proceed further.

Any public disclosure should avoid:

  • personal data;
  • credentials;
  • confidential Customer information;
  • details that enable the immediate exploitation of systems not yet updated;
  • indications identifying users or organizations involved.

TAGMOOD assesses in good faith any requests for public acknowledgment of the contribution, but does not guarantee publication of the reporter’s name.

11. Good Faith Research Commitment

Where a person:

  • acts in good faith;
  • complies with this policy;
  • avoids harm and unnecessary access;
  • promptly reports the issue;
  • cooperates in the coordinated management;

TAGMOOD does not intend to bring legal action against them solely for the research activity carried out in compliance with this policy.

This commitment does not apply to unlawful, harmful, negligent, extortionate activities or activities exceeding what is reasonably necessary to verify the vulnerability. This policy does not authorize violations of law nor can it bind third parties.

If in doubt as to whether an activity is permitted, the researcher must seek confirmation before proceeding.

12. Reports Normally Not Considered Vulnerabilities

Unless there is a concrete and demonstrable impact, the following may not be considered vulnerabilities:

  • absence of security headers not accompanied by an exploitable risk;
  • version information without an applicable vulnerability;
  • clickjacking on pages without sensitive operations;
  • self-XSS;
  • tabnabbing without demonstrable impact;
  • issues requiring physical access to the victim’s device;
  • attacks requiring an unsupported browser or operating system;
  • missing cookie attributes where the cookie does not contain sensitive information;
  • username or email enumeration with negligible impact;
  • rate limiting deemed insufficient without proof of concrete abuse;
  • incomplete SPF, DKIM or DMARC without demonstration of a specific risk to Webmaster360;
  • unverified automated scanner results;
  • known third-party vulnerabilities for which use of the affected version is not demonstrated;
  • generic hardening recommendations.

TAGMOOD nonetheless assesses each report in its own context.

13. Protection of Reporter’s Data

TAGMOOD processes the reporter’s data to:

  • receive and handle the report;
  • communicate updates;
  • protect the services;
  • document the verifications and measures adopted;
  • comply with any legal obligations;
  • protect its own rights and those of the parties involved.

The legal basis is the legitimate interest in system security and, where applicable, compliance with legal obligations.

Data is retained for the time necessary for the handling, documentation and protection connected to the report.

For privacy requests:

privacy@tagmood.it

14. Policy Updates

TAGMOOD may update this policy to reflect changes to the services, security processes or Applicable Law.

Each version shall bear the effective date and last update date.

15. Contacts

Security reports:
webmaster360@tagmood.it

Privacy:
privacy@tagmood.it

PEC:
tagmood@pec.it