Brecha en Fakturownia y recompensas por fallos en facturación

Un programa de recompensas por fallos en software de facturación paga a investigadores por vulnerabilidades verificadas que pueden exponer datos de clientes, comprometer integraciones o alterar registros financieros. Antes necesita una política de divulgación de vulnerabilidades: un alcance de pruebas seguro, un canal de avisos y personas que evalúen y corrijan los hallazgos. El aviso de Fakturownia del 29 de septiembre muestra por qué importa ese proceso en una plataforma que guarda cuentas y documentos de otras empresas. No hay pruebas públicas de que un programa de recompensas hubiera evitado esta intrusión.

¿Qué ha confirmado Fakturownia?

Fakturownia afirma que detectó un acceso no autorizado a sus servidores el 28 de septiembre de 2026. Su aviso público, fechado al día siguiente, señala que una persona no autorizada aprovechó un fallo de su sistema y pudo consultar datos de las cuentas de usuario y de sus contrapartes comerciales, así como documentos generados en la plataforma. El aviso indica cuándo se detectó el acceso, no cuándo comenzó. Tampoco explica el fallo ni determina cuántos datos salieron del sistema.

Según la empresa, el posible acceso abarcaba datos de las cuentas de todos sus usuarios, de sus contrapartes comerciales y de facturas emitidas antes de 2023. La lista incluye resúmenes criptográficos de contraseñas, tokens de sesión, tokens de API y de integración emitidos por Fakturownia, números de cuentas bancarias, datos de pagos, parte de los datos de las facturas, claves de la aplicación y contraseñas del sistema. Los resúmenes criptográficos no son las contraseñas en texto claro de los usuarios, pero la posible exposición de tokens y secretos de la aplicación exige medidas específicas. Fakturownia dice que ha bloqueado el acceso no autorizado, ha empezado a renovar claves y contraseñas, ha puesto en marcha nuevos servidores y ha informado del incidente a CBZC, CERT Polska y la autoridad polaca de protección de datos. La investigación sigue abierta.

Fakturownia también afirma que, según sus hallazgos actuales, no hay indicios de que se hayan comprometido los certificados de KSeF, los datos almacenados en sus integraciones, los datos de tarjetas de pago ni las facturas emitidas después de 2023. El aviso no aclara qué ocurre con las facturas emitidas durante 2023. La posible exposición de tokens de integración emitidos por Fakturownia se refiere a una clase de datos distinta de los datos guardados en integraciones externas. No conviene confundir ambas afirmaciones.

Zaufana Trzecia Strona recoge la afirmación de una persona que se atribuye el ataque y dice haber sustraído 6 TB de facturas. Es una afirmación del presunto atacante, no un volumen confirmado por Fakturownia. La publicación también describe un posible método de ataque, pero el aviso de la empresa solo confirma que se aprovechó un fallo del sistema. La secuencia técnica detallada, la identidad del atacante y el volumen sustraído siguen sin verificarse en las fuentes públicas.

¿Por qué un fallo en la plataforma de facturación afecta a más de un cliente?

Un proveedor de facturación concentra datos de varias partes. La cuenta de un cliente puede incluir accesos del personal, nombres y datos de contacto de contrapartes comerciales, cuentas bancarias, conceptos de facturas y credenciales que conectan sistemas contables, de comercio y de pagos. Por eso, un fallo en la plataforma del proveedor puede obligar a actuar a muchas empresas clientes, a sus equipos financieros y a personas que nunca abrieron una cuenta en ella.

Un aviso sobre acceso entre cuentas merece un tratamiento distinto al de un fallo meramente visual. Si una cuenta de prueba creada por el investigador puede leer una factura de otra cuenta de prueba independiente, el proveedor necesita a alguien que reproduzca el hallazgo, compruebe si el límite entre cuentas falla en otros lugares, lo corrija y mantenga informado al investigador. Este debe poder demostrar el problema con cuentas y documentos bajo su control, sin abrir la factura de un cliente real. El Top 10 de seguridad de las API de OWASP distingue los fallos de autorización sobre objetos de los fallos de autenticación; ambos deben figurar en el plan de pruebas de una plataforma de facturación.

