Base de CVEs

ImageMagick before 7.1.2-26 and 6.9.13-51 contains a memory leak in color transformation to the log colorspace: when the operation fails, a small amount of memory is not released.

ImageMagick before 7.1.2-26 and 6.9.13-51 contains an information disclosure vulnerability: when a profile is displayed with the identify command and the profile value is not printable, a single byte at the end of the profile can be printed (read past the profile boundary). This behavior occurs when debug output is enabled.

ImageMagick before 7.1.2-26 and 6.9.13-51 contains a use-after-free vulnerability that occurs when freetype initialization fails: the method does not exit and continues to use memory that was already freed. This can be triggered during image processing and may lead to a denial of service.

ImageMagick before 7.1.2-26 and 6.9.13-51 contains a heap-based buffer over-write vulnerability that occurs when running an X11 import with a crafted window title, which can result in heap memory corruption and denial of service.

ImageMagick before 7.1.2-26 and 6.9.13-x before 6.9.13-51 contains a policy bypass vulnerability in the -script operation due to missing security policy checks. This allows reading files from paths that are otherwise disallowed by the configured security policy.

Hono before 4.11.10 contains a timing attack vulnerability in the basicAuth and bearerAuth middlewares due to non-constant-time string comparison in the timingSafeEqual function. Attackers can exploit early termination of string equality checks to infer valid credentials through precise timing measurements.

ImageMagick through 7.1.2-18 contains a memory leak vulnerability in the ASHLAR coder when an action fails. Attackers can trigger failed actions to exhaust memory resources and cause denial of service.

HCL BigFix Platform is affected by a user enumeration vulnerability which might allow an attacker, through careful system control and response time monitoring, to perform some level of user enumeration for the BigFix service.

ColdFusion is affected by an Insufficient Session Expiration vulnerability that could result in a Security feature bypass. A high-privileged attacker could leverage this vulnerability to bypass security measures and gain unauthorized write access. Exploitation of this issue does not require user interaction.

Adobe Commerce is affected by an Information Exposure vulnerability that could lead to a limited disclosure of sensitive information. Exploit depends on conditions beyond the attacker's control. Exploitation of this issue does not require user interaction.

Insertion of sensitive information into a file in the Recovery Kit response file generation feature in Devolutions Server 2026.1.22.0, 2026.2.11.0 allows an attacker with access to the generated response file to obtain the Azure Key Vault client secret in cleartext, even when the option to exclude sensitive data is selected.

Improper authorization in the secure messages deletion endpoint in Devolutions Server 2026.2.11, 2026.1.22 allows an authenticated user to delete another user's messages via a direct object reference to the message identifier.

Out-of-bounds read in Windows Print Spooler Components allows an authorized attacker to disclose information locally.

Out-of-bounds read in Microsoft Office allows an unauthorized attacker to disclose information locally.

Out-of-bounds read in Microsoft Office allows an unauthorized attacker to disclose information locally.

Out-of-bounds read in Microsoft Office allows an unauthorized attacker to disclose information locally.

Exposure of sensitive information to an unauthorized actor in Windows Kernel allows an authorized attacker to disclose information locally.

Exposure of sensitive information to an unauthorized actor in Windows Win32K allows an authorized attacker to disclose information locally.

