Hay vulnerabilidades que llaman inmediatamente la atención porque permiten ejecutar código, acceder a una base de datos o tomar el control de determinadas funciones de una aplicación. CVE-2026-84186 me parece especialmente interesante por otro motivo: pone en duda algo tan básico como saber desde qué dirección IP se está conectando realmente un visitante.
Y eso es bastante más importante de lo que puede parecer.
El problema afecta a la forma en la que PrestaShop obtiene la IP del visitante cuando una tienda funciona detrás de determinados elementos de infraestructura, como un proxy inverso, un balanceador de carga o una CDN.
En esas situaciones entra en juego información como la cabecera HTTP X-Forwarded-For. Si esa información no se procesa correctamente, un visitante puede conseguir que la aplicación interprete una dirección IP diferente de la real.
A primera vista podríamos pensar: “Bueno, solamente es una IP”.
El problema es que una dirección IP no siempre es un dato meramente informativo.
Muchas aplicaciones, módulos y sistemas de seguridad utilizan la IP para decidir si permiten una acción, bloquean una petición, registran un comportamiento como sospechoso o conceden acceso a determinados recursos.
Por eso, si administras una tienda PrestaShop dentro de las ramas afectadas, yo no dejaría esta actualización para más adelante.
Las versiones corregidas que debemos tomar como referencia son:
- PrestaShop 8.2.8
- PrestaShop 9.1.5
Pero actualizar es solamente una parte del trabajo.
Aprovecharía este problema para comprobar también cómo está configurada la infraestructura situada delante de PrestaShop, especialmente si utilizas Cloudflare, otra CDN, un proxy inverso o un balanceador de carga.
Porque CVE-2026-84186 deja una lección bastante clara: la seguridad de una tienda no termina al pulsar el botón de actualizar.
Qué es CVE-2026-84186 y por qué afecta a PrestaShop
CVE-2026-84186 está relacionada con la forma en la que PrestaShop determina la dirección IP desde la que procede una petición.
La ficha de VulDB identifica específicamente Tools::getRemoteAddr como la función afectada y describe el problema como explotable de forma remota.
Para entender por qué esto importa, primero tenemos que pensar en cómo llega normalmente una petición a una tienda.
En una instalación sencilla podríamos imaginar algo parecido a esto:
Visitante → servidor web → PrestaShopEl servidor recibe directamente la conexión del visitante y puede obtener su dirección IP.
Sin embargo, muchas tiendas actuales tienen una arquitectura diferente:
Visitante → CDN / proxy → servidor web → PrestaShopAquí aparece un problema.
Desde el punto de vista del servidor, la conexión puede parecer que procede de la CDN o del proxy y no directamente del ordenador del visitante.
Necesitamos, por tanto, algún mecanismo que permita transportar hasta la aplicación información sobre cuál era la dirección IP original.
El problema está en cómo PrestaShop determina la IP real del visitante
Aquí es donde la cadena de confianza se vuelve especialmente importante.
No basta con recibir una dirección IP. Hay que determinar quién nos está diciendo que esa es la dirección correcta.
En mi caso, es precisamente lo que más me interesa de CVE-2026-84186.
No estamos hablando únicamente de almacenar mal un dato. Estamos hablando de que la aplicación puede terminar confiando en información sobre el origen de una petición que no debería considerar fiable.
Y existe una diferencia enorme entre ambas cosas.
Si una aplicación registra incorrectamente el navegador utilizado por un visitante, probablemente tengamos un problema de calidad de datos.
Si interpreta incorrectamente una dirección IP y después utiliza esa IP para tomar una decisión de seguridad, tenemos un problema completamente distinto.
Qué papel juega X-Forwarded-For
X-Forwarded-For es una cabecera utilizada habitualmente cuando existe un intermediario entre el visitante y el servidor.
Simplificando bastante, permite transportar información sobre la IP original a través de proxies.
El concepto en sí no es problemático.
El problema aparece cuando no está perfectamente definida la cadena de confianza.
Si la infraestructura espera que un proxy añada o sobrescriba esa información, la aplicación debería poder distinguir los datos aportados por infraestructura de confianza de aquellos que un visitante puede introducir por su cuenta.
Y ese es uno de los puntos esenciales para entender CVE-2026-84186.
Por qué falsear una dirección IP es más importante de lo que parece
Cuando explico un problema de este tipo, creo que es fácil infravalorarlo.
“¿Qué puede pasar porque aparezca otra IP?”
La pregunta correcta sería otra:
¿Qué decisiones toma mi tienda utilizando esa IP?
Ahí cambia completamente la valoración del problema.
Una dirección IP puede utilizarse simplemente para estadísticas, pero también puede intervenir en controles de acceso, restricciones, sistemas antifraude, detección de comportamiento anómalo o procesos de auditoría.
Por eso el impacto real dependerá mucho de la tienda, de sus módulos y de la infraestructura que tenga alrededor.
Controles de acceso y restricciones basadas en IP
Imaginemos una funcionalidad a la que solamente permitimos acceder desde determinadas direcciones.
La lógica puede ser perfectamente válida:
- Obtengo la IP.
- Compruebo si está autorizada.
- Permito o deniego el acceso.
El problema aparece si el primer paso devuelve un dato en el que no podemos confiar.
Los pasos dos y tres pueden funcionar exactamente como fueron diseñados y, aun así, producir una decisión incorrecta.
Esta es una de las razones por las que considero interesante esta vulnerabilidad: no necesariamente rompe el control de seguridad; puede romper el dato sobre el que ese control está tomando la decisión.
Modo mantenimiento y listas de IP permitidas
Un ejemplo especialmente sencillo de visualizar es una tienda en modo mantenimiento.
Durante determinados trabajos podemos querer mantener la tienda cerrada al público mientras permitimos que desarrolladores, administradores o responsables del negocio accedan desde direcciones concretas.
Si algún componente de ese control depende de una IP cuya procedencia puede falsearse, tenemos un escenario que merece revisión.
Lo mismo puede ocurrir con módulos o desarrollos personalizados que utilicen listas blancas de direcciones IP.
No significa que cualquier instalación tenga automáticamente todos estos problemas.
Significa que conviene identificar cualquier funcionalidad de nuestra tienda que utilice la IP interpretada por PrestaShop como un dato de confianza.
Geolocalización, detección de abuso y rate limiting
Hay más ejemplos.
Una dirección IP puede participar en procesos relacionados con geolocalización, prevención de fraude, detección de abuso o limitación de solicitudes.
Pensemos en un sistema que decide que una IP está realizando demasiadas peticiones y empieza a restringirla.
Si ese sistema toma directamente como referencia un identificador manipulable, su capacidad para diferenciar visitantes reales puede degradarse.
La vulnerabilidad cobra entonces importancia no por “cambiar un número”, sino porque ese número puede formar parte de otras decisiones.
Esa es la cuestión que yo revisaría en una tienda real.
Cómo puede manipularse la IP cuando PrestaShop está detrás de un proxy o CDN
Para entender el problema no necesitamos entrar en técnicas ofensivas ni reproducir un exploit.
Lo importante es comprender la arquitectura.
Imaginemos esta cadena:
Visitante
↓
Cloudflare / CDN / Proxy
↓
Servidor web
↓
PrestaShopCada componente debe saber qué información procede del anterior y en qué datos puede confiar.
El servidor puede ver como origen directo la dirección del proxy. Para conservar la información del visitante, el proxy comunica la IP original mediante las cabeceras correspondientes.
Hasta ahí, todo normal.
La cuestión aparece si un visitante también puede mandar cabeceras con ese tipo de información y estas llegan hasta PrestaShop sin que la infraestructura las sustituya o normalice adecuadamente.
Visitante, proxy inverso y servidor: dónde se rompe la cadena de confianza
Para mí, la mejor forma de pensar en este problema es como una cadena de confianza.
No basta con preguntar:
¿Qué valor contiene
X-Forwarded-For?
También debemos preguntar:
¿Quién ha escrito ese valor?
No es lo mismo una cabecera establecida por un componente de infraestructura que administramos que una entrada sobre la que el visitante ha podido influir.
Ese matiz parece pequeño, pero cambia completamente la seguridad del diseño.
Una aplicación debería confiar únicamente en información de forwarding procedente de intermediarios que realmente reconoce como fiables.
El problema de confiar en una cabecera enviada por el propio visitante
Este es el escenario que debemos evitar.
Si la aplicación termina tomando como IP real un valor proporcionado por el propio cliente, estamos permitiendo indirectamente que ese cliente influya sobre su identidad de red desde el punto de vista de la aplicación.
Y entonces volvemos a la pregunta anterior:
¿qué hacemos después con esa IP?
Si solamente la imprimimos en una página de estadísticas, el impacto será limitado.
Si la utilizamos para decidir permisos, bloquear solicitudes o registrar evidencias de un incidente, las consecuencias cambian.
Cloudflare, balanceadores y proxies inversos: estar detrás de ellos no basta
Aquí hay una idea que considero especialmente importante.
Usar Cloudflare no convierte automáticamente una arquitectura en segura.
Lo mismo ocurre con cualquier proxy inverso o balanceador.
Podemos instalar una capa muy potente delante de PrestaShop y seguir teniendo una configuración incorrecta detrás.
Hay que revisar qué cabeceras recibe nuestro servidor, qué componente las establece, cuáles sobrescribe la infraestructura y cuáles acepta finalmente la aplicación.
Por eso aprovecharía esta actualización para revisar la arquitectura completa y no únicamente la versión instalada.
Los logs también pueden perder fiabilidad
Hay una consecuencia de CVE-2026-84186 que me preocupa especialmente: la trazabilidad.
Cuando ocurre un incidente de seguridad, uno de los primeros sitios a los que solemos acudir son los registros.
Queremos saber qué ocurrió, cuándo ocurrió, qué URLs se solicitaron, qué cuentas participaron y desde qué direcciones se originaron determinadas peticiones.
La IP aparece muchas veces como una pieza importante de ese puzle.
Pero ¿qué ocurre cuando tenemos dudas sobre cómo se obtuvo?
Qué ocurre cuando investigas un incidente
Imaginemos que estamos analizando una actividad sospechosa y encontramos varias peticiones asociadas a una dirección determinada.
Es tentador asumir inmediatamente:
Esta era la IP del atacante.
Pero en una arquitectura con proxies, cabeceras de forwarding y aplicaciones intermedias, debemos ser más cuidadosos.
Si el valor registrado por una determinada capa pudo estar influido por datos enviados por el cliente, esa IP deja de poder tratarse automáticamente como una evidencia totalmente fiable del origen real.
En mi caso, ese aspecto me parece casi tan importante como cualquier control de acceso.
Porque afecta a lo que ocurre después del ataque.
Podemos tener más dificultades para reconstruir los hechos, correlacionar eventos entre distintos sistemas o diferenciar una dirección legítima de otra introducida para generar ruido.
Por qué una IP registrada no siempre equivale al origen real de la petición
Esto tampoco significa que todos los logs de una tienda pasen a ser inútiles.
Una infraestructura suele generar registros en diferentes puntos:
- CDN.
- Proxy.
- Balanceador.
- Servidor web.
- Aplicación.
- Sistemas de seguridad adicionales.
Precisamente por eso, cuando investigamos un incidente, es recomendable correlacionar diferentes fuentes en lugar de asumir que un único campo contiene toda la verdad.
Una CDN puede disponer de información que no se está registrando de la misma manera dentro de PrestaShop.
Un proxy puede conocer la conexión recibida directamente mientras que la aplicación trabaja con una cabecera reenviada.
CVE-2026-84186 sirve como buen recordatorio de una regla más general: registrar una IP y conocer realmente el origen de una petición no son necesariamente la misma cosa.
Qué versiones de PrestaShop están afectadas por CVE-2026-84186
Aquí conviene evitar complicaciones innecesarias.
Si administras una tienda dentro de las ramas afectadas, las versiones corregidas que debemos tomar como referencia son:
PrestaShop 8.2.8
y
PrestaShop 9.1.5
Si tu instalación está dentro de una de las ramas afectadas y todavía no incorpora la corrección, mi recomendación sería planificar la actualización cuanto antes.
No dejaría una vulnerabilidad de este tipo pendiente simplemente porque no parezca tan espectacular como una ejecución remota de código.
Como hemos visto, su importancia depende de lo que nuestra tienda haga con la dirección IP obtenida.
PrestaShop 8 y la actualización a 8.2.8
Para instalaciones que deban permanecer en la rama 8, PrestaShop 8.2.8 es la versión corregida que debemos tener como referencia para este problema.
Pero actualizar una tienda de comercio electrónico requiere algo más de cuidado que actualizar una aplicación cualquiera.
Antes de tocar producción comprobaría al menos:
- versión exacta instalada;
- compatibilidad de módulos;
- compatibilidad del tema;
- modificaciones del core, si existen;
- overrides;
- personalizaciones;
- versión de PHP y entorno;
- estrategia de copia de seguridad;
- posibilidad de probar previamente en staging.
No utilizaría una vulnerabilidad como excusa para realizar una actualización a ciegas.
La actualización es importante, pero también necesitamos que la tienda siga funcionando después.
PrestaShop 9 y la actualización a 9.1.5
Para la rama 9, la versión corregida indicada es PrestaShop 9.1.5.
El enfoque sería el mismo.
Primero identificar exactamente dónde estamos y después llevar la instalación a una versión que incluya la corrección, siguiendo el procedimiento adecuado para nuestro entorno.
Hay otra precaución importante: no asumiría que “mi hosting se encarga de todo”.
Un proveedor puede gestionar sistema operativo, servidor web o infraestructura, pero eso no implica necesariamente que actualice nuestra aplicación, nuestros módulos o nuestras personalizaciones.
La responsabilidad de comprobar qué versión ejecuta realmente la tienda sigue siendo importante.
Cómo solucionar CVE-2026-84186 en PrestaShop
La acción principal es bastante clara:
actualizar PrestaShop a una versión que incluya la corrección.
Pero yo separaría el proceso en varias fases para reducir riesgos.
Actualiza primero a una versión corregida
El objetivo inmediato es dejar de utilizar una versión vulnerable dentro de las ramas afectadas.
Para ello tomaría como referencia:
- 8.2.8 en PrestaShop 8.
- 9.1.5 en PrestaShop 9.
No retrasaría innecesariamente la actualización porque “la tienda está detrás de Cloudflare” o porque exista un firewall delante.
Las capas adicionales de seguridad son útiles, pero no sustituyen una corrección en la propia aplicación.
Haz una copia de seguridad antes de actualizar
Antes de realizar una actualización importante en producción, quiero poder volver atrás.
Como mínimo, conservaría:
- archivos de la tienda;
- base de datos;
- configuración relevante;
- personalizaciones;
- información necesaria para restaurar el servicio.
Y no me limitaría a comprobar que “el backup ha terminado”.
Una copia de seguridad solamente es realmente útil si sabemos que podemos restaurarla.
Comprueba módulos, tema y personalizaciones
PrestaShop rara vez funciona completamente solo.
Normalmente tenemos módulos de pago, logística, facturación, SEO, analítica, feeds, marketplaces, ERP, CRM y muchas otras integraciones.
Por eso comprobaría compatibilidad antes del cambio.
Especialmente si la tienda genera una parte importante de la facturación del negocio, realizaría primero el proceso en un entorno de pruebas lo más parecido posible a producción.
Verifica la tienda después de la actualización
Después de actualizar no me quedaría únicamente con un mensaje de “actualización completada”.
Probaría al menos:
- navegación por el catálogo;
- inicio de sesión;
- carrito;
- checkout;
- métodos de pago;
- envío;
- correos;
- área de administración;
- tareas automáticas importantes;
- integraciones externas;
- logs.
Y para esta vulnerabilidad añadiría una comprobación adicional:
verificar cómo está detectando PrestaShop la dirección IP del visitante.
Actualizar PrestaShop no es suficiente: revisa también tu infraestructura
Esta es probablemente la parte más importante del artículo después de la actualización.
Podemos corregir CVE-2026-84186 y aun así conservar una infraestructura mal configurada.
Son dos problemas diferentes.
La versión corregida resuelve el comportamiento vulnerable de PrestaShop, pero nuestra CDN, nuestro proxy o nuestro balanceador siguen teniendo que tratar correctamente las cabeceras que reciben.
Comprueba quién puede establecer X-Forwarded-For
Yo empezaría aquí.
Necesitamos saber:
- qué componente recibe directamente las conexiones de Internet;
- qué cabeceras acepta;
- cuáles elimina;
- cuáles sobrescribe;
- cuáles añade;
- qué ve finalmente nuestro servidor;
- qué información considera fiable PrestaShop.
No deberíamos confiar en una cabecera simplemente porque tenga un nombre conocido.
La confianza debe proceder de la arquitectura, no del nombre del encabezado.
Configura correctamente tu CDN, proxy inverso o balanceador
Una configuración sólida debería permitirnos identificar con claridad qué intermediarios son de confianza.
Además, nuestra infraestructura frontal debería controlar la información que reenvía hacia la aplicación.
Si cualquier visitante puede introducir un valor que atraviesa intacto todas nuestras capas y termina siendo interpretado como información fiable del proxy, tenemos un problema de diseño.
Asegúrate de que las cabeceras se sobrescriben desde infraestructura de confianza
Este punto merece especial atención.
Si utilizamos una infraestructura frontal para informar de la IP real, queremos que sea esa infraestructura la encargada de establecer el dato en el que vamos a confiar.
No el visitante.
Es exactamente la clase de detalle que puede pasar desapercibido cuando desplegamos una CDN siguiendo un tutorial rápido y después damos por hecho que todo está protegido.
Revisa logs y controles que dependen de la dirección IP
Después buscaría cualquier lugar donde la IP tenga consecuencias:
- accesos restringidos;
- modo mantenimiento;
- módulos antifraude;
- sistemas de bloqueo;
- geolocalización;
- limitadores de peticiones;
- monitorización;
- registros;
- desarrollos personalizados.
No porque todos ellos sean vulnerables automáticamente, sino porque son los puntos donde una IP incorrecta puede tener consecuencias reales.
Una tienda puede estar perfectamente actualizada y continuar teniendo una mala configuración de infraestructura.
La seguridad no termina al pulsar el botón de actualizar.
Qué comprobaría yo después de aplicar la actualización
Después de instalar la versión corregida, haría algunas comprobaciones específicas.
No se trata solamente de confirmar que la web abre.
Quiero saber que la cadena completa funciona como espero.
La IP que realmente recibe PrestaShop
Primero comprobaría qué dirección IP está interpretando la aplicación en condiciones normales.
Si accedo a través de la CDN o del proxy, quiero confirmar que PrestaShop recibe la IP correcta y no simplemente la dirección de la infraestructura intermedia.
Pero además quiero comprobar que ese valor procede de una fuente en la que realmente puedo confiar.
Son dos comprobaciones distintas:
¿Es correcta la IP?
y
¿puede un visitante influir indebidamente sobre ella?
El comportamiento detrás de Cloudflare o del proxy
Si utilizo Cloudflare, un proxy inverso o un balanceador, revisaría cómo viajan las cabeceras entre cada componente.
No asumiría que la configuración por defecto es necesariamente la adecuada para mi arquitectura.
También documentaría el funcionamiento.
Dentro de seis meses puede cambiar un servidor, una CDN, un proxy o una persona del equipo. Tener claro qué componente es responsable de conservar la IP real evita muchos problemas.
Restricciones por IP y accesos en modo mantenimiento
Después probaría cualquier funcionalidad importante que dependa de direcciones IP.
Especialmente:
- accesos administrativos restringidos;
- listas de IP autorizadas;
- accesos durante mantenimiento;
- módulos que hagan controles específicos;
- herramientas internas.
Quiero asegurarme de que siguen funcionando y de que utilizan la información adecuada.
Monitorización y registros
Por último, revisaría los logs.
Compararía, cuando sea posible, la información registrada por diferentes capas.
Si Cloudflare registra una cosa, el proxy otra y la aplicación una tercera, quiero entender el motivo.
No necesariamente tienen que almacenar exactamente el mismo dato, pero sí necesitamos comprender de dónde sale cada dirección IP que aparece en nuestros registros.
Eso facilita muchísimo cualquier análisis posterior.
CVE-2026-84186 demuestra que la IP también forma parte de la seguridad
CVE-2026-84186 me parece un buen ejemplo de esas vulnerabilidades que esconden una lección más interesante que el fallo concreto.
Estamos acostumbrados a considerar sensibles las contraseñas, sesiones, tokens, permisos o consultas a bases de datos.
Pero a veces dejamos en segundo plano información aparentemente sencilla como la dirección IP.
Y una IP puede convertirse en un dato de seguridad en el momento en el que empezamos a tomar decisiones utilizando ese valor.
Si utilizamos la dirección para controlar accesos, detectar abuso, aplicar restricciones o investigar incidentes, necesitamos tener garantías razonables sobre cómo se ha obtenido.
Por eso, si gestionara ahora mismo una tienda PrestaShop dentro de las ramas afectadas, actuaría en dos niveles.
El primero es inmediato:
actualizaría a la versión corregida correspondiente.
PrestaShop 8.2.8 o 9.1.5, según la rama.
El segundo es más amplio:
revisaría cómo está configurada la infraestructura que existe delante de la tienda.
Comprobaría proxies, CDN, balanceadores y, especialmente, el tratamiento de las cabeceras utilizadas para identificar la IP original.
No basta con colocar una CDN delante de PrestaShop y asumir que desde ese momento toda la cadena es segura.
Hay que definir quién puede proporcionar cada dato y en qué sistemas confiamos.
Para mí, esa es la enseñanza más importante de CVE-2026-84186:
una aplicación puede estar tomando una decisión perfectamente lógica sobre un dato que nunca debería haber considerado fiable.
Corregir la vulnerabilidad es imprescindible.
Entender por qué se produjo nos ayuda a evitar muchas otras.
Dudas de la comunidad
¿Qué es CVE-2026-84186?
CVE-2026-84186 es una vulnerabilidad relacionada con la forma en la que PrestaShop determina la dirección IP de un visitante en determinados escenarios donde existen proxies, CDNs o balanceadores.
El problema permite que información relacionada con X-Forwarded-For pueda influir indebidamente en la IP que termina considerando la aplicación.
¿Qué versiones de PrestaShop corrigen CVE-2026-84186?
Las versiones corregidas indicadas son PrestaShop 8.2.8 y PrestaShop 9.1.5.
Si gestionas una instalación dentro de las ramas afectadas, conviene comprobar la versión exacta y actualizar a una versión que incorpore la corrección.
¿Es peligroso manipular X-Forwarded-For?
Depende de cómo utilice la aplicación la información obtenida.
Si la dirección IP participa en controles de acceso, sistemas antifraude, rate limiting, restricciones, geolocalización, monitorización o registros, manipular la IP interpretada por la aplicación puede reducir la efectividad de esos mecanismos.
¿Me afecta si utilizo Cloudflare?
Utilizar Cloudflare no permite concluir automáticamente que una instalación esté afectada o protegida.
Lo importante es cómo están configuradas las cabeceras entre el visitante, Cloudflare, el servidor y PrestaShop.
La infraestructura frontal debe gestionar correctamente las cabeceras de forwarding y evitar confiar directamente en valores que pueda controlar el visitante.
¿Es suficiente con actualizar PrestaShop?
Actualizar a una versión corregida es la acción principal frente a CVE-2026-84186, pero yo aprovecharía la intervención para revisar también la infraestructura.
Comprueba la CDN, proxy inverso o balanceador, identifica qué cabeceras llegan hasta PrestaShop y asegúrate de que solamente confías en intermediarios legítimos.
¿Puede CVE-2026-84186 afectar a los logs?
Puede afectar a la confianza que depositamos en determinados registros si estos almacenan como IP de origen un valor que ha podido ser influido por el visitante.
Eso no significa que todos los logs sean inútiles. Significa que durante una investigación conviene contrastar la información registrada por las diferentes capas de la infraestructura.
¿Cómo puedo comprobar la IP real que está utilizando PrestaShop?
La comprobación debe realizarse teniendo en cuenta toda la arquitectura.
No basta con observar qué IP devuelve la aplicación. Hay que verificar también de dónde procede ese valor, qué proxy o CDN lo ha establecido y si las cabeceras potencialmente enviadas por el visitante se eliminan, sustituyen o procesan correctamente.
El objetivo no es solamente que PrestaShop muestre una IP correcta, sino que esa IP proceda de una cadena de confianza correctamente configurada.
Opinión Personal
CVE-2026-84186 me parece una vulnerabilidad mucho más interesante de lo que su descripción inicial puede hacer pensar. No estamos ante un fallo espectacular de ejecución de código ni ante una brecha directa de base de datos, pero sí ante un problema que afecta a algo fundamental: la confianza que depositamos en la dirección IP de un visitante.
Y precisamente ahí está la lección.
Muchas veces damos por hecho que, si utilizamos Cloudflare, una CDN, un proxy inverso o un balanceador, la infraestructura ya está correctamente protegida. Sin embargo, este tipo de fallos demuestra que la seguridad también depende de cómo configuramos la relación de confianza entre todas esas capas.
Por eso, yo no me limitaría a actualizar PrestaShop. Aprovecharía la ocasión para revisar qué cabeceras llegan al servidor, quién puede modificarlas y qué sistemas utilizan la IP para tomar decisiones.
Actualizar es imprescindible, pero entender por qué existe la vulnerabilidad puede ayudarnos a detectar otros problemas que todavía no tienen un CVE asociado.
¿Utilizas Cloudflare, un proxy inverso o un balanceador delante de tu tienda PrestaShop? ¿Has revisado alguna vez cómo está detectando realmente la IP de tus visitantes?
Déjame tu experiencia o tus dudas en los comentarios. Me interesa especialmente saber cómo tienes montada tu infraestructura y si este tipo de vulnerabilidades te ha hecho replantearte alguna configuración de seguridad.
