Strange request skipped all before_dispatch hooks

[vanishingESCkey]

Hi, I'm seeing something strange in my Mojolicious 8.50 app.

I have two before_dispatch hooks: one for authentication (cookie-based) and one for request logging to MySQL. These are normally triggered for every request. However, I noticed a request from a suspicious client in my NGINX logs:

49.113.95.xxx - - [02/Jun/2025:19:10:22 +0200] "GET / HTTP/1.1" 500 7285 "-" "Go-http-client/1.1"

This request somehow:

• Reached a protected route (/)
• Caused a 500 error in the app (due to self->user being undef)
• Skipped both before_dispatch hooks
• Did not get logged into the MySQL table, which is normally done in the logging hook

So it seems like before_dispatch was never called for this request.

I'm wondering:

• Has anyone else experienced before_dispatch being skipped like this?
• Could a malformed or bot-crafted request (e.g., from a Go client) bypass Mojolicious routing/hooks?
• Is this a known issue in 8.50 that might have been fixed in later releases?

Would really appreciate any insights or tips on how to catch or defend against this kind of request.

Thanks!

[christopherraa]

Hi there. I have not seen that particular issue of a client being able to bypass internal hooks, and do not believe that to be very probable in this case.

I would rather think this is an issue of ordering, ie. which hooks are executed and at what time, and what kind of processing goes on there. My advice would be to dive into your code and make sure that you first of all have graceful handling of cases like you mention here where a protected endpoint is called without the user being authenticated / having a valid session. Meaning; get rid of cases such as the one you mentioned where you get a 500 due to a user not being authenticated. Then I would look into mapping which hooks are executed when and check, if there are multiple of them in the same request stage, if any particular ordering is required for them to function correctly.

If however you do find that there is a vector where a malicious actor can form a request that does bypass hooks then please do let us know so we can look into it. A working example would be greatly appreciated and help expedite patching.

[s1037989]

This request somehow:

Understanding the exact details of the request would be interesting and useful for creating a repeatable test case. Unfortunately, it's too late to turn this on after the bad request occurred, and you generally wouldn't want this running all of the time. Maybe run it in a separate honeypot app for future investigations?

Try a after_build_tx hook:

#  $self->plugin('CaptureTX' => {
#    skip_cb => sub ($app, $tx, $stream, $bytes, $asset) {
#      # return true to skip capturing requests you don't care to capture
#      return 1 if substr($bytes, 0, 14) eq 'GET / HTTP/1.1';
#      return 1 if substr($bytes, 0, 40) =~ m!^\w+ (/admin/minion)!;
#    }
#  });

package Mojolicious::Plugin::CaptureTX;
use Mojo::Base 'Mojolicious::Plugin', -signatures;

use Mojo::File qw(path);
use Mojo::Home;
use Mojo::Util qw(encode);

use constant CAPTURE_TX => $ENV{MOJO_CAPTURE_TX} // 1;

has tx_dir  => sub { Mojo::Home->new->detect->child('tx') };
has skip_cb => sub { sub {} };

sub register {
  my ($self, $app, $conf) = @_;

  my $path = path($conf->{path}) if $conf->{path};
  $self->tx_dir(path($conf->{path})) if $path;
  return unless -d $self->tx_dir && CAPTURE_TX;
  $app->log->debug(sprintf 'Capturing Transactions in %s', $self->tx_dir);
  $self->skip_cb($conf->{skip_cb}) if $conf->{skip_cb};
  $app->hook(after_build_tx => sub { $self->_capture($_[1], $_[0]) });
  $app->helper(capture_tx => sub { $self->_capture($_[0]->app, $_[1]) });
}

# Capture real requests for replaying later
# $ nc localhost 3000 < tx_dir/abc123
sub _capture ($self, $app, $tx) {
  $tx->on(connection => sub ($tx, $connection) {
    my $request_id = $tx->req->request_id;
    $self->{assets}->{$connection} //= Mojo::Asset::File->new(cleanup => 0, path => $self->tx_dir->child(sprintf "%s.%s", $connection, $request_id));
    $request_id = $self->{assets}->{$connection}->{request_id} //= $request_id;
    my $stream = Mojo::IOLoop->stream($connection);
    $stream->on(read => sub ($stream, $bytes) {
      my $asset = $self->{assets}->{$connection} or return;
      return if !$bytes || $self->skip_cb->($app, $tx, $stream, $bytes, $asset);
      $app->log->trace(sprintf '[%s] [%s] got %d bytes (%d total so far)', $request_id, $connection, length($bytes), length($bytes) + $asset->size);
      eval { $asset->add_chunk(encode 'UTF-8', $bytes) };
      if ($@) {
        $app->log->error(sprintf 'error writing %s: %s', $asset->path, $@);
      }
      else {
        $app->log->debug(sprintf 'wrote %d bytes to %s', $asset->size, $asset->path);
      }
    });
    $stream->on(close => sub ($stream) {
      my $asset = $self->{assets}->{$connection} or return;
      $app->log->debug(sprintf '[%s] [%s] captured %d-byte tx', $request_id, $connection, $asset->size) if $asset->size;
      delete $self->{assets}->{$connection};
      path($asset->path)->remove unless $asset->size;
    });
  });
}

1;

[guest20]

There are some requests that don't make it to the code - bad request line, large request body/over sized attachments and read time-outs all stop dispatch, it could be one of those cases...

You might get a more detailed picture by:

1. having nginx-generated request ids passed along to your app and logged
2. including the request id and $request_body_file in your nginx log format and setting client_body_in_file_only on;
3. set up a cron job to clear out that temp dir, and or at least gz the entries

Then you can can import your nginx logs along side your app-generated logs and find out which requests managed to escape the logging hook and what nginx resolved to do with them. In interesting cases you can go find the full request in the temp dir

[vanishingESCkey]

Thanks everyone for the input!

As @christopherraa suggested, I had to "dive into my code" — and that helped a lot. It turned out the request shown in the access log was actually a WebSocket request, and I completely missed that at first.

What I also didn’t realize is that regular routes are still accessible via WebSocket connections, not just those explicitly defined with $r->websocket(..) . On top of that, both of my plugins (for authentication and logging) were ignoring ws requests, the authorization for ws was postponed to the ws route.

The good news is that I tracked it down to some legacy code that wasn’t properly secured — so this helped me catch a real security gap. Appreciate the help — and big respect for Mojolicious, solid and reliable as always.