PHP2Shell y tu tienda: obligaciones si hay una brecha

La noticia de esta semana es de informáticos. Las consecuencias que te tocan a ti son de gestión: qué obligaciones te genera, qué debes revisar en tus cobros, dónde guardas tus facturas y cómo registras el gasto de arreglarlo.

Una aclaración antes de seguir: no hay certeza de que tu tienda haya sido atacada. CISA no había observado explotación al publicar su aviso, aunque Cloudflare sí vio tráfico de ataque contra clientes. Lo que sigue sirve igual: es lo que conviene tener claro por si el día de mañana te toca a ti.

El parche es del servidor; la responsabilidad es tuya

Los fallos están en el motor de PHP, no en tu tema ni en tus plugins. Por eso actualizar WordPress o PrestaShop no los arregla: hay que actualizar PHP en el servidor, o pedírselo a tu hosting.

Y aquí viene lo que suele olvidarse. Tu hosting es, en el lenguaje del RGPD, un encargado del tratamiento. Si ocurre un incidente, debe avisarte sin dilación indebida. Pero el responsable del tratamiento, el que decide para qué se usan los datos de tus clientes, eres tú. Delegar el parche no delega la obligación.

Si hay brecha, el reloj son 72 horas

Según la AEPD, el plazo para notificar a la autoridad de control es de 72 horas desde que tienes constancia de la brecha. Si no llegas, la notificación debe ir con los motivos del retraso.

Tres matices que importan:

Primero, no toda incidencia se notifica. El artículo 33 del RGPD exime los casos en los que es improbable que la brecha suponga un riesgo para los derechos y libertades de las personas. Valorarlo es parte de tu obligación, y por escrito: el responsable debe documentar cualquier violación de seguridad, la notifique o no.

Segundo, si el riesgo es alto, además de la AEPD hay que informar a los afectados (artículo 34).

Tercero, tener PHP sin parchear unos días no equivale a haber sufrido una brecha. Equivale a haber estado expuesto. La diferencia es la que decide si notificas. Cuando haya dudas, la AEPD ofrece una herramienta de ayuda para decidirlo.

Dinero: qué revisar en cobros, devoluciones y pasarelas

Uno de los fallos puede devolver memoria de otras peticiones, y según Sansec ahí pueden viajar contraseñas, tokens y claves API. Si tu servidor estuvo expuesto, el primer paso es cambiar las claves de tu pasarela de pago y de las integraciones con tu ERP o tu banco.

El segundo paso es de contabilidad. Compara, desde el 20 de octubre, los pedidos de la tienda con las liquidaciones de la pasarela y con los movimientos del banco. Busca tres señales: devoluciones sin pedido, cambios en cuentas de cobro y pagos que no casan con ningún pedido. Si vendes también por marketplaces, las liquidaciones vienen del propio marketplace, no de tu servidor: la revisión es sobre la tienda propia.

Facturas y pedidos: no dependas de un solo servidor

El Código de Comercio (artículo 30) obliga a conservar libros, correspondencia, documentos y justificantes durante seis años desde el último asiento. Si tus pedidos y facturas solo existen dentro de la base de datos de tu tienda, un incidente puede dejarte sin ellos. Programa una exportación periódica de pedidos y facturas a un sitio que no sea el propio servidor.

Cómo se registra el gasto de arreglarlo

Como regla general, y a confirmar con tu asesor porque depende del caso, funciona así:

Actualizar PHP o resolver un problema de seguridad es un gasto de reparación y conservación. Se contabiliza como gasto del ejercicio.

Migrar la tienda o la web a otra plataforma es otra cosa. Si el proyecto tiene alcance suficiente y utilidad de varios años, puede tratarse como inversión (un activo intangible que se amortiza). Cuándo se amortiza y cuándo no lo explicamos en a partir de qué importe hay que amortizar un activo.

En ambos casos, para deducir el gasto y el IVA soportado necesitas factura completa, a nombre de tu actividad o de tu sociedad, y que el gasto esté vinculado a ella.

¿Soy responsable si mi hosting no parchea?

Frente a tus clientes y a la AEPD, sí: eres el responsable del tratamiento. Tu hosting es el encargado y debe avisarte de un incidente sin dilación indebida, pero eso no te quita la obligación. Pídele por escrito que confirme la versión de PHP y que el parche está aplicado.

¿Tengo que avisar a mis clientes si no ha pasado nada?

No. Avisar a los afectados es obligatorio cuando hay una brecha con riesgo alto para ellos, no por haber tenido un fallo sin parchear. Lo que sí conviene es dejar por escrito qué comprobaste y por qué concluiste que no había brecha.

¿Puedo deducirme el parche o la migración?

Como regla general sí, si es un gasto vinculado a tu actividad, justificado con factura completa y contabilizado. El tratamiento cambia: el parche es gasto del ejercicio; una migración de mayor alcance puede ser inversión. Confírmalo con tu asesor antes de cerrar el ejercicio.

¿Qué pasa si solo vendo en Amazon y no tengo web propia?

Tu exposición a este fallo es mucho menor, porque no tienes servidor propio con PHP. Revisa si tienes un blog, una web corporativa o una landing aparte: son las que suelen olvidarse.

¿Quién hace el parche o la migración técnica?

Tu hosting o tu equipo de desarrollo. Si no tienes ninguno, Epinium hace actualizaciones de PHP y migraciones de tienda y de web, y te dice antes de empezar si de verdad hace falta migrar.

Lo que conviene dejar atado esta semana

Hay tres papeles que valen más que cualquier herramienta: la confirmación escrita de tu hosting, la nota de qué revisaste y qué concluiste, y una exportación de pedidos y facturas fuera de tu servidor. Si algún día te preguntan qué hiciste el 21 de octubre, esos tres documentos son tu respuesta. Y sale casi gratis hacerlos.