Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Now, this is quite innocent: it produces following output: The problem is that nowhere I told valinor that it could use Throwable#getMessage(). This is a problem with cases where you get: an SQL exception showing an SQL snippet a DB connection exception showing DB ip address/username/password a timeout detail / out of memory detail (exploring DDoS possibilities) This allows for potential data exfiltration, DDoS, enumeration attacks, etc.
Recommended action: Upgrade to 0.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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: 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.
Recommended action: Upgrade to 0.7.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.