unserialize(): Error at offset — verifying backup integrity before object instantiation

Question

ContextRestoring application state from serialized PHP backups requires calling unserialize() on stored strings. When a backup file is truncated or corrupted during transfer, PHP emits the warning unserialize(): Error at offset and returns false. However, the function may still partially instantiate objects before failing, and any __wakeup() or __destruct() magic methods on those partial objects can execute side effects such as database connections or file operations.ConstraintSince PHP 7.0 the allowed_classes option restricts which classes may be instantiated, yet internal classes like DateTime and Exception are always permitted even when allowed_classes => false. No built-in checksum or signature verification exists for serialized data, so integrity checks must be implemented externally (e.g., HMAC) before unserialize() is called. PHP 8.1+ further deprecates the Serializable interface in favor of __serialize/__unserialize, meaning legacy backups that rely on custom serialization logic may trigger deprecation notices or fail to restore.Open questionsWhat is the exact sequence of magic-method execution when unserialize() encounters a truncated string — does __wakeup() run on partially constructed objects before the offset error is raised?How should a verification pipeline order HMAC validation, allowed_classes restriction, and legacy Serializable compatibility checks to guarantee that no object instantiation occurs on corrupted or untrusted backup data?

Tasadduq Burney · Answer

AnswerWhen unserialize() encounters a truncated serialized string, it stops parsing at the point of corruption, emits the warning "unserialize(): Error at offset", and returns false. Any objects that were completely parsed before the truncation point have already been instantiated, so their __wakeup() method (if defined) will have run. If the truncation occurs inside the serialized representation of an object, that object is incomplete and __wakeup() is not invoked.Confirmed factsunserialize() returns false on error; the warning is emitted regardless of the return value.The allowed_classes => false option blocks instantiation of user‑defined classes but does not affect internal PHP classes such as DateTime or Exception.No built‑in checksum exists for serialized data; integrity must be verified externally (e.g., HMAC) before calling unserialize().PHP 8.1+ deprecates the Serializable interface in favor of __serialize/__unserialize; legacy data may trigger deprecation notices.Steps for this caseCompute an HMAC of the backup string using a secret key known only to your application and compare it to the stored HMAC; abort if they differ.Set the allowed_classes option (e.g., ['stdClass'] or false) to restrict which classes may be instantiated.Call unserialize($string, ['allowed_classes' => $allowed]);Check that the result is not false and, if needed, validate the restored objects (type, property values). Only after this validation should you consider the backup successfully restored.To tailor the advice, please confirm the PHP version you are running (e.g., 7.4, 8.0, 8.2).

unserialize(): Error at offset — verifying backup integrity before object instantiation

Context

Constraint

Open questions

1 answer

Answer

Confirmed facts

Steps for this case

Your perspective belongs here.

0 question comments