Webnode · Security

Security Vulnerability Disclosure Policy

How to report a security vulnerability to Webnode, what is in scope, and what you can expect from us.

The security of our customers and their data is a top priority. We welcome reports from security researchers and are committed to working with them fairly and in good faith. This policy explains what is in scope, how to report a vulnerability, and what you can expect from us.

To receive and handle reports we primarily use the Intigriti platform, our vulnerability disclosure partner.

How to report

Please submit your report through one of the following channels, in order of preference:

  1. Via Intigriti Preferred — structured intake and communication. https://app.intigriti.com/programs/combell/webnode/
  2. By email Always available. Please encrypt sensitive details with our PGP key. security-report@webnode.com
    https://www.webnode.com/.well-known/security-pubkey.asc

What your report should include

  • A clear description of the vulnerability and its impact.
  • Precise steps to reproduce.
  • A proof of concept — request/response, screenshot, or video.
  • The affected asset (URL) and the conditions under which the issue occurs.

Reports with a clear proof of concept can be assessed significantly faster.

Scope

The following production assets are in scope:

  • www.webnode.com — main corporate portal: sign-in and management of sites, projects, and personal account.
  • [project].webnode.page — live customer websites.
  • [project].cms.webnode.page — the CMS editor where customers build their sites.
  • [project].user.webnode.page — user project URL.

You may freely create your own account and your own test websites. Please test only against your own accounts and projects.

Areas of particular interest

We are especially interested in findings with real, demonstrated impact related to:

  • cross-tenant information leaks;
  • leakage of personal data.

Out of scope

Assets

  • webnode.com/blog — WordPress, marketing.
  • webnode.com/support/ — knowledge base, third-party solution.

Finding types (without demonstrated real impact)

  • Username/email enumeration; WordPress username disclosure.
  • Missing or bypassable rate limiting; email bombing.
  • Missing security headers; missing cookie flags; presence of the autocomplete attribute on forms.
  • CSRF with low or no impact; clickjacking without realistic user interaction.
  • Self-XSS not exploitable against other users; same-site scripting; content injection without the ability to modify HTML.
  • CORS misconfiguration on non-sensitive endpoints.
  • Anything related to email spoofing, SPF, DMARC, or DKIM.
  • API key / version / banner disclosure without business impact; un-stripped file metadata.
  • Blind SSRF without demonstrated impact (pingbacks alone are not sufficient); host header injection without impact.
  • Pre-auth account takeover / OAuth squatting; race conditions; HTTP request smuggling without demonstrated impact.
  • Best-practice recommendations (password policy, expiration, reuse, etc.).
  • Reports that software is outdated or vulnerable without a proof of concept; theoretical issues without a realistic exploit scenario.
  • DoS/DDoS and brute-force attacks; spam; social engineering; physical attacks.
  • Attacks requiring physical access to a device, MITM, or a compromised account.

The complete and binding scope rules are maintained on our program page on Intigriti.

Assessment and rewards

We assess the severity of each report individually, based on real, demonstrated impact (CVSS methodology).

Any rewards are provided solely within our program on the Intigriti platform, at our discretion and subject to the program's current capacity. This policy does not create any entitlement to a reward or any other obligation on our part.

Safe harbor

If you conduct your research in good faith and comply with this policy, we will consider your research authorized, will not treat it as unauthorized access, and will not pursue legal action against you.

Rules of engagement

  • Test only against your own accounts and projects; do not access other users' data.
  • Limit data access to the minimum necessary to demonstrate the vulnerability; do not exfiltrate, modify, or delete data.
  • Do not disrupt our services — no DoS/DDoS and no automated brute-force attacks.
  • No social engineering, phishing, or physical attacks against employees or customers.
  • Do not publicly disclose the vulnerability until it has been resolved, or until we agree on coordinated disclosure.
  • Allow us reasonable time to remediate.

What you can expect

  • Acknowledgment of your report and a fair assessment.
  • Communication about the status of remediation.
  • Recognition for helping improve the security of our services.