"WidgetVariante::renderVariantList" ("Core/Lib/Widget/WidgetVariante.php:298-330") and "WidgetSubcuenta::renderSubaccountList" ("Core/Lib/Widget/WidgetSubcuenta.php:290-321") build the "<tr onclick="...">" row for each modal hit by concatenating the user-controlled "referencia" / "codsubcuenta" field directly into a single-quoted JavaScript string literal inside an HTML "onclick" attribute. The defender's intuition is that "Tools::noHtml" (called in "Variante::test()" and "Subcuenta::test()") replaces "'" with the HTML entity "&#39;", neutralising the JavaScript string break. The intuition is wrong: HTML attribute parsing decodes character references before the JavaScript fragment is parsed, so "&#39;" becomes a literal "'" in the JavaScript context. An attacker who can store a value such as "1',alert(1),'2" in "Variante.referencia" (no special characters required, just one apostrophe) ends up with "widgetVarianteSelect('id', '1',alert(1),'2');" executing in any user's browser the moment they open the variant-picker modal. The recent "40bc701" and "8586b97" fixes corrected the same anti-pattern in three sister classes by switching to "data-reference="..."" + "this.dataset.reference". The two widget classes audited here were missed by that fix wave.