Several CiviCRM fields are stored with an unconventional "HTML-esque" encoding. Consumers which read or write these fields via APIv4 have been prone to mishandling those strings (which can lead to cross-site scripting vulnerabilities and/or quirky outputs). In APIv3, the issue was previously mitigated by automatically transcoding strings. This revision extends the same mitigation to APIv4.
Most APIv4 consumers should automatically become more secure with this update.
Hypothetically, some APIv4 consumers may need to be revised -- for example, if you independently observed a cross-site scripting vulnerability or miscoded symbol output when handling strings from APIv4, and if you mitigated by explicitly applying "HTML-esque" encoding/decoding, then you may need to retest/revise. However, we have not encountered a consumer like this - and we do not expect this situation to be common.
- CiviCRM 5.19.0 - 5.19.1
- Any previous version of CiviCRM - with extension "org.civicrm.api4" before 4.5.3 or 4.4.4
- CiviCRM 5.19.2 - with APIv4 builtin
- CiviCRM 5.13.7 - with bundled extension "org.civicrm.api4" (v4.4.4)
- Any previous version of CiviCRM - with extension "org.civicrm.api4" (v4.4.4+ or v4.5.3+)
Upgrade to the latest version of CiviCRM
Tim Otten of CiviCRM for reporting and fixing the issue
security/core#67