VulnLine

FAQ

What is a security.txt file?

A security.txt file is a plain-text file, defined by RFC 9116, that tells security researchers how to report a vulnerability in your website. It is published at /.well-known/security.txt and must contain at least a Contact field (where to send reports) and an Expires field (when the information goes stale).

Where does security.txt go on a WordPress site?

At https://yoursite.com/.well-known/security.txt — that is the only location RFC 9116 requires, served over HTTPS with the content type text/plain. VulnLine serves it at exactly that address automatically; you do not create folders or upload files.

Does WordPress create a security.txt file automatically?

No. WordPress core does not generate a security.txt file, and most hosts do not add one either. Without a plugin or a manually uploaded file, /.well-known/security.txt on a WordPress site returns a 404 — which is the gap VulnLine fills.

How do I add security.txt to WordPress without FTP or server access?

Install VulnLine and activate it. WordPress cannot write a real file to /.well-known/ by itself, so the plugin serves security.txt dynamically at that exact URL with the correct text/plain content type — no FTP, cPanel, file manager or .htaccess edits needed.

What should a security.txt file contain?

Two fields are required by RFC 9116: Contact (a mailto:, https:// or tel: URI that a human actually reads) and Expires (a future date, ideally less than a year ahead). Optional fields are Encryption (your PGP key), Policy (your disclosure policy page), Preferred-Languages, Acknowledgments, Hiring and Canonical. VulnLine’s settings screen covers all of them.

Is security.txt required by law?

No — RFC 9116 is a voluntary standard, not a law. That said, it is mandatory for Dutch government organisations, recommended by security agencies such as the UK NCSC, and the direction of regulation (for example the EU Cyber Resilience Act’s coordinated-disclosure requirements) is toward every product and site having a published security contact. Having one costs nothing and takes a minute.

What is the difference between security.txt and robots.txt?

Different audiences. robots.txt tells search-engine crawlers which pages they may index. security.txt tells security researchers how to contact you about vulnerabilities. They live in different places, too: robots.txt sits in the root, security.txt belongs at /.well-known/security.txt.

Do I need to configure anything?

No. On activation VulnLine fills in ready-to-use defaults — your site admin email as the Contact, an Expires date one year ahead, and your site language — so the file is valid and live immediately. Change anything you like under Settings → VulnLine.

Can I add security.txt without a plugin?

Yes, if you have FTP or file-manager access: create a .well-known folder in your web root and upload a correctly formatted security.txt file. The plugin route is safer for most sites — it guarantees the text/plain content type, validates the format, survives migrations and theme changes, and reminds you before the Expires date lapses.

Do I need this if I already have a contact page or a disclosure policy?

Yes. Researchers check /.well-known/security.txt first — it is machine-readable and unambiguous, unlike a contact form buried three clicks deep. VulnLine also links your existing policy page in the Policy field, so the two work together.

How do I know my security.txt is valid?

Open yoursite.com/.well-known/security.txt — you should see plain text, not a 404 or a web page. VulnLine goes further: it validates every save against RFC 9116, shows a live status (valid / action needed) on its settings screen, and warns you in the dashboard if the file ever becomes invalid.

What happens when the Expires date passes?

Researchers treat the file as stale and may not trust or use the contact details. VulnLine shows a countdown on its settings screen and warns you in the dashboard if your file is missing or invalid — set a calendar reminder to renew the date yearly.

Why is it called VulnLine?

Because that is what it is: a direct line for vulnerability reports. When a researcher finds a bug, VulnLine makes sure they can reach you — through the standard security.txt file (RFC 9116) at /.well-known/security.txt.

Will this work with caching plugins / Cloudflare?

The file is served dynamically through WordPress. If you use aggressive full-page caching, exclude the /.well-known/security.txt path so updates appear immediately.

Does it slow down my site?

No. Nothing loads on the front end; the plugin only responds when /.well-known/security.txt itself is requested.