PolyShell CVE-2026-48356: verificar y corregir Magento

PolyShell: lo que está establecido y lo que difiere

Lo que dicen las fuentes y lo que usted retiene

Desplace la tabla

Por qué el parche no cierra el expediente

Lo que este procedimiento deja en sus manos

• Un inventario por tienda — edición (Commerce u Open Source), versión exacta, presencia o ausencia del parche 2026-jul.
• Una versión objetivo por rama — leída en el boletín APSB26-73, sin adivinar la numeración.
• Un estado congelado antes de intervenir — snapshot y exportación de la base conservados como prueba, antes de cualquier limpieza.
• Cuatro controles reproducibles — archivos bajo pub/media, puertas traseras accesson.php, JavaScript en cms_block y en cms_page.
• Una rotación completa de accesos — cuentas de administración, claves de API y de integración, base de datos, clave de cifrado, SSH y SFTP.
• Un informe fechado para cada cliente — lo que se ha verificado, encontrado y corregido, y lo que no.

Versiones afectadas y versiones corregidas según APSB26-73

Desplace la tabla

Inventariar la versión de cada tienda

1. 01

   Leer la versión declarada

   cd /var/www/tienda-cliente
bin/magento --version
   El comando muestra la edición y el número. La ruta es un ejemplo: adáptela a cada alojamiento. Ejecútelo con el usuario del sistema propietario de los archivos, no como root, para no modificar los permisos de la caché.

2. 02

   Contrastar con Composer

   composer show magento/product-community-edition
   para Magento Open Source, o
   composer show magento/product-enterprise-edition
   para Adobe Commerce. Composer lee lo que está realmente instalado. Si las dos lecturas difieren, manda Composer, y la diferencia se anota.

3. 03

   Recorrer un servidor entero

   find /var/www /home -name composer.lock -not -path '*/vendor/*' -exec grep -H -A1 '"name": "magento/product-' {} +
   Cada archivo citado pertenece a una instalación de Magento, y la línea version sigue al nombre del paquete. Una preproducción pública o una copia antigua descomprimida cuenta como una tienda: está expuesta de la misma manera si se sirve.

4. 04

   Clasificar con la tabla de versiones

   Compare el número obtenido con la tabla anterior. Regla de lectura: toda versión que no lleve el sufijo 2026-jul de su rama debe tratarse. Para Magento Open Source 2.4.5 y 2.4.4, ausentes de la lista de la NVD, no escriba «no afectada»: remita al boletín de Adobe y trate la tienda como expuesta mientras no haya leído lo contrario.

5. 05

   Anotar una línea por tienda

   Cliente, servidor, ruta, edición, versión obtenida, fecha y hora de la lectura. Añada desde ahora las columnas que servirán más adelante: parche aplicado, resultado de los cuatro controles, accesos rotados. Esta tabla se convierte en la pieza central del expediente entregado al cliente.

Congelar el estado antes de tocar: también es una prueba

Aplicar el parche sin un corte largo

1. 06

   Ensayar en una preproducción

   Restaure el estado congelado en una preproducción, o clone la tienda, y ejecute primero allí la actualización. Cronometre cada comando: esa duración fija la ventana de mantenimiento que anunciará al cliente.

2. 07

   Fijar la versión corregida

   composer require magento/product-community-edition=<version-corregida> --no-update
   Sustituya el paquete por magento/product-enterprise-edition para Adobe Commerce, y <version-corregida> por la versión con el sufijo 2026-jul de su rama, tal como la escribe el boletín.

3. 08

   Resolver y validar el archivo de bloqueo

   composer update magento/product-community-edition --with-all-dependencies
   Revise la lista de paquetes modificados. El composer.lock obtenido y probado es el que desplegará: la producción ya no resuelve nada, instala.

4. 09

   Abrir la ventana de mantenimiento en producción

   bin/magento maintenance:enable
bin/magento maintenance:allow-ips <su-ip>
   Todo lo anterior se hizo sin cortar la venta. El segundo comando le permite probar la tienda antes de reabrirla.

5. 10

   Instalar y aplicar

   composer install --no-dev
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy
   Con un archivo de bloqueo ya validado, el corte se limita a estos cuatro comandos.

6. 11

   Reabrir y comprobar

   bin/magento maintenance:disable
composer show magento/product-community-edition
   La versión instalada debe ser la versión corregida de su rama. Haga un pedido con la pasarela de pago en modo de prueba y anote después la versión y la hora en la tabla.

Buscar rastros de compromiso

1. 12

   Listar los archivos depositados bajo pub/media

   find pub/media/custom_options/ pub/media/customer_address/ -type f ! -name '.htaccess'
   Comando publicado por Sansec, que se lanza desde la raíz de la tienda. Todo archivo listado debe examinarse, en particular un script PHP. Cópielo fuera del árbol público con su fecha de modificación antes de borrarlo.

2. 13

   Buscar las puertas traseras accesson.php

   find . -name 'accesson.php' -type f
   Sansec señala este archivo «en varios directorios»: lance la búsqueda desde la raíz, no solo bajo pub/. Un resultado vacío demuestra la ausencia de ese archivo, no la ausencia de cualquier puerta trasera.

3. 14

   Consultar la tabla cms_block

   SELECT block_id, identifier, update_time FROM cms_block WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
   Consulta publicada por Sansec. Añada el prefijo de tabla de la instalación si existe. La columna update_time ayuda a fechar la inyección.

4. 15

   Consultar la tabla cms_page

   SELECT page_id, identifier, update_time FROM cms_page WHERE content LIKE '%fpCode%' OR content LIKE '%se_referrer%' OR content LIKE '%localStorage.getItem%';
   El mismo control sobre las páginas CMS. Un resultado no es necesariamente malicioso: localStorage.getItem puede aparecer en un script legítimo. Lea el contenido antes de concluir.

5. 16

   Cotejar con los indicadores publicados

   Para la oleada de marzo de 2026, Sansec publicó un dominio de cargador, lanhd6549tdhse.top, una clave de localStorage, 136c1e07507f4a97, y una marca de puerta trasera, 8194460. Búsquelos en los resultados anteriores y en los archivos encontrados, por ejemplo con grep -rl 'lanhd6549tdhse' pub/ app/. Esta lista no es exhaustiva: su ausencia no exculpa a una tienda.

6. 17

   Revisar las cuentas de administrador

   SELECT user_id, username, email, created, logdate, is_active FROM admin_user ORDER BY created DESC;
   Una cuenta que nadie reconoce, o creada en una fecha cercana a la de un archivo sospechoso, se desactiva y luego se documenta. El control mensual de estos puntos en cada VPS de cliente se describe en nuestra checklist de auditoría.

Solución de problemas: los bloqueos frecuentes del procedimiento

Después de la limpieza: lo que debe rotarse

• Contraseñas de administrador — todas las cuentas de admin_user, incluidas las que considere sanas.
• Claves de API e integraciones — tokens de las integraciones declaradas en la administración, claves de los servicios de terceros (pago, transporte, ERP) guardadas en la configuración.
• Credenciales de base de datos — una nueva contraseña, actualizada en la configuración de la tienda.
• Clave de cifrado — se cambia siguiendo la documentación de Adobe, tras evaluar el efecto sobre los datos ya cifrados.
• Accesos SSH y SFTP — contraseñas, claves SSH autorizadas, cuentas del sistema desconocidas.
• Accesos de alojamiento — panel de control y copias de seguridad, que también dan acceso a los archivos.

El informe fechado que debe entregar a cada cliente

Desplace la tabla

Lo que usted conserva y las fuentes que citar