Déjenos sus datos y le enviaremos un resumen por correo electrónico.
Consiento el tratamiento de mis datos personales para el envío de material publicitario personalizado de conformidad con la Política de privacidad. Al confirmar el envío, acepta recibir material de marketing
Gracias.

El formulario se ha enviado correctamente.
Encontrará más información en su buzón.

Datos IA Móvil Finanzas Ciencias de la vida ERP
Innowise logo
Sobre nosotros
Servicios
Tecnologías
Industrias
Cartera
Flash hire iconContrátanos Flash hire iconContrátanos
Contáctenos Contáctenos
ES
Cómo trabajamos Gestión de la calidad Gestión de la seguridad Responsabilidad social de las empresas Liderazgo Nuestros expertos Blog Consejos de expertos
Testimonios Socios tecnológicos Certificaciones Premios Eventos Redacción
Desarrollo de software interno o externo 2026: pros, contras, costes y cómo elegir
Leer el artículo
Servicios completos de desarrollo de software
IT consulting & advisory Desarrollo web Desarrollo móvil Desarrollo de software integrado Desarrollo de software a medida Desarrollo de MVP Desarrollo en la nube Desarrollo de ERP Soporte de mainframe Modernización legacy
 
UI/UX design 3D design Pruebas de software y control de calidad Pruebas de seguridad Administración de bases de datos DevOps DevSecOps Red IT Staff Augmentation Equipo dedicado
Aplicación de tecnologías avanzadas
Big data Gestión de datos Análisis de datos Ingeniería de datos Visualización de datos Inteligencia empresarial Aprendizaje automático Inteligencia artificial Ciencia de datos Sostenibilidad y ESG
 
Transformación digital Automatización de procesos empresariales Automatización robótica de procesos Ciberseguridad Internet de las cosas Blockchain NFT Metaverso AR& VR
Front-end
React Angular Vue.js JavaScript
Back-end
Java .NET Python PHP Rust C/C++
 
Node.js Unity Ruby Golang Unreal Engine Cobol
Móvil
iOS Android Flutter React Native Xamarin .NET MAUI
 
Swift Kotlin
Cloud
AWS Azure GCP Sharepoint
ERP & CRM
SAP MS Dynamics 365 Odoo Salesforce Creatio
Finanzas Banca Trading Seguros eCommerce Comercio minorista
Salud Farmacéutica Educación Telecomunicaciones Medios y entretenimiento
Empresa Fabricación Automoción Logística Transporte Marketing Publicidad
Gobierno Energía y Servicios Públicos Petróleo y gas Construcción Sector inmobiliario Agricultura Viajes
Estudios de casos
Banca Finanzas Salud Farmacéutica
E-commerce Comercio minorista Fabricación Empresa
Nuestras plataformas
Sistema de seguimiento de candidatos (ATS) Sistema de GRH Sistema de gestión del aprendizaje (SGA) Sistema de reserva de espacios de trabajo
Sistema operativo financiero unificado basado en IA para monedas fiduciarias y criptomonedas
Leer estudio de caso
Contratar desarrolladores dedicados
IT Staff Augmentation Equipos dedicados Desarrolladores offshore
Contratar desarrolladores web
Angular React.js Vue.js JavaScript Ruby on Rails Full stack MEAN stack
.NET Java PHP Python Golang Cobol
Contratar desarrolladores móviles
iOS Android Kotlin React Native Swift
Contratar otros ingenieros
IA Cloud AWS Azure DevOps QA
Fintech SAP Odoo Salesforce Shopify UiPath
Datos IA Móvil Finanzas Ciencias de la vida ERP
Innowise logo
Sobre nosotros
Servicios
Tecnologías
Industrias
Cartera
Flash hire iconContrátanos
Contáctenos
es Español

Seleccionar idioma

Mobile menu arrow iconSobre nosotros
Sobre nosotros
Cómo trabajamos Gestión de la calidad Gestión de la seguridad Responsabilidad social de las empresas Liderazgo Nuestros expertos Blog Consejos de expertos
Testimonios Socios tecnológicos Certificaciones Premios Eventos Redacción
Desarrollo de software interno o externo 2026: pros, contras, costes y cómo elegir
Leer el artículo
Mobile menu arrow iconServicios
Todos los servicios
Servicios completos de desarrollo de software
IT consulting & advisory Desarrollo web Desarrollo móvil Desarrollo de software integrado Desarrollo de software a medida Desarrollo de MVP Desarrollo en la nube Desarrollo de ERP Soporte de mainframe Modernización legacy
UI/UX design 3D design Pruebas de software y control de calidad Pruebas de seguridad Administración de bases de datos DevOps DevSecOps Red IT Staff Augmentation Equipo dedicado
Aplicación de tecnologías avanzadas
Big data Gestión de datos Análisis de datos Ingeniería de datos Visualización de datos Inteligencia empresarial Aprendizaje automático Inteligencia artificial Ciencia de datos Sostenibilidad y ESG
Transformación digital Automatización de procesos empresariales Automatización robótica de procesos Ciberseguridad Internet de las cosas Blockchain NFT Metaverso
AR &VR
Mobile menu arrow iconTecnologías
Todas las tecnologías
Front-end
React Angular Vue.js JavaScript
Back-end
Java .NET Python PHP Node.js Unity Ruby Golang Rust C/C++ Unreal Engine Cobol
Móvil
iOS Android Flutter React Native Xamarin .NET MAUI Kotlin Swift
Cloud
AWS Azure GCP Sharepoint
ERP & CRM
SAP MS Dynamics 365 Odoo Salesforce Creatio
Mobile menu arrow iconIndustrias
Todos los sectores
Finanzas Banca Trading Seguros eCommerce Comercio minorista
Salud Farmacéutica Educación Telecomunicaciones Medios y entretenimiento
Empresa Fabricación Automoción Logística Transporte Marketing Publicidad
Gobierno Energía y Servicios Públicos Petróleo y gas Construcción Sector inmobiliario Agricultura Viajes
Mobile menu arrow iconCartera
Cartera
Estudios de casos
Banca Finanzas Salud Farmacéutica
E-commerce Comercio minorista Fabricación Empresa
Nuestras plataformas
Sistema de seguimiento de candidatos (ATS) Sistema de GRH Sistema de gestión del aprendizaje (SGA) Sistema de reserva de espacios de trabajo
Sistema operativo financiero unificado basado en IA para monedas fiduciarias y criptomonedas
Leer estudio de caso
Mobile menu arrow icon Contrátanos
Contrátanos
Contratar desarrolladores dedicados
IT Staff Augmentation Equipos dedicados Desarrolladores offshore
Contratar desarrolladores web
Angular React.js Vue.js JavaScript Ruby on Rails Full stack MEAN stack .NET Java PHP Python Golang Cobol
Contratar desarrolladores móviles
iOS Android Kotlin React Native Swift
Contratar otros ingenieros
IA Cloud AWS Azure DevOps QA Fintech SAP Odoo Salesforce Shopify UiPath

