To: PickPlugins support
Subject: Security disclosure — Job Board Manager 2.1.62: unauthenticated reset of all email templates
Hi,
I'm a security researcher. While testing Job Board Manager (version 2.1.62) on a
local lab site of my own, I found an authorization problem I want to report to
you directly.
Summary
The plugin registers the AJAX action `job_bm_ajax_reset_email_templates_data`
for unauthenticated users (wp_ajax_nopriv_). The handler overwrites the
`job_bm_email_templates_data` option with the factory-default templates. There
is no capability check and no nonce check, so anyone on the internet can wipe a
site's customized job-board email templates at any time, as often as they like.
The code is in includes/functions/functions.php (lines 196–208):
function job_bm_ajax_reset_email_templates_data(){
$class_job_bm_emails = new class_job_bm_emails();
$templates_data = $class_job_bm_emails->job_bm_email_templates_data();
update_option('job_bm_email_templates_data', $templates_data);
die();
}
How to reproduce (tested on WordPress 7.1.4 + plugin 2.1.62, local lab)
1. Install and activate the plugin, then as admin customize any email template
and save, so the stored templates differ from the defaults.
2. Log out completely and send one request, no cookies, no nonce:
POST /wp-admin/admin-ajax.php
Content-Type: application/x-www-form-urlencoded
action=job_bm_ajax_reset_email_templates_data
3. The request returns HTTP 200. Open the Email templates settings page again:
the customization is gone and every template is back to the plugin defaults.
In my run I had set a custom subject line in the stored option first; after the
single unauthenticated request it was replaced by the full default template set
(application_hire, application_submitted, job_edited, job_featured, etc.).
Impact
An unauthenticated attacker can destroy a site's email template configuration
whenever they want — removing branding, legal text, corrected links and custom
wording from every notification the job board sends to applicants and
employers — and can repeat it immediately after an admin rebuilds them.
For reference: this is separate from the access-control fixes you shipped in
2.1.60 and 2.1.61. Those closed other handlers; this one is still open in
2.1.62.
Suggested fix
Remove the wp_ajax_nopriv_ registration for this action, and check a nonce plus
current_user_can() in the handler before updating the option, the same way the
plugin's settings screens do.
I tested this only against my own local installation and haven't shared the
details with anyone else. I'm happy to provide anything further that helps.
Unless we agree otherwise, I'll treat this as a standard 90-day disclosure
window from today before mentioning it publicly in any form.
Could you please confirm you've received this?
Thanks,
Rithin Krishna K V