Look at this mess of a mitigation recommendation…
![Screen shot of a Mitigation instruction which states to: update your wp-cronfig.ph [sic] file to include the following setting: define(‘DISABLE_WP_CRON’), true);](https://masterwp.com/wp-content/uploads/2023/02/Screen-Shot-2023-02-06-at-9.56.13-AM-1024x352.png)
I’m not talking about the typo, that is an honest mistake. The mitigation itself is dangerous, this disables WP-Cron.
No WP-Cron means no version checks, no automatic updates, no patches. This leaves the site in an unsafe, insecure, state.
The problem with the mitigation as it relates to the concern it is attempting to solve, is that it is missing an important second step. You must set up the operating system’s task scheduler (cron) as a replacement if you disable WP-Cron. Without this important second step, this mitigation is just telling users to make their websites stop running all WP-Cron tasks.
How did this happen? How did we get to a point that mitigation of a security concern creates a security concern it’s trying to prevent? This was simply caused by miscommunication. A lack of knowledge or collaboration between people sharing their perspective of an issue, leading to some important details getting missed. Misinformation here appears to be caused by missing-information. It turns out, when people are careless with sharing information online, data loss or missing information can happen and the results can lead to tragedy.
In this post I will highlight the importance of interpersonal communication. The importance of both being distrustful of what you read online as well as being open to seeing from other viewpoints.
Using an example that starts with a few blog posts, leads to a CVE (or vulnerability record) being publicly reported in wp-cron.php, and misinformation tainting the mitigation. I will step you through different perspectives on the situation, and how as information flowed through one person to the next, an important step gets lost. Resulting in bad advice being given, which is when I stepped in.
Here I share how I cleaned up this mess of misinformation using nothing but dialog, knowledge and research.
How did this start?
WP-Cron has always been a clever way for a web application to replicate a task scheduler. It works a lot like a task scheduler, it is named after a task scheduler (cron), but it is not a real task scheduler because it requires someone or something to make a request to the website for it to function.
This clever solution has two drawbacks:
* If no one visits the website, tasks will not run (until the next visitor)
* It generates additional traffic on the web server. (some see this as wasteful)
And this works fine for most sites, but not for every site. WP-Cron’s cleverness can become an annoyance, possibly problematic too in some configurations. Multiple people have written about it in the past, to help others in the same situation.
In 2017, Damien Carbery (daymobrew) wrote a post about how to use WP-Cron and included instructions for how to avoid a problem that affects sites with low-to-no traffic, WP-Cron not running frequently enough. The solution they shared was to first disable WP-Cron, then set a replacement task using the operating system’s task scheduler (cron.)
A year after Damien’s post, an individual by the name of “theCpanelGuy” expressed concerns with wp-cron wasting their server resources via a post titled “The Nightmare that is wp-cron.php” published via medium. Including the same solution: first disable WP-Cron in wp-config.php, then set a replacement task using the operating system’s task scheduler (cron.)
This recommendation to use the operating system’s task schedule has been well known to WordPress developers and hosting providers. The WordPress.org documentation team wrote an article on how to use the system task schedule for WP-Cron tasks. Furthermore,Many hosting providers have instructions or features that switch from the default WP-Cron to the system’s scheduler in order to address this concern.
This could have been the end of it, important knowledge shared between people who need to know about the implications. Customers are informed about the steps they can take to move WP-Cron to the system scheduler. But, the knowledge suffered from being isolated. Those who needed to know about WP-Cron issues knew, even if it information came one support article at a time.
Missing information creates misinformation.
In December 2022 a PCI approved scanning vendor added a High severity finding to their database if they detect wp-cron.php. The PCI vendor cited the article from theCpanelGuy above and scored their finding a “7.5” or “high risk” to cause service to become unavailable.
But, it gets worse … This report also provides a very vague solution for users, which could lead to disaster.
The PCI scanning vendor is encouraging users to disable WP-Cron and block access to wp-cron.php. This remediation recommendation lacked the step to set up the system’s task scheduler (cron) that all previous articles included.
In other words, “mistakes were made.”
The vulnerability goes public.
The information about WP-Cron’s quirky behavior is now associated with a denial of service risk. Once this association was made, public vulnerability databases were obliged to record the concern.
A public vulnerability identification record was created: CVE-2023-22622. This CVE described concerns in WP-Cron’s lack of documentation or alerts. In the references or supporting facts, included referencing the PCI scanning vendor’s “7.5 high risk” concern and its incomplete solution.
More misinformation.
Many security vendors, bug bounty hunters, and nefarious actors track these public databases of CVE records … and each came to their own conclusions related to exploitation, risks and remediation. Writing their own reports from their perspectives.
Here are some of the quotes I found:
One site predicted a $5000 bounty to anyone to write a working proof of concept.
Techniques on how to detect wp-cron.php are shared.
Two security vendors shared inaccurate remediation steps.
![Screen shot of a Mitigation instruction which states to: update your wp-cronfig.ph [sic] file to include the following setting: define(‘DISABLE_WP_CRON’), true);](https://masterwp.com/wp-content/uploads/2023/02/Screen-Shot-2023-02-06-at-10.13.09-AM-1024x352.png)
One security vendor recommended upgrading to WordPress 6.1.2. Which is illogical, WordPress 6.1.2 doesn’t exist (yet.) but at least it is not harmful.
Countering misinformation.
If I can help, I will not hesitate to lend a hand. I like to fix things, especially misinformation.
In the case of CVE-2023-22622, I could help. I am knowledgeable in the field of security, vulnerabilities and WordPress. I also care about WordPress users, accuracy of shared data and the open source community.
Pulling from my experience, my tool of choice to battle this misinformation was: Communication! I talked with the kind staff at MITRE and NIST. I reached out to Security vendors with clarifications, but most importantly I listened to friendly WordPress contributors who had the deepest knowledge of the subject.
I was successful, but I had to take the first step as well as be open to other’s perspectives.
Communication and custodianship.
My first email was to MITRE was headstrong (but I was hopeful.) I recommended a rejection of the CVE, providing MITRE with my perspective of the problem.
The anonymous MITRE team member clarified the CVE was relevant only to how WP-Cron runs intermittently (based on site traffic) but was not directly related to the denial of service claims the PCI scanning vendor made.
With this one email exchange I broadened my understanding of the problem. I no longer worried about the CVE’s existence, it was justified but the high severity rating and those bad remediation steps still persisted.
Empowered with a new perspective, I wrote a review of CVE-2023-22622 for Patchstack. I included enough details so anyone could understand what this CVE is all about, including links to official remediation steps.
MITRE accepted my article as a reference for the CVE-2023-22622. Now, people reviewing the CVE can be better informed when investigating the issue.
It’s a small win. The CVE still exists, but people now have a better chance to understand it fully.
To address the high severity rating, I reached out to NIST. Citing the article written for MITRE I made a recommendation for an adjustment to the severity rating. I will save you the headache of explaining what a CVSS score is and skip ahead to share that I was successful in convincing NIST to change their severity rating from a “7.5” High risk, to a “5.3” Medium risk. Another small win, but it’s better than where we started!
Finally, I reached out to the security vendors that had inaccurate remediation steps as long as they had a “report a problem/correction” form for me to use.
Some vendors have still not updated their bad remediation steps, but I have done what I can to reach out to any vendor still recommending site owners disable WP-cron to somehow address a concern where WP-Cron could be disabled (DoS’d). This mess is still out there, but it has been cleaned up a bit. Some vendors have replied to my initial contact but they haven’t updated their solution yet. It is unfortunate the misinformation is still out there, but the ball is in their court now.
Conclusions
While writing this and my previous article addressing the concerns around CVE-2023-22622. I had great conversations with many people who shared one common goal. Accurate information dissemination.
From these conversations, I learned a lot about WP-Cron, its possible problems and the solutions. I can tell you confidently you probably want to disable the default WP-Cron behavior and set up a task using normal cron. It’s not a serious security risk, and your site will probably be fine without moving WP-Cron to a task schedule. But, please make sure WP-Cron is running!
Not everything was learned through discussion alone. I manually tested my WordPress installations to verify statements and shared my findings with others. By doing this I was able to contribute verified evidence to the discussion. You must fight misinformation with verified facts, not just another opinion.
With the right effort in the right places, we all can fight misinformation. Openness to learning, willingness to test, and good foundational knowledge of subject matter guided me along in the dialogues or discussions I had with others. It was an effort, but by putting in the effort I was able to enact change and gain knowledge in the process.
I will end this post with a poem, to commemorate the adventure:
“`
I put in the effort,
but didn’t work in a bubble.
Made sure my voice was heard,
remembering to be humble.
“`
I have one last proposition for you kind readers. If you have an open-mind as I do, and an interest in dialog backed up with facts. Then I would like to share with you some of my knowledge of security as it applies to WordPress development. I will be running a Workshop on March 7th right here on MasterWP all about secure development practices for WordPress developers. I hope to see some of you there.