Lista de comprobación de seguridad de PHP: 8 pasos para detectar y corregir vulnerabilidades

5 de noviembre de 2026 19 min leer
php icon.
Herman Samolazov, Head of Engineering..
Por Herman Samolazov
Responsable de Engineering
Experto verificado
Todos los artículos de Innowise están escritos por autores con experiencia práctica. Entienden el tema más allá de la teoría y aportan conocimientos basados en proyectos reales.
7+ años de experiencia
Experto verificado
7+ años de experiencia
Herman dirige departamentos de ingeniería y establece los procesos, las estructuras de equipo y las normas técnicas que estos necesitan para crecer. Su experiencia abarca los sistemas backend de alta carga, la gestión de la entrega y el liderazgo en ingeniería.
Experiencia
Sistemas de alta carga Arquitectura de software Bases de datos
Destacado en
Medium logo.
Hablemos

Principales conclusiones

  • PHP2Shell requiere una corrección urgente. El 21 de octubre de 2026, PHP corrigió las vulnerabilidades CVE-2026-109618 y CVE-2026-109619. Ambas son vulnerabilidades críticas en tiempo de ejecución (CVSS v4.0: 9,2) que pueden permitir la ejecución remota de código sin autenticación.
  • Comprueba las versiones parcheadas. Las primeras versiones corregidas son PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Es posible que las distribuciones de Linux proporcionen las mismas correcciones mediante parches retroportados.
  • Priorice los entornos de ejecución de PHP expuestos. Apache mod_php presenta el mayor riesgo notificado, pero PHP-FPM y otras configuraciones orientadas a la web también requieren atención. Las actualizaciones del framework y la auditoría de Composer no solucionarán PHP2Shell.
  • No te limites a aplicar parches a PHP. Utiliza la lista de comprobación de ocho pasos para revisar las dependencias, el código de la aplicación, la configuración del servidor y otras vulnerabilidades de seguridad.
  • Verifica la corrección en el entorno de producción. Pide a tu equipo un informe que muestre qué versiones de PHP se están ejecutando realmente, qué cargas de trabajo se han parcheado y si hay indicios de que el sistema haya sido comprometido anteriormente.
Resumir artículo con IA
Añadir a las fuentes favoritas

Según W3Techs, PHP es el lenguaje utilizado en aproximadamente el 70 % de los sitios web en los que se conoce el lenguaje del lado del servidor. Dado que PHP es tan común, una vulnerabilidad en el intérprete puede poner en riesgo a muchos sitios web, incluso si su propio código es seguro.

El 21 de octubre de 2026, el proyecto PHP publicó parches de emergencia para dos vulnerabilidades críticas, CVE-2026-109618 y CVE-2026-109619, denominadas conjuntamente PHP2Shell. Ambas obtuvieron una puntuación de 9,2 según el CVSS v4.0 y permiten la ejecución remota de código sin autenticación. Estas fallas afectan a la memoria interna y la gestión de solicitudes de PHP.

Los primeros parches se publicaron en PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Si su sistema utiliza una de las versiones afectadas, actualice PHP de inmediato y asegúrese de que su servidor web esté ejecutando la versión parcheada. Pero el trabajo no debería terminar ahí. Para los equipos que desarrollan y mantienen aplicaciones PHP, incluidos los especialistas en desarrollo de InnowisePHP especialistas en desarrollo, el lanzamiento de octubre también es un motivo para revisar las dependencias, el código de las aplicaciones y la configuración del servidor.

En esta guía, te mostraré ocho pasos para detectar y corregir vulnerabilidades en tu configuración de PHP y confirmar que tus correcciones funcionan en producción.

Consulte los servicios relacionados que ofrecemos

Análisis de un experto: en qué se diferencia PHP2Shell de una vulnerabilidad CVE habitual relacionada con las dependencias

Un paquete de Composer vulnerable afecta al código que utiliza tu aplicación. PHP2Shell es diferente. Ambas vulnerabilidades se encuentran dentro del propio interpretador de PHP, y un atacante podría activarlas antes de Laravel, Symfony u otro framework empiece siquiera a ejecutarse. Actualizar los complementos del CMS o las dependencias de Composer no parcheará PHP, y la auditoría de Composer no detectará estas vulnerabilidades en tiempo de ejecución.

El equipo de seguridad de PHP identifica Apache mod_php como la configuración de mayor riesgo para CVE-2026-109618, con un ataque demostrado que funciona antes de que se ejecute el código de la aplicación. PHP-FPM, CGI y otras configuraciones de servidores web también se ven afectadas, aunque las condiciones de explotación difieren. Los investigadores también han demostrado la explotación de CVE-2026-109619 contra PHP-FPM.

Esto es lo que falla en cada caso:

CVECausa principalPor qué los equipos deberían prestarle atención
CVE-2026-109618Si PHP se queda sin memoria mientras procesa una solicitud, es posible que algunos datos internos queden en un estado no válido. Cuando PHP limpia la solicitud fallida, puede que utilice esos datos.Si PHP se queda sin memoria mientras procesa una solicitud, es posible que algunos datos internos queden en un estado no válido. Cuando PHP limpia la solicitud fallida, puede que utilice esos datos.
CVE-2026-109619Un trabajador de PHP puede conservar una referencia a memoria que se liberó tras una solicitud anterior. Cuando el trabajador gestiona otra solicitud, puede intentar utilizar esa referencia antigua.El problema puede trasladarse entre las solicitudes gestionadas por el mismo trabajador. Comprobar las solicitudes de la aplicación una por una no garantiza que se detecte.

Ambas vulnerabilidades pueden dar lugar a la ejecución remota de código sin autenticación. La corrección se encuentra en el entorno de ejecución de PHP, no en las dependencias de la aplicación.

Para obtener una explicación técnica más detallada, puedes consultar los avisos del proyecto PHP sobre CVE-2026-109618 y CVE-2026-109619.

¿De dónde proceden las vulnerabilidades de seguridad de PHP?

Como he mencionado anteriormente, actualizar PHP no solucionará un paquete de Composer vulnerable, y un análisis completo de dependencias no detectará problemas en tu propio código. Al revisar una aplicación PHP, analizo cuatro fuentes de riesgo de seguridad, cada una con sus propias consecuencias potenciales.

