CVE-2024-58134: Mojolicious Session Cookie Auth Bypass

CVE-2024-58134 Overview

CVE-2024-58134 affects Mojolicious, a real-time web framework for Perl. Starting with version 0.999922, Mojolicious uses a hard-coded string or the application's class name as the default HMAC session cookie secret. Applications that never override this default expose predictable secrets to attackers. An attacker who guesses or recovers the secret can compute valid HMAC signatures and forge session cookies. This enables session tampering and account takeover by impersonating other authenticated users. The weakness is classified as [CWE-321] Use of Hard-coded Cryptographic Key.

Critical Impact
Predictable default HMAC secrets allow attackers to forge session cookies and hijack authenticated user sessions across affected Mojolicious deployments.

Affected Products

Mojolicious for Perl, versions from 0.999922 onward with default secret configuration
Perl applications built on Mojolicious that do not set an explicit secrets value
Debian Perl packages redistributing vulnerable Mojolicious releases

Discovery Timeline

2025-05-03 - CVE-2024-58134 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-58134

Vulnerability Analysis

Mojolicious signs session cookies with an HMAC keyed by the application's secrets attribute. When a developer does not configure secrets, the framework falls back to a value derived from a hard-coded string or the application's class name. Both fallbacks are predictable and low-entropy. Session cookies remain readable to clients, but the HMAC is expected to prevent tampering. Because the key material is guessable, the integrity guarantee collapses. Attackers can enumerate common class names, brute-force short secrets offline against a captured cookie, or reuse published defaults to sign arbitrary session payloads. A signed forged cookie is accepted by the server as authentic, letting the attacker set arbitrary session values including user identifiers.

Root Cause

The root cause is insecure-by-default cryptographic configuration. The framework selects a deterministic fallback key when secrets is unset instead of generating a strong random value at install or first run. Developers who follow tutorials or ship applications without hardening inherit the weak default silently, with no runtime error. See the MetaCPAN Mojolicious Source for the historical default and the Synacktiv Article on Cookies for exploitation research.

Attack Vector

The attacker requests any page from the target Mojolicious application to obtain a session cookie. They extract the base64-encoded session payload and the HMAC. The attacker then attempts HMAC verification using the known hard-coded default, the class name derived from public reconnaissance, and common variants. Tooling such as the proposed Hashcat module accelerates offline recovery. Once the correct key is identified, the attacker crafts a session payload, signs it, and submits it as a cookie to impersonate any user.

Refer to the Medium Article on Mojolicious for a full exploitation walkthrough. No fabricated exploit code is included here.

Detection Methods for CVE-2024-58134

Indicators of Compromise

Session cookies signed with the framework's documented default secret or the application's class name
Unexpected privilege changes tied to session identifiers that do not correspond to a prior login event
Multiple valid sessions for a single user originating from distinct IP addresses in a short window
Log entries showing the Your secret passphrase needs to be changed warning being ignored across restarts

Detection Strategies

Grep application code and configuration for missing app->secrets([...]) initialization
Inspect running processes and configuration files for the default warning message emitted by Mojolicious at startup
Replay captured session cookies against a local test instance seeded with the default secret to confirm signature validity

Monitoring Recommendations

Alert on authentication events where the session cookie predates the most recent secret rotation
Correlate web access logs with authentication logs to flag sessions created without a login request
Track deployments of Mojolicious versions and confirm each has an explicit non-default secrets value

How to Mitigate CVE-2024-58134

Immediate Actions Required

Set a high-entropy value for app->secrets in every Mojolicious application before returning to production traffic
Rotate all active session cookies by invalidating existing signatures after updating the secret
Upgrade Mojolicious to a release that enforces or generates a strong default, tracked in Mojo Pull Request 2252
Audit downstream Debian Perl packages using the guidance in Debian Perl List Message 16

Patch Information

Upstream fixes are tracked across Mojo Pull Request 1791, Mojo Pull Request 2200, and Mojo Pull Request 2252. Review the Mojolicious FAQ Entry for supported upgrade paths and mandatory configuration steps after patching.

Workarounds

Generate at least 32 bytes of random data from /dev/urandom and assign it to app->secrets at startup
Store the secret outside source control in an environment variable or secrets manager and load it at boot
Provide a list of secrets to app->secrets so older cookies remain valid during rotation while new cookies use the leading value
Enforce HttpOnly, Secure, and SameSite=Strict attributes on session cookies to reduce cookie exposure

bash

# Configuration example: set a strong secret in a Mojolicious app
export MOJO_SECRET="$(head -c 48 /dev/urandom | base64)"

# In lib/MyApp.pm inside the startup() method:
#   my $secret = $ENV{MOJO_SECRET}
#     or die 'MOJO_SECRET is required';
#   $self->secrets([$secret]);