Lo mismo vale para los tokens de acceso y los campos que pueden mover dinero. Un aviso podría mostrar que un token sigue funcionando tras su revocación, que un usuario puede actuar fuera de la cuenta asignada o que un cambio de cuenta bancaria elude una protección. Son ejemplos del alcance que podría tener un programa de recompensas, no hallazgos sobre el ataque a Fakturownia. Las pruebas externas pueden descubrir defectos en las partes accesibles del producto, pero no sustituyen el diseño seguro, la revisión de código, los permisos mínimos, la vigilancia ni la respuesta a incidentes.

¿Qué muestran realmente los antiguos comentarios sobre recompensas?

El rastro público plantea una pregunta razonable: cómo llegan los avisos de seguridad a quienes se encargan del producto. El índice del foro de sugerencias de Fakturownia muestra una pregunta de 2016 sobre si la empresa pensaba ofrecer recompensas por fallos. No hemos podido verificar la respuesta en el hilo enlazado. La página pública de seguridad explica cómo avisar de facturas sospechosas, phishing y problemas con la página de inicio de sesión, pero la versión que revisamos no define un alcance para probar vulnerabilidades, condiciones de puerto seguro (Safe Harbor), plazos de respuesta ni reglas de recompensa. Eso no permite determinar si Fakturownia tiene un proceso privado para recibir avisos de seguridad.

En comentarios de LinkedIn que nos compartieron tras el incidente, dos profesionales afirman que comunicaron problemas a Fakturownia en años anteriores. Uno dice que algunos fallos de los que conservaba pruebas de concepto afectaban a los ingresos del proveedor, no a la seguridad de los datos de clientes. No hemos visto los avisos, las respuestas de la empresa ni ningún vínculo entre esas afirmaciones y esta brecha. Los comentarios plantean cómo diseñar un programa, pero no demuestran que se ignorara una vulnerabilidad comunicada y que después se explotara.

¿Qué debería ocurrir si alguien comunica un caso de abuso práctico que no encaja en una lista estrecha de vulnerabilidades técnicas? Una laguna en las reglas de facturación o descuentos no es automáticamente un fallo de seguridad. Aun así, necesita llegar a una persona que evalúe su impacto, decida si entra en el programa de recompensas y conteste a quien lo comunicó. Un proveedor que descarta ese aviso sin respuesta pierde una señal útil, aunque su programa de recompensas de seguridad no pague por esa clase de problema.

¿A quién debería llegar un aviso sobre un fallo en el software de facturación?

Un programa útil especifica quién debe tomar la siguiente decisión, no solo una dirección de correo. La guía del NIST sobre divulgación recomienda un proceso formal para recibir, evaluar, gestionar y comunicar los avisos. El equipo de seguridad puede encargarse de recibirlos, pero debe poder remitir cada hallazgo al responsable de ingeniería, finanzas o producto que pueda actuar.

En todos los casos, el investigador necesita un acuse de recibo, información sobre el estado y una decisión razonada. Un aviso válido no debería desaparecer porque un equipo lo considere un problema de producto y otro, de seguridad. El proveedor puede fijar reglas de recompensa distintas para cada clase de hallazgo, pero debe publicar los límites y responsabilizarse del traspaso entre equipos.

¿Qué debería publicar el proveedor antes de ofrecer recompensas?

Publica una política de divulgación de vulnerabilidades (VDP) con un contacto fácil de encontrar, el alcance de las aplicaciones y API propias del proveedor, condiciones de puerto seguro (Safe Harbor) para las pruebas de buena fe, plazos de respuesta y una vía para los casos dudosos. Un archivo security.txt puede dirigir a los investigadores al contacto y a la política; por sí solo no autoriza a hacer pruebas. La guía para configurar un VDP explica el proceso más amplio.