CategoríaEjemplosRiesgo principal
Tiempo de ejecución de PHPVersiones de PHP sin parches, vulnerabilidades del intérprete, versiones sin soporte técnicoLos atacantes aprovechan vulnerabilidades del propio PHP, independientemente del nivel de seguridad con el que se haya programado la aplicación.
Dependencias de tercerosPaquetes de Composer, complementos para CMS, marcos de trabajoEl código de terceros vulnerable expone a las aplicaciones a ataques, incluso cuando tu propio código es seguro.
Código de solicitudInyección SQL, XSS, CSRF, deserialización insegura, control de acceso defectuosoLos errores de programación pueden permitir que los atacantes roben datos, realicen acciones no autorizadas o pongan en peligro la aplicación.
Configuración e infraestructuraConfiguración insegura de PHP, archivos expuestos, permisos excesivosLas configuraciones incorrectas pueden exponer información confidencial o proporcionar a los atacantes un acceso mayor del previsto.

Soluciona las vulnerabilidades de PHP antes de que se agraven

Consultar con expertos

Lista de comprobación de seguridad de PHP: 8 comprobaciones imprescindibles

A continuación, repasaremos ocho comprobaciones de seguridad que yo aplicaría a una aplicación PHP ya existente. Empezaría por el entorno de ejecución de PHP que atiende las solicitudes en tiempo real y, a continuación, revisaría el código, las dependencias y la configuración en busca de problemas que una simple actualización de PHP no resolvería por sí sola.

Comprueba tu versión de PHP y los parches de seguridad

En primer lugar, identifica qué entornos de ejecución de PHP utilizan tus aplicaciones: Apache mod_php, PHP-FPM, php-cgi, FrankenPHP o LiteSpeed. Incluye los pools de FPM, los contenedores, las instalaciones de la CLI, los trabajadores de cola y las tareas programadas por separado.

No te fíes únicamente de php -v o php –ini. php -v muestra la versión de la CLI, mientras que php –ini muestra su configuración. Ninguno de los dos confirma el entorno de ejecución PHP que atiende las solicitudes web.

Compara el entorno de ejecución activo y su configuración con el aviso oficial de PHP, que incluye las versiones afectadas y las condiciones de vulnerabilidad. Apache mod_php presenta la mayor vulnerabilidad demostrada a PHP2Shell, incluida una vía de explotación antes de que se ejecute el código de la aplicación. La vulnerabilidad de PHP-FPM depende de la configuración y las vías de ejecución. También es necesario evaluar otras SAPI, ya que la SAPI por sí sola no determina si una implementación es segura.

Las primeras versiones de los desarrolladores que contenían ambas correcciones fueron:

Rama PHPPrimera versión corregida
8.28.2.35
8.38.3.36
8.48.4.27
8.58.5.12

Estas versiones aparecen en los avisos de seguridad de PHP para CVE-2026-109618 y CVE-2026-109619. Comprueba si hay versiones de seguridad más recientes antes de actualizar.

Verificar los parches de PHP en Linux y en contenedores

Comprueba el entorno de ejecución activo. Revisa la configuración de tu servidor web para identificar el módulo PHP, el grupo FPM o el SAPI integrado que gestiona las solicitudes. Confirma su versión mediante diagnósticos de acceso restringido y, a continuación, elimina cualquier punto final temporal. Nunca expongas públicamente phpinfo() ni un punto final de versión.

Comprueba los paquetes instalados. En Ubuntu con PHP 8.3, estos comandos de solo lectura muestran los paquetes instalados y las versiones disponibles:

dpkg-query -W 'php8.3*'
apt-cache policy php8.3-fpm

Adapta los nombres de los paquetes a tu rama de PHP y compara las versiones instaladas con el aviso de seguridad del proveedor o el registro de cambios del paquete. Los proveedores de Linux pueden retroportar correcciones a versiones anteriores de PHP. Por ejemplo, Ubuntu enumera estas compilaciones parcheadas:

  • Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13

  • Ubuntu 22.04: 8.1.2-1ubuntu2.28

Ambas contienen las correcciones pertinentes a pesar de tener números de versión más bajos. Consulta el aviso de seguridad de Ubuntu.

Aplica el parche y vuelve a implementar. Instala los paquetes parcheados. En el caso de los contenedores, registra el resumen de la imagen en ejecución, actualiza las imágenes base vulnerables de PHP, recompila y vuelve a implementar las cargas de trabajo afectadas, incluidos los trabajadores de cola.

Verifica el resultado. Reinicia o sustituye los trabajadores PHP afectados y confirma que los procesos y contenedores en ejecución utilicen compilaciones parcheadas o adaptaciones de seguridad verificadas del proveedor. Registra las versiones de los paquetes, los resúmenes de las imágenes en ejecución, los detalles del reinicio y los resultados de la verificación.

PHP 8.1 y versiones anteriores ya no cuentan con soporte por parte del desarrollador original, aunque algunos proveedores siguen proporcionando adaptaciones de seguridad. Comprueba si tu versión instalada está cubierta y actualízala si no es así. El soporte de seguridad de PHP 8.2 finaliza el 31 de diciembre de 2026, por lo que cualquier parche a corto plazo debe ir acompañado de un plan de actualización. Puede consultar el calendario completo de soporte en el calendario de soporte de PHP.

Dependencias y marcos de auditoría

Empieza por composer.lock. Este archivo recoge las versiones de los paquetes de los que depende tu aplicación, incluidas aquellas instaladas indirectamente a través de otros paquetes. Ejecuta estos dos comandos:

composer audit --locked
composer outdated

composer audit --locked comprueba las versiones bloqueadas con respecto a los avisos de seguridad conocidos y puede señalar los paquetes abandonados. composer outdated muestra qué actualizaciones están disponibles, pero un paquete desactualizado no es necesariamente vulnerable. Consulta también los avisos de Laravel o Symfony, especialmente si la versión de tu framework ya no recibe soporte.

Compara los paquetes implementados en producción con las versiones del archivo «lock» auditado. Conserva los resultados de la auditoría y el inventario de paquetes instalados junto con tus registros de lanzamiento.

Si encuentras paquetes vulnerables, actualízalos a versiones parcheadas compatibles y prueba la funcionalidad afectada. Sustituye las bibliotecas que ya no reciban parches de seguridad. Si los problemas de compatibilidad impiden la actualización del marco de trabajo, documéntalos junto con el trabajo de migración necesario. No pases por alto los complementos de CMS ni las bibliotecas instaladas fuera de Composer.

Una auditoría de Composer sin incidencias no confirma que PHP2Shell esté solucionado. La auditoría comprueba los paquetes de Composer, mientras que PHP2Shell requiere una comprobación independiente del interpretador de PHP y sus parches. Para evaluar la propia aplicación, utiliza SAST para analizar el código fuente y DAST para probar la aplicación en ejecución.

Revisión de PHP y configuraciones del servidor

Comprueba la configuración de PHP que utiliza realmente tu servidor web, incluidas las modificaciones del grupo de procesos de PHP-FPM y las extensiones cargadas. Recuerda que php --ini muestra la configuración de la CLI, que puede diferir de la de la aplicación en producción.

Para el entorno de producción, empieza con:

