Related to #1589

Analysis

Summary of existing PHP 8.2 behavior based on the RFC:

// Extra data (after 1st semicolon) will be silently ignored
var_dump(unserialize('i:5;i:6;')); // int(5)

Updated behavior in PHP 8.3:

// Warning: unserialize(): Extra data starting at offset 4 of 8 bytes
var_dump(unserialize('i:5;i:6;'));

Top 2000 Packages

Found thousands of occurrences, but only 2 where it can be reliably inferred:

• drupal/core - plain serialized string in a test
• magento/magento-coding-standard - empty string in a test

Source: https://gist.github.com/afilina/d385de0733d0293fd4067824bae60b34

Detection in PHP 8.2

• unserialize('i:5;i:6;') - Trailing data: valid
• @unserialize('i:5;i:6;') - Trailing data: valid

See "Syntax Variations" for more examples.

Detection in PHP 8.3

• unserialize('i:5;i:6;') - Trailing data: warning
• @unserialize('i:5;i:6;') - not sure what to expect, since this silences the PHP warning, but also might get promoted to an error in the future, so maybe worth flagging anyway.

See "Syntax Variations" for more examples.

Syntax Variations & Detectability

Since unserialize() is useful mostly in contexts where the input is a variable or a complex expression, reliably detecting it might be difficult.

Additionally, the sniff needs to be able to reproduce the deserialization to detect trailing bytes, which I believe might be overly complex.

At first glance, this seems not sniffable. Feedback welcome.

• False positives - not calls to the unserialize() function, though they contain the string
• Cross-version valid
• Pre-existing invalid - notices and deprecations on various types / values before the RFC
• 8.3 invalid - warnings since PHP 8.3

References

• RFC: Make unserialize() emit a warning for trailing bytes
• PR: Make unserialize() emit a warning for trailing bytes
  • Commit
• PHP Manual:
  • Migrating from PHP 8.2.x to PHP 8.3.x - Other Changes
  • unserialize