choices/choices 9.0.1 is affected by polyfill.io

Created a patch that replaces the domain based on https://github.com/Choices-js/Choices/commit/0dae0283740f4f619c7589e7b16...

There is also a polyfill.io url in webform.libraries.yml, under js for the external library webform.choices

This external library is a dependency of the webform.element.choices, which is conditionally attached in prepare() for the Select element plugin class Plugin/WebformElement/Select.php.

// Enhance select element using select2, chosen, or choices.
    if (isset($element['#select2']) && $select2_exists) {
      $element['#attached']['library'][] = 'webform/webform.element.select2';
      $element['#attributes']['class'][] = 'js-webform-select2';
      $element['#attributes']['class'][] = 'webform-select2';
    }
    elseif (isset($element['#choices']) && $choices_exists) {
      $element['#attached']['library'][] = 'webform/webform.element.choices';
      $element['#attributes']['class'][] = 'js-webform-choices';
      $element['#attributes']['class'][] = 'webform-choices';
    }
    elseif (isset($element['#chosen']) && $chosen_exists) {
      $element['#attached']['library'][] = 'webform/webform.element.chosen';
      $element['#attributes']['class'][] = 'js-webform-chosen';
      $element['#attributes']['class'][] = 'webform-chosen';
    }

BUT, It looks like the system will only offer one of the above, and the preferred option is Select2, so Choices is a fallback from that.

// If select2, choices, or chosen is not available,
    // see if we can use the alternative.
    $select2_exists = $this->librariesManager->isIncluded('jquery.select2');
    $choices_exists = $this->librariesManager->isIncluded('choices');
    $chosen_exists = $this->librariesManager->isIncluded('jquery.chosen');
    $default_select = ($select2_exists ? '#select2' :
      ($choices_exists ? '#choices' :
        ($chosen_exists ? '#chosen' : NULL)
      )
    );

So i think the default setup with Select2 available means this polyfill.io script isn't loaded, but it should be fixed in webform.libraries.yml, or just removed altogether since it's just one of two fallbacks from Select2.

I wouldn't remove it altogether. It's not a "fallback", it's a valid configuration option. I'm sure there's lots of sites using it.

Thank you for the patch. I've emailed the maintainer of the Choices library to request action and offer to find a new maintainer. Hopefully the related PR, which has already been reviewed and approved, will soon be merged.

Just chiming in here from a different perspective: our group has disallowed the use of Choices.js for years due to inherent accessibility issues.

Given that...

1. The software hasn't had a commit in ~3 years
2. The software ships with a vulnerability
3. The Select2 implementation ranked higher in [our] a11y testing

Might it be an alternative to deprecate / disable its use in Webform by default? Shipping what is effectively abandonware doesn't seem sustainable.

Savvy users can also utilize composer to further harden their applications:

Example: Nuke the vulnerable file from orbit on `composer install`

    "scripts": {
        "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
        "post-install-cmd": [
          "rm docroot/libraries/choices/public/index.html"
        ]
    }

🛡️

Another thing you can do in composer.json is tell Composer not to even try downloading and installing the `choices/choices` library even if it is required by another package, like webform's `composer.libraries.json`. This is informing Composer that I already have a package that replaces the functionality of all versions of `choices/choices` (even though I don't have a replacement). So, Composer will not attempt to download and install `choices/choices`..

"replace": {
    "choices/choices": "*"
}

Be aware that in case of choices 9.0.1 (contrary to the current master), which gets included by webform, the URL is *not* cdn.polyfill.io but <script src="https://polyfill.io/v3/polyfill.min.js?features=es5%2Ces6%2CArray.prototype.includes%2Cfetch%2CCustomEvent%2CElement.prototype.closest"></script> as mentioned by OP.
If you use some kind of search & replace mechanism, it should rather be something along these lines:

"scripts": {
    "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
    "post-install-cmd": [
      "sed -i 's#https://polyfill\.io/#https://polyfill-fastly\.io/#g' web/libraries/choices/public/index.html"
    ]
},

As already mentioned in [ 🐛 polyfill.io Library is no longer considered safe to use Fixed ], I'd very much favor that composer.libraries.json included this or some other form of patching the file without user interaction for the time being. Users should get a secure setup by just running composer update for their drupal installation, at least that's my way of thinking.
We can update to a fixed version later on (or switch to a better maintained lib as mentioned above) anyway.