display_errors = Off
log_errors = On

Mantén los registros fuera de los directorios de acceso público y restringe el acceso a ellos. Elimina las páginas públicas phpinfo() y los puntos finales de depuración, y revisa expose_php, las extensiones innecesarias y los permisos del sistema de archivos.

Desactivar display_errors reduce la divulgación de información, pero no mitiga la vulnerabilidad CVE-2026-109619. La ruta de código vulnerable puede ejecutarse antes de que PHP gestione el mensaje de error.

Medidas temporales cuando PHP se retrasa en la aplicación de parches

Si hay que esperar para aplicar el parche, sigue las instrucciones del aviso oficial de PHP correspondiente a su configuración.

  • CVE-2026-109619: Desactiva session.upload_progress.enabled y, en PHP 8.5, configura fatal_error_backtraces=0. Aplica estos ajustes antes de procesar las solicitudes a través de la configuración del servidor o del grupo de trabajadores y, a continuación, reinicia los trabajadores afectados. Es posible que persistan otras vías de explotación.

  • CVE-2026-109618: Imponer memory_limit=-1 a nivel de servidor o de grupo y reiniciar los trabajadores afectados. Esto elimina la vía de fallo predecible relacionada con el límite de memoria de PHP, pero sigue siendo posible que se produzcan otros fallos de asignación. Comprueba los límites de las solicitudes y las protecciones de memoria del host o del contenedor para reducir los riesgos de denegación de servicio.

PHP también ha publicado un aviso independiente para CVE-2026-115560 el 23 de octubre. Afecta a las aplicaciones que cambian session.serialize_handler de php_binary o php_serialize a php utilizando ini_set() antes de session_start(), con el progreso de la carga habilitado. Las configuraciones afectadas deben desactivar el progreso de la subida hasta que se publique una corrección.

Contrata un plan de actualización para las aplicaciones heredadas PHP de las que depende tu empresa

Contáctenos

Comprueba si hay inyección SQL, XSS y ejecución de código no seguro

Si no se gestionan adecuadamente las entradas de los usuarios, se pueden exponer datos confidenciales o permitir que los atacantes ejecuten código malicioso. Te recomiendo que utilices la revisión de código para rastrear las rutas de entrada de riesgo y SAST para detectar posibles vulnerabilidades. El DAST autorizado prueba la aplicación en ejecución, mientras que las pruebas de penetración ayudan a determinar qué puntos débiles podrían aprovechar los atacantes. Las aplicaciones creadas mediante programación «vibe» pueden presentar los mismos fallos y requieren las mismas comprobaciones.

Inyección SQL

La inyección SQL se produce cuando los datos introducidos por el usuario modifican la estructura de una consulta a la base de datos. Comprueba cómo tu aplicación construye las consultas, especialmente en los formularios de búsqueda y los informes.

Para mantener los datos introducidos por el usuario separados de los comandos SQL, utiliza sentencias preparadas de PDO:

$stmt = $pdo->prepare(
    'SELECT id FROM users WHERE email = :email'
);
$stmt->execute(['email' => $email]);

Las sentencias preparadas mantienen los valores de los datos separados de la sintaxis SQL, tal y como hace el marcador de posición :email en el ejemplo. Sin embargo, los marcadores de posición no pueden representar nombres de tablas o columnas. Por ejemplo, si los usuarios pueden ordenar un informe, selecciona las columnas permitidas de una lista definida en la aplicación. Prueba las consultas afectadas tras realizar los cambios.

Scripting entre sitios

El 'cross-site scripting' (XSS) se produce cuando una aplicación muestra datos no fiables que el navegador puede ejecutar como código. Comprueba las plantillas PHP para detectar entradas de usuario que se muestren sin el escape adecuado, especialmente cuando el escape automático esté desactivado.

Por ejemplo, si tu aplicación muestra el nombre de un usuario como texto HTML, utiliza htmlspecialchars() para convertir los caracteres especiales de modo que el navegador los trate como texto:

echo htmlspecialchars(
    $name,
    ENT_QUOTES | ENT_SUBSTITUTE,
    'UTF-8'
);

La protección adecuada depende de dónde aparezcan los datos. JavaScript, las URL y los atributos HTML requieren comprobaciones y codificaciones específicas según el contexto. Si los usuarios pueden enviar HTML con formato, utiliza un sanitizador de HTML para eliminar los elementos peligrosos, conservando al mismo tiempo el formato permitido.

Código no seguro y ejecución de comandos

Some PHP functions can execute system commands or PHP code. Check whether untrusted input reaches exec(), shell_exec(), or eval(). Also review dynamic file inclusion and the use of unserialize() with data from untrusted sources.

Where possible, use a PHP API instead of running a shell command. If you need to start an external program, specify the executable and pass its arguments separately. Here’s an example using Symfony Process:

use Symfony\Component\Process\Process;

// Validate $filePath against approved paths first.
$process = new Process([
    '/usr/bin/file',
    '--',
    $filePath
]);
$process->mustRun();

This example uses the file utility to identify a file’s type. Symfony Process passes $filePath as a separate argument rather than inserting it into a shell command string. You still need to validate the path, restrict the service account’s filesystem access, and allow only the operations your application requires.

Deserialization needs a separate check. Avoid passing untrusted data to unserialize(), even with allowed_classes restrictions. Where suitable, use JSON instead and validate the decoded values.

Repasa la autenticación, las sesiones y el control de acceso

Empieza por las contraseñas. No deben almacenarse en un formato legible. Comprueba que tu aplicación utilice las funciones password_hash() y password_verify() de PHP, o los métodos equivalentes del framework. Busca código de hash antiguo que pueda haber dejado de ser seguro.

A continuación, comprueba qué ocurre cuando alguien inicia sesión. La aplicación debería generar un nuevo ID de sesión, de modo que un ID obtenido antes de iniciar sesión no pueda reutilizarse para acceder a la cuenta. Revisa la configuración de session.use_strict_mode y de las cookies, como Secure, HttpOnly y SameSite. Prueba la regeneración del ID de sesión a través de tu marco de trabajo, incluso cuando lleguen varias solicitudes a la vez.

Ahora comprueba si los usuarios pueden ver datos que no les pertenecen. Crea dos cuentas de prueba, cada una con su propia factura. Inicia sesión en la primera cuenta y cambia el ID de la factura en una solicitud por el que pertenece a la segunda cuenta. El servidor debería denegar el acceso a menos que ese usuario tenga permiso.

Repite la prueba para la edición de facturas, la descarga de archivos y las solicitudes a la API. Comprueba que los usuarios normales no puedan acceder a las funciones de administración. El hecho de haber iniciado sesión no otorga automáticamente permiso para acceder a todos los registros. El servidor debe comprobar los permisos en cada solicitud dirigida a un registro protegido o a un punto final de la API.

Comprobar la protección contra CSRF

