alkimcoskun/yordam-kutuphane-otomasyonunda-coklu-html-enjeksiyonuCVE-2026-77818 - Yordam Kütüphane Otomasyon Sistemi - Inyección de HTML reflejado en tres puntos distintos, secuestro de la acción del formulario y robo de credenciales (CWE-79)
CVE-2026-77818 · CVSS 3.1 6.1 (Media) · Presidencia de Ciberseguridad · Publicado 2026-09-04 · TR-26-1011
Estado: Las vulnerabilidades se han corregido en la versión v22.2. Las instalaciones afectadas deben actualizarse a v22.2 o superior.
El Sistema de Automatización de Bibliotecas Yordam es un software comercial de automatización de bibliotecas y catálogo en línea (OPAC) ampliamente utilizado en bibliotecas universitarias, públicas e institucionales de Turquía. La instalación es on-premise; cada cliente ejecuta una copia separada en su institución.
En la versión v22.1 del producto, existen inyecciones de HTML reflejadas en tres puntos independientes. Las tres no requieren autenticación y las tres se activan con un solo enlace.
| # | Punto | Causa raíz |
|---|
| 1 | Página de inicio de sesión, parámetro devam | No se aplica ningún escape |
| 2 | Atributo value del campo de formulario oculto | Doble decodificación de URL después del escape |
| 3 | Atributo name del campo de formulario oculto | El escape se aplica solo al valor, no al nombre |
Como las tres se encuentran en la misma versión del mismo producto y en la misma clase de vulnerabilidad, se han agrupado en una sola notificación y se han publicado bajo un único identificador CVE. En términos de impacto, el punto número 1 es el más grave.
devamEste es el más crítico. El punto de inyección está directamente en la propia etiqueta HTML del formulario de autenticación.
El parámetro devam transporta la dirección a la que el usuario volverá después de iniciar sesión y llega codificado en hexadecimal — el valor 2f796f7264616d2f significa /yordam/. La aplicación decodifica este valor de hexadecimal y lo escribe en la etiqueta de apertura del formulario de inicio de sesión. No hay ningún proceso de escape en medio:
<form class='girisForm collapse show ikiAdimliGiris' method='post'
action='inc/islem.fm.inc.php'
data-url='<ENTRADA DE USUARIO DECODIFICADA EN HEX>'
autocomplete="off">
En la salida, los caracteres <, > y las comillas aparecen en bruto. Lo único que contiene el payload es que el atributo data-url está envuelto en comillas simples. Cuando se introduce una comilla simple dentro de la entrada, eso también termina: el atributo se cierra, la etiqueta <form> se cierra y el HTML escrito por el atacante reemplaza al formulario de autenticación de la página.
La acción del formulario es secuestrada. Aquí no se dibuja un formulario falso — el formulario propio de la aplicación se deja vacío y se cierra, e inmediatamente después se abre un nuevo <form> que lleva las mismas clases CSS. Como los campos de nombre de usuario, contraseña y código de verificación de la página son todos HTML original de la aplicación, permanecen dentro de este nuevo formulario. El usuario ve el formulario real, rellena el formulario real; la información introducida va al servidor del atacante. No hay ninguna diferencia visualmente distinguible.
El punto crítico: la inyección no ocurre en una página aleatoria, sino en la página donde ya se espera que el usuario introduzca su contraseña. En una inyección reflejada ordinaria, el atacante debe convencer a la víctima; aquí, la propia interfaz de la aplicación hace el trabajo de convencimiento.
value del Campo de Formulario Oculto — Doble Decodificación de URLEn la página de búsqueda, los valores de los parámetros GET se escriben en campos de formulario ocultos. En este punto se aplica escape — pero en el orden incorrecto.
El mismo valor q se utiliza en tres contextos distintos dentro de una sola respuesta, y cada uno tiene una profundidad de decodificación diferente:
| Contexto | Decodificación | Estado |
|---|---|---|
Cadena JS en bloque <script> | 1 vez | Seguro |
Cuadro de búsqueda principal <input value="…"> | 1 vez | Seguro |
Campos de formulario ocultos <input type='hidden' value="…"> | 2 veces | Vulnerable |
La secuencia de operaciones es la siguiente:
Entrada del cliente : %2522
↓ análisis de $_GET
Variable PHP : %22
↓ filtro de entrada → no ve contenido malicioso, no hay comillas presentes
↓ htmlspecialchars → no hay caracteres que escapar, sin cambios
↓ urldecode → se decodifica %22
Impreso en la página : " ← comilla en bruto, salida del atributo
Mientras que el filtro de entrada y el escape operan en la primera capa de decodificación, la salida se alimenta de la segunda capa. Al comparar las versiones codificadas una y dos veces del mismo payload, la diferencia se ve claramente:
| Enviado | Respuesta | Salida del campo oculto |
|---|---|---|
q=foo%22… (codificación única) | 302 Found | value="foo"…" — el filtro lo captura |
q=foo%2522… (doble codificación) | 200 OK | value="foo"><…>" — HTML en bruto |
La vulnerabilidad no es específica del parámetro q. El bloque que genera los campos ocultos itera sobre todos los parámetros GET de la solicitud; también se ha verificado en tip y alan.
name del Campo de Formulario Oculto — Inyección en el Nombre del ParámetroEl mismo bloque genera la siguiente estructura para cada parámetro GET:
<input type='hidden' name="<NOMBRE DEL PARÁMETRO>" value="<VALOR DEL PARÁMETRO>"/>
El escape se aplica solo al lado de value. Al lado de name no se aplica en absoluto. En este punto tampoco se necesita doble codificación — la codificación única es suficiente, porque no hay ningún escape que sortear.
Un nombre de parámetro inventado se escribe directamente en bruto en el atributo name y se puede salir del atributo. Como el nombre del parámetro está bajo el control del atacante, no es necesario que sea un parámetro conocido por la aplicación.
Los puntos 2 y 3 de estas tres vulnerabilidades se originan en el mismo bloque de código, y este bloque se repite en seis formularios distintos: dilForm, adetForm, siralaForm, tkForm, ekForm, tmForm. Es decir, en una sola solicitud la inyección ocurre seis veces.
La naturaleza dinámica del bloque se ha verificado comparando la salida de dos solicitudes:
Solicitud A: ?p=1&dil=0&alan=&tip=basit&gorunum=liste&q=…
Salida A: name="p" · name="alan" · name="tip" · name="gorunum" · name="q"
Solicitud B: ?p=2&dil=0&devam=…
Salida B: name="p" · name="devam"
Los campos generados no provienen de una lista fija, sino directamente de los parámetros de la solicitud. Por lo tanto, tanto el contenido escrito en el atributo name como en el value está bajo el control del atacante.
Lo único que necesita el atacante es un enlace que la víctima abra. No necesita iniciar sesión ni tener una cuenta.
action del formulario de inicio de sesión se redirige al atacante. Verificado.Dado que la plataforma afectada alberga las credenciales y los datos personales de los miembros de la biblioteca, es posible acceder a los registros de miembros a través de las cuentas comprometidas.
La aplicación utiliza CSP y script-src y object-src están basados en nonce; es decir, el XSS clásico basado en scripts no funciona en estas páginas. A primera vista, esto parece reducir el hallazgo al nivel de "solo alteración de contenido".
La política completa es la siguiente:
Content-Security-Policy: script-src 'nonce-...'; object-src 'nonce-...'; frame-ancestors 'self'
No hay form-action. Tampoco hay default-src — por lo tanto, no hay un valor predeterminado al que recurrir para las directivas no definidas. Resultado: el navegador no bloquea de ninguna manera que el formulario haga POST al servidor del atacante.
Para robar credenciales no es necesario ejecutar JavaScript. El HTML plano es suficiente, y el CSP no detiene el HTML plano.
Primaria
Relacionadas
En el registro CVE, la debilidad primaria se clasifica como CWE-79. A nivel de causa raíz, CWE-116 es más descriptiva: la causa de los tres puntos es que el escape de salida o no se aplica en absoluto o se aplica en el orden incorrecto.
Cabe señalar que en este producto no se ejecutan scripts — la política script-src basada en nonce que envía el propio producto no lo permite, y el valor del nonce no se puede leer de forma cross-origin. El impacto real no es la ejecución de scripts, sino la inyección de HTML y el secuestro del formulario de inicio de sesión. La asignación de CAPEC-148 (Content Spoofing) se ha realizado por esta razón.
CWE-174 se aplica especialmente al punto número 2 — la decodificación por segunda vez de los mismos datos después del escape.
Media — Puntuación base CVSS 3.1 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)
El atacante no necesita ningún privilegio; como la víctima debe abrir el enlace preparado, la interacción del usuario es Requerida. El Scope se ha tomado como Changed porque el contenido inyectado se procesa en el contexto de seguridad del navegador.
Los tres puntos corresponden a la misma puntuación. En términos de impacto, el más grave es el punto número 1: como la inyección ocurre directamente en la propia etiqueta del formulario de autenticación, es posible el secuestro del destino de action del formulario y el robo de credenciales.
Sistema de Automatización de Bibliotecas Yordam
Afectadas : v22.1 y anteriores
Corregidas : v22.2
La verificación se realizó en v22.1. Las vulnerabilidades no se deben a errores de configuración específicos de la institución, sino a componentes comunes de la interfaz del producto; afectan a todas las instalaciones de la misma familia de versiones. El estado de las versiones más antiguas debe ser evaluado por el fabricante.
Como las instalaciones son on-premise, incluso si el fabricante ha publicado la corrección, las instalaciones que no hayan aplicado la actualización seguirán afectadas.
| # | Punto final | Punto de salida |
|---|---|---|
| 1 | GET /yordam/?p=2&dil=<n>&devam=<hex> | Atributo data-url del formulario de inicio de sesión |
| 2 | GET /yordam/?p=1&…&<parámetro>=<payload> | Atributo value del campo de formulario oculto |
| 3 | GET /yordam/?p=1&…&<payload>=1 | Atributo name del campo de formulario oculto |
Los puntos 2 y 3 se originan en el mismo bloque generador de campos ocultos; el bloque se repite en los formularios dilForm, adetForm, siralaForm, tkForm, ekForm y tmForm.
Las vulnerabilidades han sido corregidas por el fabricante. La aplicación debe actualizarse a la versión v22.2 o superior.
| ID CVE | CVE-2026-77818 |
| Asignador (CNA) | TR-CERT (USOM) — Presidencia de Ciberseguridad de la República de Turquía |
| Estado | PUBLISHED |
| Reservado | 2026-08-21 |
| Publicado | 2026-09-04 |
| Aviso de Seguridad | TR-26-1011 |
| Título del Registro CVE | Reflected HTML Injection via Form Hijacking in Yordam Informatics's Library Automation System |
| CAPEC | CAPEC-148 — Content Spoofing |
Fabricante: Yordam Bilgi Teknolojileri Danışmanlık Eğitim ve Elektronik Sistemler Sanayi ve Ticaret A.Ş.
Alkım Coşkun – Netlore Security
| Fecha | Evento |
|---|---|
| 2026-08-20 | Las vulnerabilidades fueron descubiertas y verificadas |
| 2026-08-21 | Notificadas a la Presidencia de Ciberseguridad; se reservó el ID CVE |
| 2026-09-04 | Se publicó CVE-2026-77818, se anunció el aviso de seguridad TR-26-1011 |