Para el software de facturación, facilita dos cuentas de prueba independientes y bajo control del investigador, además de documentos ficticios. Una sola cuenta puede contener varias empresas, por lo que crear dos fichas de empresa dentro de ella quizá no pruebe el límite entre cuentas. Exige a los investigadores que se detengan si encuentran facturas, datos bancarios o credenciales reales y que envíen solo las pruebas mínimas, con los datos sensibles ocultos o eliminados. Prohíbe las exportaciones masivas, los cambios en pagos, las pruebas destructivas, la ingeniería social y las pruebas de carga. Incluye únicamente sistemas que el proveedor posea o tenga autorización para someter a pruebas. La política actual de Visma muestra cómo combinar un canal amplio de avisos y reglas de puerto seguro con un programa de pago limitado a los activos enumerados.

Después, financia un programa de recompensas económicas con un alcance definido cuando el equipo pueda validar más avisos, corregir los fallos aceptados y cumplir sus decisiones de pago. La guía de OWASP sobre divulgación advierte de que las recompensas aumentan tanto el número de avisos como el trabajo necesario para gestionarlos. Paga por el impacto demostrado, no por la etiqueta del informe; publica rangos y reglas para avisos duplicados, de modo que quien investiga sepa qué esperar. La guía de niveles de recompensa explica cómo hacerlo.

Ninguna fuente pública muestra que un investigador externo encontrara antes el fallo explotado en Fakturownia, que pudiera probarlo de forma segura o que intentara comunicarlo. No podemos atribuir a un programa de pago la prevención de este incidente. Sí puede dar a futuros hallazgos más posibilidades de llegar a un equipo responsable antes de que los aproveche un delincuente.

¿Qué deberían hacer y preguntar ahora los clientes de Fakturownia?

En su aviso del 29 de septiembre, Fakturownia recomienda cambiar la contraseña de la cuenta y cualquier otra donde se haya reutilizado, proteger la cuenta de correo vinculada, activar la autenticación de dos factores y comprobar el número de cuenta bancaria y la lista de usuarios en la configuración. También advierte sobre mensajes y llamadas que se hacen pasar por bancos, autoridades, la propia empresa o contrapartes comerciales. Estas son las recomendaciones públicas actuales de Fakturownia mientras determina a quién debe notificar. Pregúntale directamente por el estado de los tokens de sesión, API o integración que utilices; el aviso público los enumera como potencialmente accesibles, pero no ofrece un procedimiento completo para que los clientes los renueven.

Después, pide el proceso de divulgación del proveedor. ¿Puede un investigador sin relación con la empresa encontrar un contacto de seguridad sin iniciar sesión? ¿Autoriza la política a probar los sistemas propios del proveedor sin poner en riesgo los datos de clientes? ¿Llegaría a alguien capaz de corregirlo y de responder al investigador un aviso sobre una factura de otra cuenta, un token, datos bancarios o una regla de facturación? Estas preguntas valen para sistemas contables, plataformas de cobro y nuestra propia categoría de software relacionado con KSeF. El artículo sobre puerto seguro explica por qué importa la autorización para investigar; la guía sobre el alcance aclara la diferencia entre los activos propios del proveedor y los sistemas de sus clientes.

¿Cómo puede Kit gestionar el recorrido del aviso a la decisión?

Kit ayuda al proveedor a publicar un programa de divulgación con un alcance definido y un contacto localizable mediante security.txt. Los investigadores pueden enviar informes a través del portal; el equipo puede asignar un responsable, seguir los plazos de respuesta, comentar los hallazgos y registrar una decisión de recompensa opcional. Kit hace el seguimiento del traspaso para el pago, mientras que el proveedor mueve el dinero a través de su propio servicio de pagos.

La primera prueba útil es sencilla: envía un informe ficticio sobre acceso entre cuentas y síguelo desde la recepción hasta una decisión de ingeniería y una respuesta. Así comprobarás si se escucharía a un investigador real. Kit organiza ese recorrido; el proveedor sigue siendo responsable de investigar, corregir el fallo y proteger a sus clientes.