Un ataque CSRF engaña al navegador de un usuario que ha iniciado sesión para que realice una acción que no ha autorizado, como modificar los datos de la cuenta. Empieza por revisar los formularios y las solicitudes que modifican datos, especialmente aquellos que se autentican mediante cookies de sesión.

Revisa la protección contra CSRF en tu aplicación Laravel o Symfony y comprueba si hay alguna ruta excluida. Cuando se aplique la validación de tokens, prueba las solicitudes con tokens que falten o que no sean válidos. Comprueba también que las solicitudes falsificadas procedentes de otro sitio web no puedan modificar los datos de los usuarios. Comprueba asimismo la configuración SameSite en las cookies de sesión.

En Laravel Blade, @csrf añade un campo de token oculto a un formulario:


    @csrf

Hay un detalle importante en Laravel 13. Su middleware CSRF comprueba primero el encabezado Sec-Fetch-Site. Una solicitud de mismo origen puede pasar sin token, mientras que otras solicitudes recurren a la validación del token por defecto. Laravel también desactiva la protección CSRF durante las pruebas automatizadas por defecto, así que asegúrate de que esté activada al probar estas defensas.

En el caso de las API, el método de autenticación es importante. Una API sin estado que utilice tokens de portador en los encabezados de autorización suele enfrentarse a riesgos de CSRF diferentes. Pero si tu SPA se basa en cookies de sesión, seguirá necesitando protección contra las solicitudes falsificadas.

Carga y acceso seguros a archivos

La subida de archivos se convierte en un riesgo de seguridad cuando los atacantes pueden subir archivos ejecutables o acceder a datos a los que no deberían tener acceso. Comprueba qué tipos y tamaños de archivo acepta tu aplicación, dónde se almacenan los archivos subidos y quién puede descargarlos. Comprueba las rutas de subida y descarga en busca de 'path traversal', asegúrate de que los archivos subidos no se puedan ejecutar como PHP y comprueba que .env, .git y los archivos de copia de seguridad no sean accesibles públicamente.

A continuación se muestra un PHP ejemplo que comprueba el tipo MIME de un archivo subido y lo guarda con un nombre generado aleatoriamente:

if (($_FILES['file']['error'] ?? null) !== UPLOAD_ERR_OK) {
    throw new RuntimeException('Error en la subida');
}

$tmp = $_FILES['file']['tmp_name'];
$allowed = ['image/jpeg' => 'jpg', 'image/png' => 'png'];
$mime = (new finfo(FILEINFO_MIME_TYPE))->file($tmp);

if (!isset($allowed[$mime])) {
    throw new RuntimeException('Tipo de archivo no admitido');
}

$name = bin2hex(random_bytes(16)) . '.' . $allowed[$mime];
$target = '/var/app/private-uploads/' . $name;

if (!move_uploaded_file($tmp, $target)) {
    throw new RuntimeException('No se ha podido guardar la subida');
}

El ejemplo parte de la base de que se sube un único archivo y de que existe un directorio privado con los permisos adecuados. La función move_uploaded_file() de PHP confirma que el archivo de origen se subió a través del mecanismo HTTP POST de PHP.

La comprobación del tipo MIME por sí sola no es suficiente para garantizar la seguridad de las subidas. El código de producción también necesita límites de tamaño de archivo impuestos por el servidor, permisos de subida y descarga, y la validación del contenido real de los archivos. Recodifica las imágenes cuando sea necesario y considera la posibilidad de realizar análisis de malware para las subidas de mayor riesgo. Mantenga los archivos fuera de la raíz web siempre que sea posible, restrinja el acceso al sistema de archivos y evite que los archivos subidos se ejecuten como PHP.

Protege los datos confidenciales y las credenciales

Las contraseñas de bases de datos, las claves API y los tokens de acceso expuestos pueden permitir a los atacantes acceder a tu aplicación o a datos confidenciales. Revisa tu código fuente y el historial de Git en busca de estos secretos. Herramientas como Gitleaks pueden ayudarte a encontrarlos. Asegúrate de que los archivos .env no se almacenen en Git ni sean accesibles a través de la web. Revisa también quién puede acceder a los secretos en los pipelines de CI/CD, y comprueba si hay información confidencial en las imágenes de contenedores y los registros de la aplicación.

Guarda los secretos en un gestor de secretos u otro sistema con acceso restringido, en lugar de en el código de la aplicación. Limita quién puede verlos o modificarlos, y concede a cada aplicación solo los permisos que necesite.

Si se filtra una credencial, revócala o sustitúyela y actualiza los servicios que la utilizan. Elimina las copias filtradas, investiga si alguien la ha utilizado sin permiso y evita que los secretos aparezcan en futuros registros. Eliminar un secreto de tu código no lo desactiva ni lo borra de las antiguas confirmaciones de Git.

Solicita una evaluación de seguridad de PHP realizada por expertos

Programar una llamada

Cómo priorizar, implementar y verificar las correcciones de seguridad de PHP

01
Priorizar las vulnerabilidades

Da prioridad a los sistemas expuestos a ataques. Evalúa el CVSS junto con la SAPI de PHP, la exposición a Internet, las protecciones existentes y el impacto en el negocio. Las cargas de trabajo de mod_php sin parches y expuestas a Internet requieren atención urgente, mientras que otras SAPI aún deben evaluarse.

02
Aplicar parches de forma segura

Registra las aplicaciones afectadas, los grupos de trabajadores PHP y los resúmenes de las imágenes de contenedores. Realice pruebas en el entorno de staging y prepare un plan de recuperación antes de la implementación. Aplique parches a los paquetes afectados o vuelva a compilar las imágenes; a continuación, reinicie o sustituya todos los trabajadores afectados. Las reglas del WAF y las medidas de mitigación en la configuración pueden reducir la exposición a vías de explotación específicas. No corrigen el entorno de ejecución vulnerable.

03
Comprobar la corrección

Comprueba qué versión de PHP atiende las solicitudes en tiempo real y confirma su estado de parches, incluyendo cualquier retroportación del proveedor. Verifica que los trabajadores afectados se hayan reiniciado o sustituido, ejecuta pruebas de regresión y repite la comprobación de seguridad que había fallado anteriormente. Supervisa el entorno de producción en busca de errores tras la implementación.

04
Investigar una posible filtración

La aplicación del parche soluciona la vulnerabilidad. Cualquier incidente anterior sigue requiriendo una investigación. Revisa los registros del servidor, los fallos de los procesos de trabajo, los archivos desconocidos y la actividad de red sospechosa. En mod_php, PHP2Shell puede ejecutarse antes de que comience el registro de la aplicación, por lo que unos registros del framework limpios no pueden descartar un ataque. Remite las señales de alerta al equipo de respuesta a incidentes y conserva las pruebas.

05
Garantizar la seguridad

