CVE-2023-30839

El daño aquí es una autorización que no se sostiene. Un usuario del back-office en PrestaShop —cualquier cuenta con acceso a la consola, independientemente de los permisos granulares que le haya asignado un administrador— puede saltarse el filtrado SQL y escribir, actualizar o eliminar directamente en la base de datos. El modelo de permisos dice que no deberían tocar esas tablas; la capa SQL se lo permite igualmente. En una tienda en producción eso significa que registros de pedidos, datos de clientes y credenciales de administrador están todos al alcance de una cuenta pensada para tener mucho menos poder.

Lo que limita esto es tener una cuenta de back-office siquiera, razón por la que es un 9.9 en lugar de un 10 limpio, pero esa barrera es más delgada de lo que suena. Las cuentas de personal, los accesos de contratistas y los roles de bajo nivel son exactamente las credenciales que se ven afectadas por phishing o reutilización, y una cuenta junior comprometida normalmente se topa con el techo de los permisos que se le concedieron. Este fallo elimina ese techo: un único acceso débil se convierte en control total de la base de datos en una plataforma de comercio electrónico que almacena datos de pago y PII de clientes.

Para nosotros la pregunta útil no es si PrestaShop está parcheado en general, sino qué instancias son anteriores a 8.0.4 o 1.7.8.9 y cuántas cuentas de back-office activas tiene cada una. Una tienda con decenas de accesos de personal inactivos es un objetivo mucho mayor que una tienda de un solo administrador, así que clasificamos por superficie de cuentas, no solo por versión, y tratamos las cuentas de back-office obsoletas como el verdadero radio de impacto.