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
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Sylius 1.0.0 to 1.0.16, 1.1.0 to 1.1.8, 1.2.0 to 1.2.1 versions of AdminBundle and ResourceBundle are affected by this security issue. This issue has been fixed in Sylius 1.0.17, 1.1.9 and 1.2.2. Development branch for 1.3 release has also been fixed. Description The following actions in the admin panel did not require a CSRF token: - marking order’s payment as completed - marking order’s payment as refunded - marking product review as accepted - marking product review as rejected Resolution The issue is fixed by adding a required CSRF token to those actions. We also fixed ResourceController‘s applyStateMachineTransitionAction method by adding a CSRF token check. If you use that action in the API context, you can disable it by adding csrfprotection: false to its routing configuration
Recommended action: Upgrade to 1.2.2, 1.1.9 or 1.0.17 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Request parameters injected inside an expression evaluated by symfony/expression-language package haven't been sanitized properly. This allows the attacker to access any public service by manipulating that request parameter, allowing for Remote Code Execution. The vulnerable versions include: <=1.3.13 || =1.4.0 <=1.4.6 || =1.5.0 <=1.5.1 || =1.6.0 <=1.6.3. Example In this case, $id can be prepared in a way that calls other services. If you visit /foo/"~service('doctrine').getManager().getConnection().executeQuery("DELETE FROM TABLE")~", it will result in a following expression expr:service('repository').find(""~service('doctrine').getManager().getConnection().executeQuery("DELETE FROM TABLE")~""), which will execute a query on the currently connected database. To find a vulnerability in your application, look for any routing definition that uses request parameters inside expression language. Patches This issue has been patched for versions 1.3.14, 1.4.7, 1.5.2 and 1.6.4.…
Recommended action: Upgrade to 1.6.4, 1.5.2, 1.4.7 or 1.3.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Request parameters injected inside an expression evaluated by symfony/expression-language package haven't been sanitized properly. This allows the attacker to access any public service by manipulating that request parameter, allowing for Remote Code Execution. The vulnerable versions include: <=1.3.13 || =1.4.0 <=1.4.6 || =1.5.0 <=1.5.1 || =1.6.0 <=1.6.3. Example In this case, $id can be prepared in a way that calls other services. If you visit /route?id="~service('doctrine').getManager().getConnection().executeQuery("DELETE FROM TABLE")~", it will result in a following expression expr:service('repository').find(""~service('doctrine').getManager().getConnection().executeQuery("DELETE FROM TABLE")~""), which will execute a query on the currently connected database. To find a vulnerability in your application, look for any routing definition that uses request parameters inside expression language. Patches This issue has been patched for versions 1.3.14, 1.4.7, 1.5.2 and 1.6.4.…
Recommended action: Upgrade to 1.6.4, 1.5.2, 1.4.7 or 1.3.14 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact ResourceBundle accepts and uses any serialisation groups to be passed via a HTTP header. This might lead to data exposure by using an unintended serialisation group - for example it could make Shop API use a more permissive group from Admin API. Anyone exposing an API with ResourceBundle's controller is affected. The vulnerable versions are: <1.3 || =1.3.0 <=1.3.12 || =1.4.0 <=1.4.5 || =1.5.0 <=1.5.0 || =1.6.0 <=1.6.2. Patches The patch is provided for ResourceBundle 1.3.13, 1.4.6, 1.5.1 and 1.6.3, but not for any versions below 1.3. After it is applied, It allows to choose only the groups that are defined in serializationgroups or allowedserializationgroups route definition. Any group not defined in those will not be used. This behaviour might be a BC break for those using custom groups via the HTTP header, please adjust allowedserializationgroups accordingly. Workarounds Service sylius.resourcecontroller.requestconfigurationfactory can be overridden with an implementation…
Recommended action: Upgrade to 1.6.3, 1.5.1, 1.4.6 or 1.3.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.