CIVI-PSA-2026-01: Quickform Widgets

The March 18 release includes updates to several security issues -- notably CIVI-SA-2026-09: Dropdown Options (XSS). Some updates could have side-effects for other screens which use Quickform widgets (in CiviCRM and third-party add-ons), so we want to explore this in more detail.

Motivation

Consider the configuration options that appear in "Administer => Customize Data => Dropdown Options", such as "Phone Types" and "Individual Prefixes". These options are referred to generically as "Option Groups" and "Option Values", and they appear in numerous parts of the system. The visual form may vary (with select lists or radio lists or checkbox lists), but they feed off a common data-structure.

This data-structure feeds into many screens. In some screens, options display safely, but in others the options are poorly encoded and ripe to abuse. In particular, under CIVI-SA-2026-09, we find a recurring theme -- vulnerabilities frequently occur on web-pages which display options using the "Quickform" renderer.

The developers and reviewers who worked on CIVI-SA-2026-09 believe this is a systemic problem in Quickform. The contracts in Quickform are unusual in how they quietly omit ordinary encoding rules. While the design is not strictly insecure, it tends to invite insecure usage, even among jaded developers. Quickform is used by civicrm-core as well as many third-party add-ons, so this tendency toward insecure options is widespread.

Changes

The security updates (CiviCRM v6.12.1 and v6.10.3) change the behavior of several Quickform widgets:

• advcheckbox
• checkbox
• hiddenselect
• radio
• select

These widgets will now enable escaping by default, which addresses security issues across many screens (in civicrm-core and third-party add-ons).

However, it comes with a risk -- some screens may now suffer double-encoding problems. (If the old screen provided its own encoding, and if Quickform provides new encoding, then you have double-encoding.) With a double-encoding, the user may see extraneous characters (such as < or &). This problem is confusing, but it is also safer than the status-quo.

To fix a double-encoding, you will need a patch to the relevant form. For example, if your form escapes the text on its own, then you can tell Quickform that the data is already escaped:

$element = $qf->addRadio($elementName, $label, $choice, [], NULL, FALSE, $choiceAttrs);
$element->setTextEscaped();

That snippet will work in v6.12.1. If the form needs to work across a wider range of CiviCRM versions, then use a conditional:

$element = $qf->addRadio($elementName, $label, $choice, [], NULL, FALSE, $choiceAttrs);
if (method_exists($element, 'setTextEscaped')) {
  $element->setTextEscaped();
}

Meta

This is not the ideal way to make a change in Quickform. But it is less bad than the alternatives.

CiviCRM's general strategy for changing Quickform is to incrementally replace it -- by re-implementing screens with newer tools (such Search Kit and Form Builder). This is a long process. In the mean time, we still have a number of screens which depend upon it which require interim work.

An alternative approach is to keep Quickform in its current behavior, and incrementally hunt-down insecure callers. This is also a long process.

In either case (whether Quickform escaping is opt-in or opt-out), the subsequent game has similar dynamics -- it resembles Whac-A-Mole. You search over a large space to find and fix anomalies. The differences are:

• Opt-Out Escaping (Switch Quickform Immediately): The system generally becomes more secure. Some screens may display extra characters. These will present obvious symptoms (such as display < or &) -- which invites quicker remediation.
• Opt-In Escaping (Leave Quickform As-is): You don't have the issue of displaying extra characters, but many screens remain quietly insecure -- which leads to slower remediation.

Finally, numbers matter. How many existing screens are broken with the old behavior? How many existing screens will be broken with the new behavior? How many existing screens work equally well with either? This is difficult to establish precisely. However, the developers did spot-check third-party extensions and found general ranking:

• The largest group -- Most existing screens are likely to work with either. This is because they use Quickform with simple, static labels.
• The middle group -- Some moderate number of screens will be fixed.
• The smallest group -- A few screens may need updates to fix double-escaping.