MEDIUM 4.3

CVE-2026-9616: Generate Security.txt WordPress Plugin Authorization Bypass

The Generate Security.txt plugin for WordPress has an authorization flaw that allows any logged-in subscriber (or higher-privilege user) to delete the site's security.txt file or create a .well-known directory without proper permission checks. An attacker with even basic subscriber access can invoke these actions directly through the plugin's AJAX endpoints, bypassing intended access controls. This affects all versions up to and including 1.0.12.

Source data · NVD / CISA · public domain

CVSS
3.1 · 4.3 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
Weaknesses (CWE)
CWE-862
Affected products
0 configuration(s)
Published / Modified
2026-06-24 / 2026-06-25

NVD description (verbatim)

The Generate Security.txt plugin for WordPress is vulnerable to authorization bypass in all versions up to, and including, 1.0.12. This is due to the plugin not properly verifying that a user is authorized to perform an action. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete the site's security.txt file from the server filesystem or create the .well-known directory by directly invoking the delete_securitytxt or create_wellknown_folder AJAX actions.

7 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-9616 is a broken access control vulnerability (CWE-862) in the Generate Security.txt WordPress plugin. The plugin fails to properly verify user authorization before executing the delete_securitytxt and create_wellknown_folder AJAX actions. Authenticated users with subscriber-level privileges can directly call these endpoints to manipulate the security.txt file and .well-known directory structure on the server filesystem. The vulnerability requires an authenticated session but does not require elevated WordPress roles, making it exploitable by low-privilege accounts.

Business impact

Removal of the security.txt file undermines your security disclosure program by preventing researchers from discovering how to report vulnerabilities responsibly. Attackers with minimal site access could disrupt communication channels for security researchers, delay incident response coordination, or damage reputation with the security community. The unauthorized creation of directory structures could also be leveraged in conjunction with other vulnerabilities to establish persistence or stage further attacks. For organizations running this plugin, the risk is low to moderate depending on site sensitivity and user base.

Affected systems

Any WordPress installation running the Generate Security.txt plugin at version 1.0.12 or earlier is vulnerable. The plugin itself is not a core WordPress component; vulnerability impact is limited to sites where this plugin is actively installed and has at least one subscriber-level user account. Sites without authenticated users or those not running the plugin are unaffected.

Exploitability

Exploitation is straightforward and requires minimal complexity. An attacker needs only a valid WordPress subscriber account (the lowest authenticated user role) and the ability to send HTTP requests to the AJAX endpoints. No user interaction, phishing, or social engineering is required beyond obtaining baseline credentials. Network access is required but unrestricted (public or internal WordPress installations are equally vulnerable). The CVSS 3.1 score of 4.3 reflects the low barrier to entry but limited impact scope (integrity only, no confidentiality or availability impact).

Remediation

Verify against the vendor advisory for the latest patched version of the Generate Security.txt plugin. Update to a version released after June 24, 2026, which should include authorization checks for the AJAX actions. In the interim, consider restricting subscriber-level access on your WordPress site if those accounts are not required for legitimate editorial or contributor functions. Audit existing subscriber accounts and remove unused ones.

Patch guidance

Update the Generate Security.txt plugin to the latest available version from the WordPress plugin repository or the vendor's official source. Check the plugin's changelog for confirmation that authorization validation has been added to the delete_securitytxt and create_wellknown_folder AJAX actions. After updating, test that subscriber-level accounts can no longer invoke these actions; only administrators should retain this capability. No database changes or additional configuration steps are typically required for this type of security patch.

Detection guidance

Monitor WordPress audit logs and AJAX request logs for calls to delete_securitytxt or create_wellknown_folder actions originating from low-privilege user accounts. Check for unexpected deletions of files in the site root or creation of the .well-known directory by non-administrative users. Review security.txt file integrity and modification timestamps. If you maintain security headers monitoring or supply-chain scanning, verify that your security.txt file is still present and accessible at /.well-known/security.txt. Organizations using WordPress security plugins with audit logging can flag AJAX requests from subscriber accounts targeting these specific actions as indicators of exploitation.

Why prioritize this

While the CVSS score is moderate (4.3), this vulnerability should not be dismissed as low-priority. It requires minimal effort to exploit and directly undermines your organization's security disclosure program—a trust and reputation asset. Remediation is straightforward (a plugin update), so the cost-benefit analysis favors immediate patching. Sites with strict access controls (few authenticated users) face lower risk than public communities or multi-author blogs.

Risk score, explained

The CVSS 3.1 score of 4.3 (MEDIUM) reflects a vulnerability requiring authentication (low barrier: subscriber level), no user interaction, and network-accessible endpoints. Impact is limited to integrity (CWE-862 authorization bypass) with no confidentiality breach or system availability impact. The scoring does not account for business context (security.txt removal damages reputation and incident response), so security leaders should weigh their specific threat model and user base alongside the numerical score.

Frequently asked questions

Do I need a subscriber account to exploit this, or can an anonymous user?

An attacker must be authenticated with at least subscriber-level access. This is the lowest authorized user role in WordPress. If your site allows user registration or you have invited contributors or community members, the attack surface is higher. Sites with no public registration and restricted user lists face lower risk.

What happens if my security.txt file is deleted?

Legitimate security researchers will be unable to find instructions on how to report vulnerabilities to your organization. This delays responsible disclosure, damages your reputation with the security community, and could result in publicly disclosed vulnerabilities that might have been reported privately. Your incident response and security contact information become inaccessible through standard channels.

Is this vulnerability in the CISA KEV list?

No, this vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities catalog. However, that does not mean active exploitation is impossible—KEV inclusion lags behind real-world attacks. Given the ease of exploitation, you should treat this as a priority regardless of KEV status.

Do I need to do anything besides updating the plugin?

Update the plugin first. Then, audit your subscriber and contributor accounts to remove any that are no longer in use or necessary. If you run a public WordPress site, consider implementing additional account governance. Check that your security.txt file is present and unchanged post-update.

This analysis is provided for informational purposes and does not constitute legal, regulatory, or professional security advice. The vulnerability details and affected version ranges are derived from the CVE record and should be verified against the vendor's official advisory before deploying patches. CVSS scores are provided by the National Vulnerability Database and reflect baseline severity; your organization's risk may differ based on threat model, exposure, and business context. Always test patches in a non-production environment before enterprise rollout. SEC.co makes no warranty regarding the accuracy, completeness, or timeliness of this information. Source: NVD (public-domain), retrieved 2026-07-30. Analysis generated by SEC.co (claude-haiku-4-5).