CraftCMS vCard Plugin RCE (CVE-2020-37071) - Why Auditing Your Plugins Matters
In early February 2026, a vulnerability that had been publicly known since May 2020 finally received a formal CVE identifier. CVE-2020-37071 is a critical deserialization flaw in the CraftCMS 3 vCard plugin (version 1.0.0) that allows unauthenticated attackers to execute arbitrary PHP code on affected servers. It carries a CVSS score of 9.8 out of 10.
If you work with CraftCMS, this one deserves your attention - not because it is new, but because of what it teaches us about plugin security, the lifecycle of vulnerabilities, and why staying current is not optional.
What happened
The vCard plugin for CraftCMS 3 provides a simple way to generate downloadable vCard files from contact data. Under the hood, the plugin encrypts contact details using OpenSSL before passing them through a URL parameter. When a user requests a vCard download, the plugin decrypts the parameter and passes the result directly into PHP's unserialize() function.
The problem is twofold. First, the plugin shipped with a hardcoded default salt value (s34s4L7) that was visible in the public source code repository. Second, the decrypted output was fed into unserialize() without any validation whatsoever. This is a textbook case of CWE-502: Deserialization of Untrusted Data.
An attacker who knew the default salt - and it was publicly available on GitHub - could craft a malicious serialised PHP payload, encrypt it with the known salt, and send it to the vCard download endpoint. The server would decrypt the payload and dutifully deserialise it, executing whatever PHP code the attacker had embedded.
No authentication required. No user interaction needed. A single HTTP request was all it took to achieve full remote code execution with the privileges of the web server process.
The timeline tells its own story
This is where it gets interesting. The vulnerability was not discovered last month. Security researcher Wade Guest published a full exploit on Exploit-DB on 18 May 2020, complete with a working Python script and detailed write-up on GitLab. The issue was also reported directly to the plugin developer via a GitHub issue.
The plugin developer did respond. Version 1.2.0 of the plugin removed the default salt entirely, requiring administrators to set their own before the plugin would function. That was a responsible fix. But the formal CVE - CVE-2020-37071 - was not assigned by VulnCheck until 3 February 2026, nearly six years after the exploit was published.
That gap matters. Many organisations rely on CVE databases and automated scanning tools to identify vulnerabilities in their software stack. If a vulnerability does not have a CVE, it does not show up in composer audit results. It does not trigger alerts in Snyk or Dependabot. It exists in the wild, with a working exploit, but is invisible to the tools that most teams depend on for their security posture.
Who should be concerned
If you are running a CraftCMS 3 installation with the vCard plugin at version 1.0.0 - or any version where the default salt was never changed - your site is vulnerable to unauthenticated remote code execution right now.
More broadly, if you are still running CraftCMS 3 at all, you should be planning your migration. Craft CMS 3 reached end of life on 30 April 2024. Security fixes from Pixel and Tonic stopped on that date. Any vulnerabilities discovered after that point - in core or in plugins - will not receive official patches for Craft 3.
The vCard plugin itself has continued to be maintained. Version 2.x supports CraftCMS 4, and version 3.x (currently 3.1.0) supports CraftCMS 5. Both modern versions address this vulnerability. But if your site is stuck on Craft 3 with outdated plugins, you are in the exact situation this CVE highlights.
The broader lesson
We have written before about why we choose CraftCMS and its advantages over platforms like WordPress. One of those advantages is a smaller, more curated plugin ecosystem that reduces attack surface. This vulnerability does not contradict that position - it reinforces it with an important caveat.
Even on a platform with a strong security track record, third-party plugins are third-party code. They are written by independent developers with varying levels of security expertise. The vCard plugin's use of unserialize() on user-controlled input is a well-documented anti-pattern that experienced PHP developers know to avoid. But in a small community plugin, it went unnoticed until an external researcher found it.
This is why plugin auditing matters. Every plugin you install is code you are choosing to trust with your server's security. As we discussed in our post on automated security scanning in CI/CD pipelines, tools like composer audit, Snyk, and Dependabot can catch known vulnerabilities automatically. But they can only catch what has been formally catalogued. The six-year gap between this exploit's publication and its CVE assignment is a stark reminder that automated tools are one layer of defence, not the whole strategy.
What you should do
If you are running the vCard plugin on any CraftCMS installation, verify your version immediately. If you are on version 1.0.0 or 1.1.0, update to the latest version compatible with your Craft installation. If you cannot update, remove the plugin entirely.
If you are still on CraftCMS 3, this is another reason to prioritise your upgrade path. With CraftCMS 5 now the current supported version and CraftCMS 6 on the horizon with its move to the Laravel framework, there has never been a better time to plan that migration.
And regardless of which CMS you use, take the time to audit your plugins. Check when each one was last updated. Look at whether the developer is still active. Review the plugin's dependency list. If a plugin has not been touched in years and your site depends on it, that should be a red flag.
As we have said before in our post on what happens when your CMS does not get updated: security is not a one-time decision. It is an ongoing commitment. A vulnerability does not need a CVE number to be dangerous - it just needs an attacker who knows about it.