Weblate: IDOR sin autenticación permitía modificar los datos de facturación asociados a un pago

Resumen

El fallo estaba en la función de edición de los datos de facturación de un pago en Weblate, accesible en la ruta /<idioma>/payment/<uuid>/edit/. El servidor decidía qué pago mostrar y modificar únicamente a partir del identificador que aparece en la URL, sin comprobar dos cosas básicas: si quien hacía la petición había iniciado sesión y si tenía permiso sobre el cliente vinculado a ese pago.

El resultado es una referencia directa insegura a objetos (IDOR) en su versión más grave, porque ni siquiera hacía falta una cuenta: cualquier visitante anónimo que conociera el UUID de un pago podía abrir el formulario y sobrescribir la información de facturación del cliente. El investigador atribuye la causa a la ausencia de controles de autorización antes de permitir cambios en el objeto de cliente asociado al pago.

HackerOne lo clasificó como severidad alta. El reporte se envió el 16 de julio de 2026, figura como resuelto y se divulgó el 30 de agosto de 2026.

Pasos de reproducción

El investigador lo demostró sobre una instancia local de Weblate:

1. Crear un objeto de pago y apuntar su UUID. En la prueba fue este:

01f82084-20dc-498a-b004-2694d51be433

1. En un navegador sin sesión iniciada, abrir la página de edición de ese pago:

http://127.0.0.1:8000/en/payment/01f82084-20dc-498a-b004-2694d51be433/edit/

1. Comprobar que el formulario de datos de facturación se carga sin pedir autenticación.

1. Cambiar los campos de facturación. En la prueba se usaron estos valores:

Name:
IDOR_EVIDENCE_TEST

Address:
IDOR_ADDRESS_TEST

1. Enviar el formulario.

1. La aplicación acepta la petición y actualiza los datos del cliente.

1. Consultar el registro del cliente para confirmar que los cambios se han guardado de forma persistente:

Name: IDOR_EVIDENCE_TEST
Address: IDOR_ADDRESS_TEST

Impacto

Un atacante sin cuenta podía alterar datos de clientes guardados en la base de datos, en concreto el nombre y la dirección de facturación ligados a un pago, con solo conocer el UUID de ese pago. Los cambios no eran temporales: quedaban almacenados y se mostraban como datos legítimos del cliente.

Según el reporte, esto supone:

• Modificación de los registros de facturación de los clientes.
• Información de cliente incorrecta guardada y mostrada por la aplicación.
• Pérdida de integridad de los datos de cliente relacionados con pagos.
• Posibles problemas en la facturación, la emisión de facturas u otros procesos de pago si el sistema usa esos datos modificados.

El impacto descrito es sobre la integridad de los datos: el reporte no menciona lectura de información ajena ni acceso a los pagos en sí.