## Summary `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. ## Details ### the offending code `Core/Lib/Widget/WidgetVariante.php:298-330`: ```php protected function renderVariantList(): string { $items = []; foreach ($this->variantes() as $item) { $match = $item->{$this->match}; $description = Tools::textBreak($item->description(), 300); ... $items[] = '<tr class="clickableRow" onclick="widgetVarianteSelect(\'' . $this->id . '\', \'' . $match . '\');">' . '<td class="text-center">' ... ``` `$this->match` defaults to `'referencia'` (`WidgetVariante::__construct`, line 42). `$item->referencia` was sanitised at write time by `Variante::test()` (`Core/Model/Variante.php:392`) which calls `Tools::noHtml($this->referencia)`. `Tools::noHtml` (`Core/Tools.php:499-504`) replaces `'`, `"`, `<`, `>` with `&#39;`, `&quot;`, `&lt;`, `&gt;`. The defender therefore expects that any apostrophe a user typed becomes `&#39;` in the database, which renders inside the `onclick` attribute as `&#39;` and cannot break out of the surrounding `'...'` JS string literal. `Core/Lib/Widget/WidgetSubcuenta.php:290-305` has the identical shape: ```php foreach ($this->subcuentas() as $item) { $match = $item->{$this->match}; ... $items[] = '<tr class="clickableRow" onclick="widgetSubaccountSelect(\'' . $this->id . '\', \'' . $match . '\');">' . '<td class="text-center">' . '<a href="' . $item->url() . '" target="_blank" onclick="event.stopPropagation();">' ... ``` `$this->match` defaults to `'codsubcuenta'`; the value is `Tools::noHtml`-encoded by `Subcuenta::test()` (`Core/Model/Subcuenta.php:213`). ### why HTML-entity escaping does not protect a JavaScript string Per the HTML5 spec (and what every browser actually does), the value of an HTML attribute is processed by the **character reference state** of the tokenizer before any consumer sees it. By the time the `onclick` attribute value reaches the script engine, the bytes inside are the *decoded* string. Concretely, the HTML the browser receives is: ```html <tr onclick="widgetVarianteSelect('id', '1&#39;,alert(1),&#39;2');"> ``` After the tokenizer decodes `&#39;` to `'`, the JavaScript fragment passed to the script engine is: ```javascript widgetVarianteSelect('id', '1',alert(1),'2'); ``` `alert(1)` runs as a third positional argument that JavaScript happily evaluates while building the call. The `widgetVarianteSelect` function ends up being called with four arguments and the side-effect of `alert(1)` (or any payload) has already occurred. The recent `40bc701` AccountingModalHTML and `8586b97` SalesModalHTML / PurchasesModalHTML fix recognised this. Both replaced the `onclick="...('"+ value +"')"` pattern with: ```php $tbody .= '<tr ... data-subaccount="' . $code . '" onclick="$(...).modal(\'hide\');' . ' return newLineAction(this.dataset.subaccount);">' ``` Where `$code = static::html($subaccount->codsubcuenta)` and `static::html` is `htmlspecialchars(html_entity_decode($text, ENT_QUOTES | ENT_HTML5, 'UTF-8'), ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8')`. The HTML5 entity decode is deliberate: it normalises any double-encoded data so that the subsequent `htmlspecialchars` produces stable single-encoded output. The JavaScript then reads the value from `this.dataset.*`, which is the post-decoded attribute value, where the original quote is now literally inside a string property and cannot break out of any quote context. `WidgetSubcuenta` and `WidgetVariante` were not migrated to this pattern. ### ways to plant the payload `Variante::test()` (`Core/Model/Variante.php:389-401`) accepts up to 30 characters in `referencia`. The minimum payload is 13 bytes (`1',alert(1),'2`), comfortably under the limit. The `Tools::noHtml` pass during `test()` produces the stored form `1&#39;,alert(1),&#39;2`, which is 22 bytes. Three plant primitives are practical: 1. **Direct create** via `EditProducto?action=save` with the attacker-controlled `referencia` field. Because `EditProducto` is exposed to any user with the `EditProducto` permission (which roles like *sales agent* and *warehouse manager* commonly carry), this is a within-tenant primitive: a low-privilege salesperson plants the payload, an admin opens any sales document and clicks the variant picker. 2. **DB write** by anyone with raw SQL access (DBA or shared-hosting admin). `INSERT INTO variantes (referencia, ...) VALUES ('1\',alert(1),\'2', ...)`. This is what I used for the live test; the plant is permanent until the row is deleted. 3. **Plugin / API import.** `ApiAttachedFiles` and the various import endpoints allow a low-privilege API key to land arbitrary `referencia` values that bypass the `EditProducto` `permissions->onlyOwnerData` filter. For `WidgetSubcuenta`, the `codsubcuenta` field is constrained to the exercise's `longsubcuenta` length (10 by default), and the regex-free `Tools::noHtml` pass turns one apostrophe into 5 bytes (`&#39;`), so the post-noHtml string must equal the configured length exactly. A 5-byte payload (`1','` is 4) plus padding is workable for compact bypass payloads such as `'+x+'` (where `x` is a previously-loaded global). DB-write planting (primitive 2) bypasses the length check entirely. ### why the recent fix wave missed this The fix wave centred on the `Lib/AjaxForms/*ModalHTML.php` files. Both audited widgets live in `Lib/Widget/` and look superficially safe to a reviewer because every value is `Tools::noHtml`-escaped at storage. The actual decoding step happens inside the browser, not the PHP code, so the defect is not visible in a `grep`-based review of the PHP source unless the reviewer specifically looks for `onclick="...('+ $field +')'` shapes that put a `Tools::noHtml`-escaped value in a JavaScript string position inside an HTML attribute. ## PoC > **Live PoC verified 2026-05-01** against `http://127.0.0.1:8081/` running facturascripts at commit `24281ca`. A `Variante.referencia` value of `1',alert(1),'2` (planted via raw DB write below) renders inside `widgetVarianteSelect('0', '1&#39;,alert(1),&#39;2');` in the modal grid; opening the variant-picker modal in any user's browser (low-priv or admin) fires `alert(1)` from the host page's realm. Setup: the admin session at `http://127.0.0.1:8081/` is at `/tmp/fs-cookie2`. Step 1 - plant the payload (any of the three primitives works). DB-write primitive: ```bash mysql -h127.0.0.1 -ufs -pfs facturascripts <<'SQL' INSERT INTO productos (referencia, descripcion, codimpuesto, sevende, secompra, bloqueado, nostock, publico, stockfis, ventasinstock, observaciones) VALUES ('XSSPRD', 'XSS via WidgetVariante', 'IVA21', 1, 1, 0, 1, 0, 0, 1, ''); INSERT INTO variantes (referencia, idproducto, precio, coste, margen, stockfis, codbarras) SELECT "1',alert('XSS-WidgetVariante'),'2", idproducto, 0, 0, 0, 0, '' FROM productos WHERE referencia='XSSPRD'; SQL ``` After the insert, `Variante::test()` did not run (the row was created via SQL), so the literal `'` survives. Even via the EditProducto UI primitive, the round trip through `Tools::noHtml` produces the encoded form `1&#39;,alert(...),&#39;2` which decodes back to the working payload at render time. Step 2 - open any controller that uses WidgetVariante with the default `match` (or any third-party plugin form that does so). Core ships two views (`Core/XMLView/EditAgente.xml`, `Core/XMLView/ListAgente.xml`) but both override `match="idproducto"`, so they are not exposed in stock core. Any plugin form that uses `<widget type="variante" .../>` without an explicit `match` attribute opts into the vulnerable code path. Trigger the variant-picker modal: ```bash $ curl -s -b /tmp/fs-cookie2 "http://127.0.0.1:8081/EditAgente?code=1" \ | grep -oE 'widgetVarianteSelect[^<>]{1,200}' | head -3 ``` When the modal renders `match=referencia`, the row in the response contains: ```html <tr class="clickableRow" onclick="widgetVarianteSelect('0', '1&#39;,alert(&#39;XSS-WidgetVariante&#39;),&#39;2');"> ``` The browser HTML-decodes the attribute value before passing it to the script engine, yielding the actual JavaScript `widgetVarianteSelect('0', '1',alert('XSS-WidgetVariante'),'2');`. The `alert` fires the moment the attribute is parsed for execution (i.e., when the user clicks the row, or when an automation script triggers the click programmatically), and the host realm's session, cookies, and CSRF tokens are exposed to the payload. For `WidgetSubcuenta`, the payload trigger is identical: any controller with `<widget type="subcuenta" fieldname="codsubcuentaXxx"/>` (`Core/XMLView/EditProducto.xml`, `EditCuentaBanco.xml`, `EditFamilia.xml`, `EditImpuesto.xml`, `EditRetencion.xml` are the in-tree consumers) renders the modal with `widgetSubaccountSelect('id', '<HTML-decoded codsubcuenta>')`. A `codsubcuenta` row planted with one apostrophe and five bytes of payload escapes the JS string and runs in the host page. ## Impact * **Stored XSS in any user's browser the moment they open a product or subaccount picker.** The execution context is the host page, with full access to the viewer's session, CSRF tokens, and the running application. From an admin viewer's perspective the payload achieves admin compromise (install plugins, change passwords); from a normal user's perspective it can be used to exfiltrate the user's data and pivot. * **Within-tenant escalation primitive.** `EditProducto` is a routinely granted role permission. A salesperson, warehouse user, or a plugin-supplied controller without `admin` rights can plant a payload that fires in admin's browser the next time admin opens any sales document and clicks the variant picker. * **Sister vulnerability to the `40bc701` / `8586b97` fix wave.** The maintainers already understand and have fixed the same anti-pattern in three sister classes; these two were missed and remain exploitable. CVSS reasoning: `AV:N`, `AC:L` (one DB or one form POST plant), `PR:H` (the planter must be authenticated and have either `EditProducto` or DB write or import-API access; with weaker roles the payload is also reachable), `UI:R` (the victim opens a form that renders the modal and triggers a click), `S:U` (the impact stays within the application), `C:L I:L A:N` (the viewer's session and CSRF token are exposed; integrity loss bounded by viewer's role). Score 4.8. ## Recommended Fix Mirror the `40bc701` and `8586b97` fix exactly. In both `Core/Lib/Widget/WidgetVariante.php:321` and `Core/Lib/Widget/WidgetSubcuenta.php:296`, replace: ```php $items[] = '<tr class="clickableRow" onclick="widgetVarianteSelect(\'' . $this->id . '\', \'' . $match . '\');">' ``` with the data-attribute pattern that the modal helpers now use: ```php $encMatch = htmlspecialchars( html_entity_decode((string)$match, ENT_QUOTES | ENT_HTML5, 'UTF-8'), ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8' ); $items[] = '<tr class="clickableRow" data-match="' . $encMatch . '"' . ' onclick="widgetVarianteSelect(\'' . $this->id . '\', this.dataset.match);">' ``` (and the analogous change for `widgetSubaccountSelect`). The same approach should be applied to: * `WidgetSubcuenta::renderExerciseFilter` (`Core/Lib/Widget/WidgetSubcuenta.php:251-255`) where `$item->codejercicio` is interpolated into `<option value="...">`. Codes are short and predictable but the same escaping consideration applies for defence in depth. * `WidgetVariante::renderManufacturerFilter` (line 213) and `renderFamilyFilter` (line 197). Long term, the `BaseWidget::onclickHtml` and `inputHtml` builders (`Core/Lib/Widget/BaseWidget.php:163-167`, `234-239`, `273-283`) likewise concatenate `$this->value` into HTML attributes without context-aware escaping. Migrating them to use Twig (or at least `htmlspecialchars` with `ENT_QUOTES`) closes a class of bugs that today rely on every model's `test()` to be defensive. A regression test should plant a `Variante.referencia` of `1',alert(1),'2`, render the page through the live HTTP stack, and assert that no JavaScript dialog fires (e.g. via Playwright `page.on('dialog', ...)`).

