Title: VulnLine
Author: Md Jahid Bin Sabit
Published: <strong>November 11, 2026</strong>
Last modified: November 11, 2026

---

Search plugins

![](https://ps.w.org/vulnline/assets/banner-772x250.png?rev=3795575)

![](https://ps.w.org/vulnline/assets/icon-256x256.png?rev=3795575)

# VulnLine

 By [Md Jahid Bin Sabit](https://profiles.wordpress.org/jbsabit/)

[Download](https://downloads.wordpress.org/plugin/vulnline.1.1.3.zip)

 * [Details](https://wordpress.org/plugins/vulnline/#description)
 * [Reviews](https://wordpress.org/plugins/vulnline/#reviews)
 *  [Installation](https://wordpress.org/plugins/vulnline/#installation)
 * [Development](https://wordpress.org/plugins/vulnline/#developers)

 [Support](https://wordpress.org/support/plugin/vulnline/)

## Description

**When a security researcher finds a vulnerability in your site, how do they reach
you?**

Most WordPress sites have no answer — so reports go to Twitter, get ignored, or 
never happen. **VulnLine is a security.txt generator for WordPress**: it creates
and serves a valid `security.txt` file (RFC 9116, the internet standard for publishing
security contact information) at `/.well-known/security.txt`, exactly where security
researchers and bug bounty hunters look first.

**In short:** install VulnLine, and your WordPress site publishes a standard security
contact file at `https://yoursite.com/.well-known/security.txt` — with your contact
details, an expiry date, and your vulnerability disclosure policy — valid the moment
you activate it, with zero configuration.

**What is a security.txt file?**

A security.txt file is a small plain-text file that tells anyone who finds a security
problem on your website how to report it to you responsibly. It is defined by the
IETF in RFC 9116 (published 2022) and lives at one fixed address: `/.well-known/
security.txt`, served over HTTPS as `text/plain`. Think of it as robots.txt for 
security researchers: a machine-readable signpost that says “found a vulnerability?
Here is how to tell us.”

**What you get**

 * A valid `security.txt` served automatically at `/.well-known/security.txt` with
   the correct `text/plain` content type — no file editing, no FTP, no server config
 * **Zero-config start** — on activation VulnLine fills in ready-to-use defaults(
   your site admin email as the Contact, an Expires date one year ahead, your site
   language), so your file is valid and live immediately
 * **Contact** (required) — one or more contact URIs: `mailto:`, `https://`, `tel:`
 * **Expires** (required) — always a future date, with a dashboard warning before
   your file lapses
 * Every optional RFC 9116 field: **Encryption** (PGP key link), **Acknowledgments**,**
   Preferred-Languages**, **Policy** (your vulnerability disclosure policy page),**
   Hiring**, **Canonical**
 * **Live preview** — a syntax-highlighted preview with one-click copy; see exactly
   what researchers will see before you save
 * **Built-in RFC 9116 validation** — catches bad contact URIs, past Expires dates
   and malformed fields, with clear error messages
 * **Admin reminder** — a dashboard notice if your security.txt is missing or invalid,
   so it never silently rots

**What a valid security.txt looks like**

Contact: mailto:security@example.com
 Expires: 2027-11-10T23:59:59Z Preferred-Languages:
en Policy: https://example.com/security-policy Canonical: https://example.com/.well-
known/security.txt

Only `Contact` and `Expires` are required by RFC 9116. VulnLine generates this file
for you, keeps the format correct, and updates it the moment you save your settings.

**Why your WordPress site needs a security.txt**

 * Google, Facebook, the US CISA and thousands of bug-bounty programs publish a 
   security.txt — it is the expected standard for responsible disclosure
 * Security researchers, ethical hackers and vulnerability scanners (including internet.
   nl-style compliance checks) look for `/.well-known/security.txt` first; without
   one, many simply move on — or disclose publicly
 * The EU Cyber Resilience Act pushes vendors toward coordinated vulnerability disclosure;
   a security.txt is the simplest way to publish yours
 * A reachable security contact turns a potential public incident into a quiet, 
   responsible report

**Why a plugin instead of uploading the file by hand?**

You can create a `.well-known` folder and upload a text file by FTP — if you have
filesystem access and get every detail right. In practice, hand-made files break
silently: the folder is lost in a site migration, the file is served as `text/html`
instead of `text/plain`, the Expires date passes unnoticed, or the file is edited
into an invalid format. VulnLine serves security.txt dynamically through WordPress,
validates it against RFC 9116 every time you save, and warns you in the dashboard
if anything is wrong — including an Expires date that is about to lapse.

**Privacy**

This plugin collects nothing, phones home nowhere, and adds zero front-end weight—
it only serves one tiny text file when requested.

Built by WordPress security specialist Md Jahid Bin Sabit — [jbsabit.com](https://jbsabit.com/)

## Screenshots

[⌊The VulnLine settings screen — live status, expiry countdown, and a live preview
of your security.txt exactly as researchers will see it.⌉⌊The VulnLine settings 
screen — live status, expiry countdown, and a live preview of your security.txt 
exactly as researchers will see it.⌉[

The VulnLine settings screen — live status, expiry countdown, and a live preview
of your security.txt exactly as researchers will see it.

[⌊Your security.txt served at /.well-known/security.txt with the correct plain-text
format.⌉⌊Your security.txt served at /.well-known/security.txt with the correct 
plain-text format.⌉[

Your security.txt served at /.well-known/security.txt with the correct plain-text
format.

[⌊The live preview card with syntax highlighting and one-click copy — what you save
is exactly what researchers get.⌉⌊The live preview card with syntax highlighting
and one-click copy — what you save is exactly what researchers get.⌉[

The live preview card with syntax highlighting and one-click copy — what you save
is exactly what researchers get.

[⌊Built-in validation warns you the moment something is wrong — here, an Expires
date in the past.⌉⌊Built-in validation warns you the moment something is wrong —
here, an Expires date in the past.⌉[

Built-in validation warns you the moment something is wrong — here, an Expires date
in the past.

[⌊A dashboard reminder appears across wp-admin if your security.txt is missing or
invalid, so it never silently rots.⌉⌊A dashboard reminder appears across wp-admin
if your security.txt is missing or invalid, so it never silently rots.⌉[

A dashboard reminder appears across wp-admin if your security.txt is missing or 
invalid, so it never silently rots.

## Installation

 1. Upload the plugin files to `/wp-content/plugins/vulnline/`, or install through 
    the WordPress plugins screen.
 2. Activate the plugin — your security.txt is already valid and live with sensible
    defaults.
 3. Go to **Settings  VulnLine** to review or change your contact info.
 4. Visit `yoursite.com/.well-known/security.txt` to see it live.

## 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.

## Reviews

There are no reviews for this plugin.

## Contributors & Developers

“VulnLine” is open source software. The following people have contributed to this
plugin.

Contributors

 *   [ Md Jahid Bin Sabit ](https://profiles.wordpress.org/jbsabit/)

[Translate “VulnLine” into your language.](https://translate.wordpress.org/projects/wp-plugins/vulnline)

### Interested in development?

[Browse the code](https://plugins.trac.wordpress.org/browser/vulnline/), check out
the [SVN repository](https://plugins.svn.wordpress.org/vulnline/), or subscribe 
to the [development log](https://plugins.trac.wordpress.org/log/vulnline/) by [RSS](https://plugins.trac.wordpress.org/log/vulnline/?limit=100&mode=stop_on_copy&format=rss).

## Changelog

#### 1.1.3

 * Renamed to VulnLine (new slug) with a full internal re-prefix: every function,
   class, constant, option and handle now uses the unique vulnline_ prefix. Settings
   saved under either previous name (Bugline, Security.txt Generator) migrate automatically—
   your published security.txt does not change.

#### 1.1.2

 * Easy setup: the plugin now configures itself on first run — Contact is filled
   with the site admin email, Expires is set one year ahead, and Preferred-Languages
   follows the site language, so the file is valid and live the moment you activate.
   Sites upgrading with an empty Contact get it filled once, automatically.

#### 1.1.1

 * Fix: sanitize the request URI used by the plain-permalink fallback (Plugin Check
   warning). No behaviour change.

#### 1.1.0

 * Renamed to Bugline (new slug) with a full internal re-prefix: every function,
   class, constant, option and handle now uses the unique bugline_ prefix. Existing
   settings migrate automatically — your published security.txt does not change.

#### 1.0.4

 * Hardening and robustness: ABSPATH guards on all class files, plain-permalink 
   fallback for serving the file, trailing-slash tolerance, dead-code cleanup. No
   behavior change.

#### 1.0.3

 * Premium settings UI: branded top bar, gradient status hero with stat tiles, icon-
   headed cards, terminal-style syntax-highlighted preview, and polished form styling.

#### 1.0.2

 * Improved settings UI: status hero card (live/valid state with expiry countdown),
   grouped Required/Optional field cards, and a copy button on the live preview.

#### 1.0.1

 * Code quality: inline escaping on all admin outputs (resolves Plugin Check EscapeOutput
   notices) and Tested up to 7.1. No behavior change.

#### 1.0.0

 * Initial release: RFC 9116 security.txt generation, validation, live preview, 
   and automatic serving at /.well-known/security.txt.

## Meta

 *  Version **1.1.3**
 *  Last updated **20 hours ago**
 *  Active installations **Fewer than 10**
 *  WordPress version ** 5.5 or higher **
 *  Tested up to **7.1.4**
 *  PHP version ** 7.4 or higher **
 * Tags
 * [security.txt](https://wordpress.org/plugins/tags/security-txt/)[vulnerability-disclosure](https://wordpress.org/plugins/tags/vulnerability-disclosure/)
 *  [Advanced View](https://wordpress.org/plugins/vulnline/advanced/)

## Ratings

No reviews have been submitted yet.

[Your review](https://wordpress.org/support/plugin/vulnline/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/vulnline/reviews/)

## Contributors

 *   [ Md Jahid Bin Sabit ](https://profiles.wordpress.org/jbsabit/)

## Support

Got something to say? Need help?

 [View support forum](https://wordpress.org/support/plugin/vulnline/)

## Donate

Would you like to support the advancement of this plugin?

 [ Donate to this plugin ](https://jbsabit.com/)