CVE-2026-33417: Wallos Auth Bypass Vulnerability

CVE-2026-33417 Overview

CVE-2026-33417 is an insufficient session expiration vulnerability affecting Wallos, an open-source, self-hostable personal subscription tracker. Prior to version 4.7.2, password reset tokens in Wallos never expire. While the password_resets table includes a created_at timestamp column, the token validation logic never checks it. This allows a password reset token to remain valid indefinitely until it is used, enabling an attacker who intercepts a reset link at any point to use it days, weeks, or months later.

Critical Impact

Attackers who intercept password reset links can exploit them indefinitely to gain unauthorized account access, potentially compromising user credentials and personal subscription data.

Affected Products

• Wallosapp Wallos versions prior to 4.7.2
• Self-hosted Wallos instances without the security patch
• All deployments using the vulnerable password reset functionality

Discovery Timeline

• 2026-03-24 - CVE-2026-33417 published to NVD
• 2026-03-26 - Last updated in NVD database

Technical Details for CVE-2026-33417

Vulnerability Analysis

This vulnerability stems from an insufficient session expiration implementation (CWE-613) in the Wallos password reset functionality. The application generates password reset tokens and stores them in the password_resets database table along with a created_at timestamp. However, the validation logic that processes these tokens when a user clicks a reset link fails to verify the token's age against the timestamp.

The impact of this vulnerability allows attackers to exploit password reset tokens at any point after interception. Network-based attackers who can observe or capture password reset emails (through compromised email accounts, network sniffing, or man-in-the-middle attacks) can store these tokens and use them at their convenience, even months after the original reset request was made.

Root Cause

The root cause is a missing time-based validation check in the password reset token verification logic. While the database schema was designed to support token expiration through the created_at column, the application code never implemented the corresponding check to invalidate tokens after a reasonable time period. This oversight left tokens valid indefinitely until consumed.

Attack Vector

The attack requires network access and some user interaction. An attacker must first intercept a password reset link, which can be accomplished through various methods such as compromising the user's email account, performing network-level interception, or exploiting email forwarding rules. Once a token is captured, the attacker can use it at any time to reset the victim's password and gain unauthorized access to their Wallos account.

// Security patch - New cronjob for cleaning up expired tokens
// Source: https://github.com/ellite/Wallos/commit/90bb6186ee4091590b6efdef824c85f2494ff2bb

<?php

require_once 'validate.php';
require_once __DIR__ . '/../../includes/connect_endpoint_crontabs.php';

$deleted = $db->exec("DELETE FROM password_resets WHERE created_at <= datetime('now', '-1 hour')");

if ($deleted) {
    echo "Expired password reset tokens cleaned up successfully.\n";
} else {
    echo "No expired password reset tokens to clean up.\n";
}

$db->close();
?>

The patch introduces a new cronjob script (cleanupresettokens.php) that automatically purges password reset tokens older than one hour from the database.

# Cronjob configuration addition
# Source: https://github.com/ellite/Wallos/commit/90bb6186ee4091590b6efdef824c85f2494ff2bb

0 3 * * * /usr/local/bin/php /var/www/html/endpoints/cronjobs/cleanupresettokens.php >> /var/log/cron/cleanupresettokens.log 2>&1

Detection Methods for CVE-2026-33417

Indicators of Compromise

• Password reset tokens in the password_resets table with created_at timestamps older than one hour that have been subsequently used
• Unusual password reset activity from IP addresses or geolocations different from the original request
• Multiple successful password resets for accounts using tokens generated days or weeks prior
• Authentication logs showing password changes followed by immediate login from unfamiliar locations

Detection Strategies

• Query the password_resets table for tokens older than one hour: SELECT * FROM password_resets WHERE created_at <= datetime('now', '-1 hour')
• Monitor authentication logs for password reset completions where the time between token generation and use exceeds expected thresholds
• Implement alerting on password reset events that occur more than 24 hours after the reset request was initiated
• Review web server access logs for password reset endpoint usage patterns

Monitoring Recommendations

• Enable detailed logging for all password reset operations including token generation, validation attempts, and successful resets
• Set up automated alerts for password reset completions using tokens older than the expected expiration window
• Monitor the password_resets table size and age distribution of tokens to identify potential exploitation attempts
• Track user reports of unauthorized account access following password reset activity

How to Mitigate CVE-2026-33417

Immediate Actions Required

• Upgrade Wallos to version 4.7.2 or later immediately
• Purge all existing password reset tokens from the password_resets table after upgrading
• Force password resets for any accounts that may have been compromised
• Review authentication logs for suspicious activity involving password resets

Patch Information

The vulnerability has been patched in Wallos version 4.7.2. The fix introduces a new cronjob (cleanupresettokens.php) that runs daily at 3:00 AM to automatically delete password reset tokens older than one hour. This ensures tokens have a limited validity window, significantly reducing the attack surface.

For detailed patch information, refer to the GitHub Commit and the GitHub Security Advisory.

Workarounds

• If immediate upgrade is not possible, manually delete old password reset tokens using: DELETE FROM password_resets WHERE created_at <= datetime('now', '-1 hour')
• Implement a manual cronjob to periodically clean up expired tokens until the patch can be applied
• Consider temporarily disabling the password reset functionality until the upgrade is complete
• Advise users to use password reset links immediately and report any unexpected reset emails

# Manual cleanup command for SQLite database
sqlite3 /path/to/wallos/db/wallos.db "DELETE FROM password_resets WHERE created_at <= datetime('now', '-1 hour');"

# Add temporary cronjob for cleanup (run hourly)
echo "0 * * * * sqlite3 /path/to/wallos/db/wallos.db \"DELETE FROM password_resets WHERE created_at <= datetime('now', '-1 hour');\"" | crontab -