Realiza un seguimiento de las nuevas vulnerabilidades de PHP y de sus dependencias, y añade comprobaciones de seguridad a CI/CD. Basa las evaluaciones periódicas en la exposición de las aplicaciones y el riesgo empresarial, y vuelve a evaluarlas tras cambios importantes o revelaciones críticas.

arrow-icon.arrow-icon.
01 Priorizar las vulnerabilidades

Da prioridad a los sistemas expuestos a ataques. Evalúa el CVSS junto con la SAPI de PHP, la exposición a Internet, las protecciones existentes y el impacto en el negocio. Las cargas de trabajo de mod_php sin parches y expuestas a Internet requieren atención urgente, mientras que otras SAPI aún deben evaluarse.

arrow-icon.arrow-icon.
02 Aplicar parches de forma segura

Registra las aplicaciones afectadas, los grupos de trabajadores PHP y los resúmenes de las imágenes de contenedores. Realice pruebas en el entorno de staging y prepare un plan de recuperación antes de la implementación. Aplique parches a los paquetes afectados o vuelva a compilar las imágenes; a continuación, reinicie o sustituya todos los trabajadores afectados. Las reglas del WAF y las medidas de mitigación en la configuración pueden reducir la exposición a vías de explotación específicas. No corrigen el entorno de ejecución vulnerable.

arrow-icon.arrow-icon.
03 Comprobar la corrección

Comprueba qué versión de PHP atiende las solicitudes en tiempo real y confirma su estado de parches, incluyendo cualquier retroportación del proveedor. Verifica que los trabajadores afectados se hayan reiniciado o sustituido, ejecuta pruebas de regresión y repite la comprobación de seguridad que había fallado anteriormente. Supervisa el entorno de producción en busca de errores tras la implementación.

arrow-icon.arrow-icon.
04 Investigar una posible filtración

La aplicación del parche soluciona la vulnerabilidad. Cualquier incidente anterior sigue requiriendo una investigación. Revisa los registros del servidor, los fallos de los procesos de trabajo, los archivos desconocidos y la actividad de red sospechosa. En mod_php, PHP2Shell puede ejecutarse antes de que comience el registro de la aplicación, por lo que unos registros del framework limpios no pueden descartar un ataque. Remite las señales de alerta al equipo de respuesta a incidentes y conserva las pruebas.

arrow-icon.arrow-icon.
05 Garantizar la seguridad

Realiza un seguimiento de las nuevas vulnerabilidades de PHP y de sus dependencias, y añade comprobaciones de seguridad a CI/CD. Basa las evaluaciones periódicas en la exposición de las aplicaciones y el riesgo empresarial, y vuelve a evaluarlas tras cambios importantes o revelaciones críticas.

Ejemplo práctico: una actualización de producción que parece haber tenido éxito, pero que en realidad no es así

Una tienda basada en Symfony ejecuta PHP 8.3 detrás de nginx y PHP-FPM. El administrador actualiza los paquetes del sistema operativo y ejecuta «php -v». El comando muestra una versión parcheada, por lo que todo parece estar bien. Pero «php -v» solo comprueba el binario de PHP de la línea de comandos.

Las solicitudes de los clientes siguen pasando por nginx hacia los trabajadores de PHP-FPM que se iniciaron antes de la actualización. Las tareas en segundo plano también se ejecutan en un contenedor independiente con una capa base de PHP vulnerable. Es posible que los paquetes se hayan actualizado en el servidor, pero estas cargas de trabajo siguen ejecutando el código antiguo.

PHP build checks for web, workers, and CLI.

Para completar el parche, el equipo debe identificar todas las aplicaciones y grupos de trabajadores afectados, reiniciar los trabajadores de FPM y volver a implementar el contenedor de colas con una imagen parcheada. A continuación, deben verificar que los procesos PHP en ejecución utilicen compilaciones corregidas o adaptaciones del proveedor verificadas.

Probar el checkout y las subidas de archivos en el entorno de staging, ejecutar pruebas de humo en producción y repetir las comprobaciones de seguridad que fallaron anteriormente. El registro de implementación debe incluir la SAPI de PHP que gestiona el tráfico web, las versiones verificadas de los paquetes o los resúmenes de las imágenes, las pruebas de reinicio y de funcionamiento, y el responsable.

Que una auditoría de Composer se supere no es prueba de que PHP2Shell se haya corregido. Ese comando comprueba las dependencias, no el PHP intérprete que gestiona las solicitudes web.

Revisa el ID de usuario del PHP worker, los directorios en los que tiene permisos de escritura, los secretos montados, los permisos de la base de datos y el acceso a la red saliente. Estos factores determinan si un atacante podría modificar archivos de la aplicación, leer credenciales o acceder a otros sistemas. El principio del privilegio mínimo y la segmentación de la red pueden limitar el daño si se ve comprometido un proceso de trabajo, pero sigue siendo necesario aplicar el parche al intérprete.

El comando «php -v» muestra la versión de PHP en la línea de comandos, pero no permite confirmar qué intérprete gestiona el tráfico de producción ni si los procesos de fondo de larga duración siguen utilizando la versión vulnerable. Con PHP2Shell, primero verificamos el entorno de ejecución activo y, a continuación, revisamos las dependencias y el código de la aplicación. Solo consideramos que la corrección se ha completado tras confirmar que la versión parcheada está gestionando realmente las solicitudes de producción.
Stanislav Kazanov, Head of GRC and Cybersecurity.
Stanislav Kazanov
Responsable de GRC, Ciberseguridad y Sostenibilidad

Cómo Innowise puede ayudarte a proteger tus aplicaciones PHP

En Innowise, combinamos nuestra experiencia en desarrollo y seguridad de PHP. Nuestros más de 100 desarrolladores de PHP han llevado a cabo más de 250 proyectos, y nuestros más de 50 ingenieros de ciberseguridad ayudan a identificar y solucionar vulnerabilidades. Nuestro trabajo cuenta además con el respaldo de las certificaciones ISO/IEC 27001:2022 e ISO 9001:2015.

Comprobamos que tus aplicaciones PHP no presenten problemas de seguridad, incluidas dependencias vulnerables y componentes obsoletos. Nuestros desarrolladores se encargan de las correcciones y actualizaciones necesarias, mientras que los ingenieros de seguridad prueban los cambios antes de su implementación. Si no sabes por dónde empezar, nuestro equipo de consultoría de seguridad informática puede evaluar los riesgos y ayudarte a priorizar el trabajo.

ISO 27001 icon.
ISO-27017-2015.
ISO-27018 icon.
ISO 9001 icon.

Nuestros proyectos de PHP

