CIVI-PSA-2023-01: Smarty v2 Audit

CiviCRM includes the Smarty v2 templating engine. Templates are defined by core code, by third-party extensions, and by configurable content. The upstream smarty.net project has stopped publishing security backports for Smarty v2, so civicrm.org will do so (until a migration to a newer Smarty is complete).

As part of this, the CiviCRM security team has done a detailed audit to compare recent issues from v2/v3/v4.

The following one issue does impact Smarty v2. We've ported a fix to CiviCRM.

• Sandbox escape by math function (GHSA-29gp-2c3m-3j6m).
  • (See CIVI-SA-2023-07)

The following four issues do not impact Smarty v2. They relate to new behaviors that only exist in v3+.

• PHP code injection by malicious block or filename (GHSA-634x-pc3q-cf4c)
  • (The vulnerability arises in how Smarty v3+ generates certain debug information. However, this debug information is not generated at all in v2.)
• Access to restricted PHP code by dynamic static class access (GHSA-4h9c-v5vg-5m6m)
  • (The vulnerability arises from a new notation for calling static class members. However, this notation is not available in v2.)
• PHP code injection by malicious function name (GHSA-3rpf-5rqv-689q)
  • (The vulnerablity arises from a new notation for inline {function}s or TplFunctions. However, this notation is not available in v2.)
• Sandbox escape through template_object (GHSA-w5hr-jm4j-9jvq)
  • (Smarty v2 has neither {$smarty.template_object} nor static-class references.)

The following one issue has hypothetical considerations but does not impact CiviCRM's usage of Smarty v2.

• Cross site scripting vulnerability in Javascript escaping (GHSA-7j98-h7fp-4vwj)
  • (Smarty supports multiple techniques for encoding Javascript. By convention, CiviCRM and its universe of extensions generally use the safer json_encode technique -- rather than the riskier escape:javascript technique.)
  • (It is theoretically possible to create a Smarty v2 application with this defect -- that is, by using the escape:javascript string-encoder as a way to generate "template-literals". However, this is anachronistic -- "template-literals" should not naturally appear in applications or coding-conventions from the era of Smarty v2.)

civicrm.org will continue to provide backports/analyses for future issues -- until such time as we are able to coordinate a migration to a newer major release of Smarty.