I'm using v5.16.3, updated in December when I moved to a new server.

I've noticed a few times that things are being submitted when they're not supposed to be, and I THOUGHT it was an anomaly. But then a few days ago I submitted something myself that threw an error (when it shouldn't have)... but continued processing, anyway.

After days and days of digging, my only theory is that "exit" doesn't stop the script anymore?

The error I'm getting is that $contents{'username'} is blank, when I know for a fact that it isn't. The form is submitted using:

<form name="calendar" action="https://www.example.com/cgi-bin/events.cgi" method="POST" enctype="multipart/form-data" onSubmit="return false">
<input type="hidden" name="event_id" value="">
<input type="hidden" name="old_flyer" value="">
<input type="hidden" name="username" value="csdude55">

Here's the relevant part of my Perl script:

#!/usr/bin/perl 

use Imager;
use File::Copy;

use Net::Whois::IP qw(whoisip_query);

# Variables
# this .lib loads 6 modules (including CGI qw(:standard) ), converts param() to %contents, connects to MySQL, and several other common scripts
# get_date() just converts localtime() to a readable $today string
require 'libs/variables.lib';
get_date();

# this .lib is used everywhere and shouldn't be an issue
eval { require 'libs/filter_profanity.lib' };

$testing = 0;
if ($today eq '20210429' && !$contents{'username'}) {
$testing = 1;

print "Content-type: text/html\n\n";
print "<pre>\n";

print "contents: u=" . $contents{'username'} . "&n=" . $contents{'name'} . "\n";
print "param: u=" . param('username') . "&n=" . param('name') . "\n";

print "</pre>";
exit;
}

The problem I'm working on is that the script thinks that $contents{'username'} is blank when it's not, so it returns an error to the user. I printed both $contents{'username'} and param('username') to make sure that the error wasn't with my conversion, and param() is blank, too, so that's not it.

But my mind is blown because the script seems to continue past this section and still writes the data to MySQL... including what I'm expecting to be in $contents{'username'}! Even though it thinks the param is blank in the earlier part of the script?

There's definitely a logic error here that's new for this version, because this script worked fine for 10 years. And another script has been letting scammers submit things that should be getting blocked by redirecting and exiting, so it appears to be writing MySQL before it redirects?