Rediseño y reconstrucción de la página web de MedSpa Network
Innowise rediseñó la página web de MedSpa Network en WordPress, lo que permitió a su equipo gestionar las actualizaciones diarias de los contenidos.
2 meses desde el inicio hasta el lanzamiento
3-5 clientes potenciales por semana, frente a 1 al mes
Ver caso práctico
Opinión de un cliente
Ver caso práctico
Client review logo. Opinión de un cliente
MedSpa Network website redesign and rebuild.
Bot de IA para la campaña de marketing del TBC Bank
Innowise ha creado un bot bilingüe para Telegram que genera selfies generados por IA con el embajador de marca de TBC Bank, una estrella del fútbol.
3,000 usuarios activos
2 idiomas disponibles
Ver caso práctico
Opinión de un cliente
Ver caso práctico
Client review logo. Opinión de un cliente
AI Telegram bot..
Definición de la estrategia de producto para la plataforma de préstamos en bitcoins de Bitlendex
Innowise llevó a cabo una fase de análisis inicial para Bitlendex, ayudando al cliente a transformar un concepto de producto en fase inicial en un modelo de negocio validado y un MVP claramente definido.
1 mes para una fase de investigación exhaustiva
Ver caso práctico
Ver caso práctico
Defining the product strategy for Bitlendex’s bitcoin lending platform.
Sistema de asesoramiento financiero para Bonnfinanz
Innowise ayudó a Bonnfinanz a desarrollar un sistema de asesoramiento y gestión basado en la web que permite el trabajo a distancia y la interacción directa con el cliente.
Ver caso práctico
Ver caso práctico
Financial advisory system for Bonnfinanz..
Plataforma de recarga de vehículos eléctricos con facturación flexible
Innowise contribuyó a modernizar la plataforma de movilidad eléctrica de SMART/LAB mejorando sus funciones de facturación, pago, gestión de transacciones y generación de informes.
>50% una tramitación más rápida de la facturación y los pagos
Ver caso práctico
Ver caso práctico
Plataforma de carga de vehículos eléctricos con facturación flexible.
Transformación DevOps cloud-native de FinXP
Innowise ayudó a FinXP a modernizar su infraestructura de servicios financieros mediante la migración de las API y aplicaciones heredadas basadas en PHP a una arquitectura nativa de la nube.
11 Aplicaciones trasladadas a Azure App Service
100% Infraestructura como código
Ver caso práctico
Ver caso práctico
FinXP’s cloud-native DevOps transformation.
SEO técnico para plataforma de e-commerce
Innowise resolvió problemas técnicos críticos relacionados con el SEO y el rendimiento en la plataforma de comercio electrónico de Officine 08.
<500 ms tiempo de respuesta del servidor
5 meses para completar el proyecto
Ver caso práctico
Opinión de un cliente
Ver caso práctico
Client review logo. Opinión de un cliente
SEO técnico para plataforma de comercio electrónico.
Desarrollo continuo de una plataforma de suscripción de fragancias
Innowise ayudó a Scentbird a ampliar su plataforma de suscripción para dar cabida a nuevas experiencias de compra y facilitar su expansión internacional.
4 años de soporte continuo
Ver caso práctico
Opinión de un cliente
Ver caso práctico
Client review logo. Opinión de un cliente
Continuous development of a fragrance subscription platform.
01 / 01
Close popup icon

Conclusión

PHP2Shell puso de manifiesto un grave riesgo en el propio intérprete de PHP. Las actualizaciones de los marcos de trabajo y las comprobaciones de dependencias no solucionarán las vulnerabilidades a ese nivel. Las empresas deben identificar todos los entornos de ejecución de PHP que gestionan solicitudes web, instalar las actualizaciones de seguridad y verificar que los servidores de producción ejecutan las versiones parcheadas.

La seguridad de PHP también requiere comprobaciones periódicas del código de las aplicaciones, la configuración y los controles de acceso, especialmente tras la divulgación de vulnerabilidades críticas o actualizaciones importantes. Si necesitas ayuda para evaluar tu exposición o verificar las correcciones, Innowise ofrece Los equipos de consultoría de seguridad de TI y de evaluación de ciberseguridad de Innowise pueden ayudarte en esa tarea.

FAQ

Tu aplicación podría estar en peligro si tu servidor ejecuta una versión de PHP que no haya sido parcheada para las vulnerabilidades CVE-2026-109618 y CVE-2026-109619. Comprueba qué versión de PHP se está ejecutando realmente y si tu proveedor de alojamiento ha aplicado las correcciones. Apache mod_php presenta el mayor riesgo confirmado, pero también es necesario comprobar PHP-FPM. Dado que las vulnerabilidades se encuentran en el propio PHP, actualizar WordPress u otro framework no las solucionará.

Las correcciones para PHP2Shell están disponibles en PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12. Algunos proveedores de Linux han adaptado los parches a versiones anteriores, así que consulta el aviso de tu proveedor. Asegúrate de que los procesos PHP que tengas en ejecución utilicen la versión parcheada. En Windows, instala los paquetes actualizados del 26 de octubre que terminan en -1, que también corrigen otra vulnerabilidad de Brotli.

Si no puedes actualizar PHP de inmediato, restringe el acceso público a las aplicaciones afectadas siempre que sea posible. En el caso de los sitios que deban permanecer en línea, el administrador de su servidor puede aplicar medidas temporales según el aviso de seguridad de PHP, como limitar el tamaño de las solicitudes o desactivar el progreso de las subidas durante la sesión. Prueba estos cambios para asegurarte de que el sitio sigue funcionando. Solo reducen el riesgo, por lo que sigue siendo urgente instalar una versión parcheada de PHP.

No. Actualizar PHP corrige vulnerabilidades en el entorno de ejecución de PHP, pero no soluciona los problemas de seguridad del código de tu aplicación, los plugins obsoletos ni la configuración del servidor. Debes comprobarlos y solucionarlos por separado.

Recomiendo comprobar las aplicaciones PHP en busca de vulnerabilidades conocidas al menos una vez al mes, y realizar comprobaciones más frecuentes en los sistemas de alto riesgo. Supervisa PHP continuamente los avisos de seguridad y las dependencias, y programa auditorías más exhaustivas en función de la exposición de tu aplicación y del riesgo empresarial. Es importante realizar pruebas adicionales tras actualizaciones importantes o tras la divulgación de vulnerabilidades críticas.

Consulta los avisos de seguridad de PHP y los boletines de tu proveedor de alojamiento o de tu sistema operativo para conocer las vulnerabilidades conocidas. Utilice composer audit --locked para comprobar las dependencias, el análisis estático y la revisión del código para detectar problemas a nivel de aplicación, y OWASP ZAP para probar su aplicación web con permiso. Para verificar los parches de seguridad, comprueba la versión de PHP que se ejecuta en producción y cualquier corrección retroaplicada por tu proveedor.

Sí. Las actualizaciones pueden provocar problemas de compatibilidad con código antiguo o extensiones. Pruébalas en el entorno de pruebas antes de actualizar tu aplicación en producción y ten preparado un plan de recuperación por si algo falla.

