Cron-utils is a Java library to parse, validate, migrate crons as well as get human readable descriptions for them. In cron-utils before version 9.1.3, a template Injection vulnerability is present. This enables attackers to inject arbitrary Java EL expressions, leading to unauthenticated Remote Code Execution (RCE) vulnerability. Only projects using the @Cron annotation to validate untrusted Cron expressions are affected. This issue was patched in version 9.1.3. References: https://github.com/jmrozanec/cron-utils/security/advisories/GHSA-pfj3-56hm-jwq5 https://github.com/jmrozanec/cron-utils/issues/461 Upstream patch: https://github.com/jmrozanec/cron-utils/commit/4cf373f7352f5d95f0bf6512af8af326b31c835e
Marking Red Hat Integration Camel K (camel-quarkus) as having a low impact as it ships a vulnerable version of the cron-utils library through its use in quarkus-scheduler, however the vulnerable @Cron annotation is not used. Marking Red Hat build of Quarkus as having a low impact as it ships a vulnerable version of the cron-utils library, however the vulnerable @Cron annotation is not used
A word on scoring, our scoring is currently 8.1/CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H and this differs from NVD of 9.8/CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H and although we agree with most aspects of the scoring we believe there are extra considerations to the attack complexity which have not been accounted for. Exploitability Metrics: Attack Vector Network (AV:N) - Somewhat agree here, cron-utils is a utility library so its possible it will be dealing with data originating from a network source, though this is end application specific and a factor in Attack Complexity. Attack Complexity Low (AC:L) -> Attack Complexity High (AC:H): We disagree with the original scoring of a low attack complexity, we believe the impact is significantly different depending on the specific applications handling, that is to say a successful attack depends on conditions beyond the attacker's control, we believe those conditions are - *) The cron-utils would need to be processing unsanitized user input, although we have to assume the @Cron annotation will be in use for scoring this vulnerability that does not extend to the wider configuration and use of cron-utils in the end application. *) The attacker will also need to invest a significant amount of time to overcome inherent differences of the underlying software stack being used, mainly the JavaEL implementation and if any frameworks such as OSGi are being used, these are factors outside the attackers control and ones without any guarantee of consistency. Privileges Required None (PR:N) - Agree here, the attacker does not need to be a privileged user eg. no login required to exploit the base flaw. User Interaction None (UI:N) Agree here, a user does not need to be coerced into performing any action for this flaw. Scope Unchanged (S:U) Agree here, the attacker will not be able to escape the scope of the executing JVM solely due to this flaw Impact Metrics: Confidentiality High (C:H) We agree here, if the attacker has the ability to execute arbitrary expressions they will have access to all the resources available to the executing JVM Integrity High (I:H) We agree here, if the attacker has the ability to execute arbitrary expressions they will have access to all the resources available to the executing JVM Availability High (A:H) Agree here, if the attacker has the ability to execute arbitrary expressions they will have the ability to deny access to users of the end application
This issue has been addressed in the following products: Red Hat build of Quarkus Via RHSA-2021:1004 https://access.redhat.com/errata/RHSA-2021:1004
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-26238
This issue has been addressed in the following products: Red Hat Integration Via RHSA-2021:3205 https://access.redhat.com/errata/RHSA-2021:3205
This issue has been addressed in the following products: Red Hat Integration Via RHSA-2021:3207 https://access.redhat.com/errata/RHSA-2021:3207