Out-of-bounds read in Microsoft Office allows an unauthorized attacker to disclose information locally.

Heap-based buffer overflow in Microsoft Office Excel allows an unauthorized attacker to disclose information locally.

Easy!Appointments is a self hosted appointment scheduler. In versions prior to 1.6.0, `Google::oauth` at `application/controllers/Google.php:278` stores its URL-supplied `provider_id` in the session, and `oauth_callback` saves the issued Google OAuth token against that row without checking the caller owns the provider. Any logged-in backend user (admin, provider, or secretary) rebinds a peer provider's Google sync to a Google account they control. The peer's appointments then sync into the attacker's calendar with each customer's name and email attached as attendee data. Version 1.6.0 patches the issue.

Easy!Appointments is a self hosted appointment scheduler. In versions prior to 1.6.0, `Caldav::connect_to_server` at `application/controllers/Caldav.php:60` hands the request's `caldav_url` to a Guzzle `REPORT` call without scheme or host validation. A logged-in backend user (admin, provider, or secretary) reaches loopback, RFC1918, and link-local hosts on the deployment's network. The Guzzle exception path returns the upstream status code plus ~120 bytes of response body in the JSON `message` field (`Caldav.php:74-78`), so the SSRF is semi-blind. Version 1.6.0 contains a patch.

Easy!Appointments is a self hosted appointment scheduler. Versions prior to 1.6.0 correctly filter provider-scoped appointments in the `appointments/search` response, proving that provider isolation is an intended security boundary. However, the direct mutation endpoints `appointments/store` and `appointments/update` only check generic appointment privileges and never verify that the submitted `id_users_provider` belongs to the current session. A normal authenticated provider can inject new appointments into another provider's schedule via `store`, or reassign existing appointments into a foreign provider's calendar via `update`. The `store` path contains an additional write-before-crash bug: the unauthorized row is committed to the database before the controller crashes on a type error, so the attacker receives an error response while the foreign appointment is already persisted. Version 1.6.0 patches the issue.

Easy!Appointments is a self hosted appointment scheduler. Versions prior to 1.6.0 allow administrators to define a custom "booking disabled" message through the booking settings page. That value is stored in the `disable_booking_message` setting via a rich-text editor and later passed directly to the public `booking_message` view without escaping or sanitization. An authenticated administrator can store HTML or JavaScript in this field, enable disabled-booking mode, and trigger stored XSS in every unauthenticated visitor who opens the public booking page. Version 1.6.0 fixes the issue.