hardening(mikrotik_users): restrict unserialize() to scalar types to prevent object injection

[somethingwithproof]

Summary

mikrotik_users.php:63 calls unserialize() on a POST parameter without the ['allowed_classes' => false] option. Any authenticated Cacti user can POST a crafted serialised payload that instantiates arbitrary PHP objects, enabling property-oriented programming (POP) gadget chain execution if suitable classes exist in the autoloader.

The form at line 157 emits the serialised value without a CSRF token, widening the attack surface to cross-site POST from any page the victim visits.

Details

Field	Value
File	mikrotik_users.php
Line	63
Auth required	Yes — authenticated Cacti user
CWE	CWE-502

// Before
$selected_items = unserialize(stripslashes(get_request_var('selected_items')));

// After
$selected_items = unserialize(stripslashes(get_request_var('selected_items')), ['allowed_classes' => false]);
if (!is_array($selected_items)) {
    $selected_items = [];
}

Fix applied in branch security/1-restrict-unserialize-allowed-classes.

Acceptance criteria

• ['allowed_classes' => false] passed to all unserialize() calls on request data
• Non-array result coerced to empty array before downstream loop
• Regression test in tests/Security/ObjectInjectionTest.php

[somethingwithproof]

Closing public issue — moving to private security advisory per responsible disclosure policy.

[somethingwithproof]

Validated by xAI Grok security review (2026-04-08): TRUE POSITIVE, MEDIUM severity. The allowed_classes=false mitigation reduces risk but does not eliminate deserialization issues. Recommend replacing with sanitize_unserialize_selected_items() or json_decode().