Correlaciona los registros del proxy inverso, Apache/nginx, PHP-FPM y EDR/host. Busca fallos en los trabajadores, archivos o procesos sospechosos, tráfico saliente inesperado y indicios de exposición de credenciales. Los registros de la aplicación pueden pasar por alto vulnerabilidades en tiempo de ejecución de PHP que se produzcan antes de que el marco comience a registrar. Si detectas actividad sospechosa, inicia la respuesta ante incidentes y conserva las pruebas forenses.

Ver más Mostrar menos

Índice

Descubre qué cargas de trabajo de PHP necesitan una actualización de seguridad con prioridad

Evalúa mi PHP exposición

    Contáctenos

    Reserve una llamada o rellene el siguiente formulario. Nos pondremos en contacto con usted en cuanto revisemos su solicitud.

    Envíenos un mensaje de voz
    Adjuntar documentos
    Subir archivo

    Puede adjuntar 1 archivo de hasta 2 MB. Formatos de archivo válidos: pdf, jpg, jpeg, png.

    Al hacer clic en «Enviar», usted consiente que Innowise trate sus datos personales de acuerdo con nuestra Política de privacidad para proporcionarle información relevante. Al facilitar su número de teléfono, acepta que podamos contactar con usted mediante llamadas de voz, SMS y aplicaciones de mensajería. Pueden aplicarse tarifas por llamadas, mensajes y datos.

    También puede enviarnos su solicitud
    a contact@innowise.com
    ¿Qué pasa después?
    1

    Una vez recibida y revisada su solicitud, nos pondremos en contacto con usted para analizar en detalle las necesidades de su proyecto y firmar un acuerdo de confidencialidad.

    2

    Tras examinar sus deseos, necesidades y expectativas, nuestro equipo elaborará una propuesta de proyecto con el alcance del trabajo, el tamaño del equipo, el plazo y los costes estimados.

    3

    Concertaremos una reunión con usted para revisar la propuesta y concretar los detalles.

    4

    Por último, firmaremos el contrato y empezaremos a trabajar en su proyecto de inmediato.

    Contenidos relacionados

    Blog
    Generative AI trends in 2026: key technologies and future outlook.
    Tendencias de la IA generativa en 2026: tecnologías clave y perspectivas de futuro
    Descubre las principales tendencias en IA generativa para 2026. Descubre cómo están utilizando la IA generativa los distintos sectores, cuáles son los riesgos y qué nos depara el futuro.
    Michael Labutin
    5 de noviembre de 2026
    Blog
    AI discoverability: how to get your brand found, cited, and recommended by AI.
    Visibilidad para la IA: cómo conseguir que tu marca sea encontrada, citada y recomendada por la IA
    Es posible que tu marca aparezca en los resultados de Google y, aun así, sea invisible para ChatGPT. Veamos qué puede hacer la «detectabilidad por IA» al respecto.
    Yuliya Pantsiuk
    4 de noviembre de 2026
    Blog
    AI in supply chain and logistics: use cases, benefits, and implementation.
    La IA en la cadena de suministro y la logística: casos de uso, ventajas e implementación
    La inteligencia artificial se está imponiendo en el sector de la logística, y tus competidores lo saben. Descubre dónde funciona, qué ahorros genera y cómo ponerte al día.
    Philip Tikhanovich
    4 de noviembre de 2026
    Blog
    AI in social media: use cases, benefits, and trends.
    La IA en las redes sociales: casos de uso, ventajas y tendencias
    Flujos de noticias, filtros, traducción, moderación: la IA está presente en todas las redes sociales. Echemos un vistazo entre bastidores.
    Philip Tikhanovich
    30 de octubre de 2026
    Blog
    AI in CRM: use cases, benefits, and implementation.
    La IA en el CRM: casos de uso, ventajas e implementación
    ¿Qué funciones del CRM basado en IA merecen realmente tanta atención? Analizamos los casos de uso, las plataformas, los riesgos y el retorno de la inversión.
    Raman Karabach
    14 de octubre de 2026
    Blog
    AI chatbots in healthcare: use cases, benefits, and implementation.
    Chatbots con IA en el sector sanitario: casos de uso, ventajas e implementación
    Guía especializada sobre los chatbots de IA en el ámbito sanitario: casos prácticos reales, ventajas e integración clave.
    Roman Sen
    24 de septiembre de 2026
    Blog
    AI in medical imaging: applications, benefits, and implementation.
    La inteligencia artificial en el diagnóstico por imagen: aplicaciones, ventajas e implementación
    Una visión lúcida sobre cómo se utiliza actualmente la inteligencia artificial en el ámbito de las imágenes médicas.
    Aleh Yafimau
    1 de septiembre de 2026
    Blog
    LLM-as-a-judge: how we evaluate AI systems at scale.
    LLM como juez: cómo evaluamos los sistemas de IA a gran escala
    Evalúa los resultados de los modelos de lenguaje grande (LLM) con criterios de evaluación más rigurosos, puntuaciones más claras y menos puntos ciegos.
    Philip Tikhanovich
    22 de julio de 2026
    Blog
    Best 10 data modernization companies in 2026.
    Las 10 mejores empresas de modernización de datos en 2026
    Compara las principales empresas de modernización de datos y elige un socio para gestionar datos heredados, en la nube y preparados para la IA.
    Philip Tikhanovich
    16 de julio de 2026
    Blog
    Microsoft Dynamics 365 for financial services: a complete guide.
    Microsoft Dynamics 365 para el sector de los servicios financieros: una guía completa
    A los bancos les encantan los sistemas. A los equipos les disgustan los malos. Aquí es donde Dynamics 365 puede ayudar.
    Siarhei Sukhadolski
    13 de julio de 2026
    Blog
    Best 9 ERP consulting companies in 2026.
    Las 9 mejores empresas de consultoría de ERP en 2026
    Compara las 9 mejores empresas de consultoría de ERP en 2026. Analiza su experiencia y su especialización en el sector, y descubre consejos para elegir el socio más adecuado para ti.
    Kiryl Drabysheuski
    10 de julio de 2026
    Blog
    Enterprise AI adoption trends 2026.
    Tendencias en la adopción de la IA en las empresas 2026
    Las tendencias más influyentes en materia de IA para 2026 y cómo están transformando las empresas para siempre.
    Philip Tikhanovich
    7 de julio de 2026

    Más servicios que cubrimos

    Operaciones
    AIOps BPA IT gestionados Consultoría MLOps RPA
    Más información
    QA
    Pruebas automatizadas Control de calidad de aplicaciones de eCommerce Pruebas de ERP Pruebas de penetración Consultoría de control de calidad Ingenieros QA Pruebas de seguridad Pruebas Pruebas de penetración en la web
    Más información

    arrow