Skip to content

security: add allowed_classes => false to unserialize() in brute-force protection#1289

Open
XananasX7 wants to merge 1 commit into
vrana:masterfrom
XananasX7:fix/auth-unserialize-allowed-classes
Open

security: add allowed_classes => false to unserialize() in brute-force protection#1289
XananasX7 wants to merge 1 commit into
vrana:masterfrom
XananasX7:fix/auth-unserialize-allowed-classes

Conversation

@XananasX7
Copy link
Copy Markdown

Summary

auth.inc.php reads serialized brute-force tracking data from temp files and passes it to unserialize() without specifying allowed_classes.

The stored data structure is array<ip_address, [expiry_time, count]> — plain arrays of integers. There's no reason for objects here.

Without the restriction, an attacker who can write to the temp directory (e.g., through a path traversal or a symlink attack on the temp file path) can plant a serialized object payload that gets instantiated when Adminer reads its brute-force protection data.

Fix

Added ['allowed_classes' => false] to both unserialize() calls in auth.inc.php. Zero behavior change for valid data.

The brute-force protection stores invalid login attempts as serialized
PHP data in a temporary file: array<ip_address, [expiry_time, count]>.
These are plain arrays of integers — no objects are stored.

Without allowed_classes, an attacker who can write to the temp directory
(e.g., via a path traversal or symlink attack on the temp file path) can
plant a malicious serialized payload that gets instantiated when Adminer
reads the brute-force data.

allowed_classes => false closes this vector with no behavior change.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant