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.