npm 12 deshabilita la instalación de scripts de forma predeterminada para reducir el riesgo de la cadena de suministro – CYBERDEFENSA.MX

GitHub tiene oficialmente anunciado el lanzamiento de npm versión 12 con los scripts de instalación deshabilitados de forma predeterminada, junto con los tokens de acceso granular (GAT) en desuso diseñados para evitar la autenticación de dos factores (2FA).

La subsidiaria propiedad de Microsoft señaló que los siguientes comportamientos de instalación de npm que solían ejecutarse automáticamente antes se han habilitado:

  • El valor predeterminado de enableScripts está desactivado, lo que significa que los scripts del ciclo de vida de la dependencia (es decir, preinstalación, instalación, postinstalación) y las compilaciones implícitas de node-gyp ya no se ejecutan a menos que se permitan explícitamente.
  • –allow-git tiene el valor predeterminado none, lo que significa que –allow-git tiene el valor predeterminado none: las dependencias de Git (directas o transitivas) ya no se resuelven a menos que se permitan explícitamente.
  • –allow-remote tiene el valor predeterminado none, lo que significa que las dependencias de URL remotas (por ejemplo, archivos tar https) ya no se resuelven a menos que se permitan explícitamente.

Para revisar y aprobar scripts confiables, ahora los usuarios deben ejecutar: «npm aprobar-scripts –allow-scripts-pending» y luego confirmar la lista de permitidos resultante en el archivo «package.json».

Ciberseguridad

Vale la pena señalar que estos cambios se obtuvieron una vista previa el mes pasado, y GitHub recomendó a los desarrolladores actualizar a npm 11.16.0 o más reciente, ejecutar el comando de instalación normal y revisar las advertencias mostradas.

La última versión de npm también introduce dos nuevos cambios:

  • Los GAT de npm configurados para omitir 2FA ya no podrán realizar acciones confidenciales de administración de cuentas, paquetes y organizaciones. Esto incluye crear o eliminar tokens, generar códigos de recuperación y cambiar la contraseña de la cuenta npm, el correo electrónico, el perfil o la configuración 2FA, cambiar el acceso a los paquetes, los mantenedores o la configuración de publicación confiable, y administrar la membresía de la organización y el equipo, así como sus concesiones de paquetes.
  • Los GAT de npm ya no conservarán la capacidad de publicar directamente. Su superficie de publicación se limitará a leer paquetes privados y realizar una publicación, donde un paquete solo se vuelve público después de la aprobación humana de 2FA.

Se espera que el primero de los dos cambios entre en vigor a principios de agosto de 2026. Mientras tanto, se recomienda dejar de usar tokens de derivación de 2FA para las operaciones antes mencionadas y realizarlas de forma interactiva con 2FA. El segundo cambio está previsto para enero de 2027.

«Para prepararse, planee trasladar la publicación automatizada a una publicación confiable (OIDC) o una publicación por etapas con un paso de aprobación humana, en lugar de un token de publicación de larga duración», dijo GitHub.

Ciberseguridad

El desarrollo llega como pnpm 11.10. presenta una nueva configuración «_auth» para configurar la autenticación del registro como un valor único estructurado con clave URL.

«El beneficio de seguridad es que la credencial y el host al que pertenece viajan juntos, y pnpm lee _auth solo desde el entorno o la configuración global, nunca desde los archivos de un proyecto», Socket explicado.

«Eso significa que un pnpm-workspace.yaml o .npmrc malicioso o comprometido dentro de un repositorio no puede apuntar un token válido a un host diferente. Un archivo de proyecto manipulado es una forma común en que los atacantes consiguen un punto de apoyo, y redirigir un token de registro es una ruta directa para robarlo, por lo que cerrar esa ruta elimina la exposición».

Los scripts en su página de pago son ahora un problema de PCI DSS – CYBERDEFENSA.MX

Un evaluador independiente de PCI probó Reflectiz según las nuevas reglas PCI DSS. Aquí está el veredicto: Vea la evaluación QSA completa aquí →

Cuando un cliente ingresa su número de tarjeta en su proceso de pago, su navegador ejecuta mucho más que su código. Etiquetas de análisis, un administrador de etiquetas, un widget de soporte, un iframe de pago: un proceso de pago moderno carga docenas de scripts de terceros y cualquiera de ellos puede convertirse en un skimmer.

Así funciona Magecart. Sansec ha contado más de 100.000 sitios afectados por el robo de información web y los ataques a la cadena de suministro. El Incumplimiento de British Airways en 2018 Solo expuso 380.000 transacciones y una multa que comenzó en £183 millones.

La parte peligrosa: el código malicioso suele llegar a través de un script que ya has aprobado. Los atacantes comprometen a un proveedor externo y la carga útil se aloja en un script que usted ha ejecutado durante meses. Nada parece nuevo. Lo que cambió es el comportamiento del script, no su presencia en la página.

PCI DSS v4.0.1 cierra esa brecha con dos requisitos, ahora plenamente vigentes. 6.4.3 dice inventariar cada script de página de pago, autorizarlo y demostrar su integridad. 11.6.1 dice detectar la manipulación del contenido de la página y los encabezados HTTP a medida que el navegador los recibe. Hecho a mano, a través de cientos de guiones que cambian constantemente, esto no escala. Los datos de Reflectiz muestran que aproximadamente el 30% de los guiones de las páginas de pago cambian en cualquier período de dos semanas.

Lo que encontró el QSA

Integrity360 Europe, un asesor de seguridad calificado de PCI y miembro de la mesa redonda de asesores ejecutivos globales de PCI SSC, revisó la plataforma Reflectiz PCI DSS con respecto a ambos requisitos y descubrió que puede respaldar eficazmente el cumplimiento. Destacaron tres cosas:

  • Observa el comportamiento, no solo los hash de los archivos. Una verificación de hash omite un intercambio silencioso del lado del proveedor. Reflectiz capta el guión en el momento en que comienza a buscar datos de la tarjeta.
  • Se implementa sin agentes. Sin cambios de código, sin fragmentos, dura días y sigue funcionando a través de refactorizaciones y migraciones de CMS.
  • Produce evidencia lista para QSA con un solo clic. Registro de auditoría completo por página, listo para su evaluación.

El SAQ una captura

Desde enero de 2025, los comerciantes pueden eliminar 6.4.3 y 11.6.1 del SAQ A solo si confirman que su sitio no es susceptible a ataques de script. ¿Redireccionamiento completo a tu procesador? Probablemente estés bien. ¿Incrustar un iframe de pago? Un script en la página principal aún puede secuestrar el pago antes de que los datos lleguen al marco seguro, y usted debe demostrar que no puede hacerlo. La pregunta frecuente número 1588 de PCI SSC apunta directamente a estos mismos controles.

Obtenga la evaluación completa

El documento técnico completo de Integrity360 Europe desglosa ambos requisitos línea por línea, el flujo de trabajo de monitoreo y exactamente lo que SAQ A exige ahora a los comerciantes de iframe.

Descargue el documento técnico →

¿Encontró interesante este artículo? Este artículo es una contribución de uno de nuestros valiosos socios. Síguenos en noticias de google, Gorjeo y LinkedIn para leer más contenido exclusivo que publicamos.

GitHub deshabilitará los scripts de instalación de npm de forma predeterminada para detener los ataques a la cadena de suministro

GitHub tiene anunciado lo que dijo son «cambios importantes» que llegarán a la versión 12 de npm, uno de los cuales desactiva los scripts de instalación de forma predeterminada para combatir las amenazas a la cadena de suministro de software.

Los cambios tienen como objetivo combatir las técnicas de ataque que abusan del comando «npm install» para desencadenar la ejecución de código malicioso utilizando ganchos del ciclo de vida de npm. «Npm install» se utiliza para descargar e instalar todas las dependencias necesarias para un proyecto Node.js. La versión 12 está prevista para su lanzamiento el próximo mes.

Al describir los scripts del ciclo de vida en el momento de la instalación como la «superficie de ejecución de código más grande en el ecosistema npm», GitHub dicho el comando «npm install» ejecuta scripts de cada dependencia transitiva, como resultado de lo cual un único paquete comprometido en cualquier parte del árbol de dependencias puede ejecutar código arbitrario en una máquina de desarrollo o en un ejecutor de CI.

Ciberseguridad

Al bloquear tales comportamientos, la idea es requerir la aprobación explícita del usuario antes de que la ejecución del código se inicie automáticamente durante la «instalación npm», en lugar de ser confiable de forma predeterminada. «Hacer la opción de ejecución de script cierra ese camino y lo mantiene a un comando de distancia para los paquetes en los que confía», dijo GitHub.

Los cambios se enumeran a continuación:

  • npm install ya no ejecutará scripts de preinstalación, instalación o postinstalación desde dependencias a menos que estén permitidos explícitamente en el proyecto.
  • npm install ya no resolverá las dependencias de Git, ya sean directas o transitivas, a menos que se permita explícitamente a través de –allow-git.
  • npm install ya no resolverá dependencias de URL remotas, como archivos tar https, a menos que se permita explícitamente a través de –allow-remote.

«Esto incluye compilaciones nativas de node-gyp (es decir, un paquete con un enlace.gyp y sin un script de instalación explícito aún se bloquea, porque npm ejecuta una reconstrucción implícita de node-gyp)», dijo la subsidiaria propiedad de Microsoft sobre los cambios en el comportamiento predeterminado de «allowScripts». «Preparar scripts desde git, las dependencias de archivos y enlaces se bloquean de la misma manera».

Al establecer «–allow-git» en «none» de forma predeterminada, la configuración cierra una ruta de ejecución de código donde el archivo de configuración .npmrc de una dependencia de Git utilizado podría anular el ejecutable de Git, incluso con –ignorar-scriptsuna marca que evita que los paquetes especificados en un archivo package.json ejecuten automáticamente scripts de ciclo de vida integrados durante el proceso de instalación.

Ciberseguridad

GitHub recomienda que los desarrolladores se preparen para estos cambios actualizando a npm 11.16.0 o posterior, ejecutando la instalación normal y revisando las advertencias mostradas.

«Utilice npm aprobar-scripts –allow-scripts-pending para ver qué paquetes tienen scripts, aprobar aquellos en los que confía y confirmar el paquete.json actualizado», agregó. «Después de eso, sólo los scripts que usted aprobó seguirán ejecutándose una vez que actualice. Todo lo que deje sin aprobar se detendrá».

A principios de este año, npm también introdujo «min-release-age», una configuración que le dice a npm que rechace cualquier versión de paquete publicada menos de un número específico de días como protección contra paquetes maliciosos recientemente publicados.

Complemento LiteSpeed ​​cPanel CVE-2026-48172 explotado para ejecutar scripts como root – CYBERDEFENSA.MX

Una vulnerabilidad de seguridad de máxima gravedad que afecta al complemento cPanel LiteSpeed ​​User-End ha sido objeto de explotación activa en la naturaleza.

El defecto, rastreado como CVE-2026-48172 (Puntuación CVSS: 10,0), se relaciona con un caso de asignación incorrecta de privilegios que un atacante podría abusar para ejecutar scripts arbitrarios con permisos elevados.

«Cualquier usuario de cPanel (incluido un atacante o una cuenta comprometida) puede explotar la función lsws.redisAble para ejecutar scripts arbitrarios como root», LiteSpeed dicho.

La vulnerabilidad afecta a todas las versiones del complemento entre 2.3 y 2.4.4. El complemento WHM de LiteSpeed ​​no se ve afectado. El problema se solucionó en la versión 2.4.5. Al investigador de seguridad David Strydom se le atribuye el mérito de descubrir e informar la falla.

LiteSpeed ​​señaló que «la vulnerabilidad está siendo explotada activamente», pero se abstuvo de compartir detalles adicionales. Ha compartido el siguiente indicador de compromiso:


grep -rE "cpanel_jsonapi_func=redisAble" /var/cpanel/logs /usr/local/cpanel/logs/ 2>/dev/null

Si ejecutar el comando «grep» antes mencionado no produce ningún resultado, el servidor no se ve afectado. Sin embargo, si hay algún resultado, se recomienda a los usuarios que examinen las direcciones IP de la lista y determinen si son legítimas y, en caso contrario, las bloqueen.

Ciberseguridad

Luego de una revisión de seguridad de sus complementos cPanel y WHM a raíz de la vulnerabilidad, LiteSpeed ​​dijo que parcheó vectores de ataque potenciales adicionales en ambos complementos y lanzó la versión 2.4.7 del complemento cPanel junto con la versión 5.3.1.0 del complemento WHM.

Se recomienda a los usuarios actualizar a la versión 5.3.1.0 del complemento LiteSpeed ​​WHM, que viene incluido con el complemento cPanel v2.4.7 o superior, para corregir la vulnerabilidad. Si la aplicación de parches inmediata no es una opción, se recomienda eliminar el complemento del usuario final ejecutando el siguiente comando:


/usr/local/lsws/admin/misc/lscmctl cpanelplugin --uninstall

El desarrollo se produce semanas después de que se identificara una vulnerabilidad crítica de cPanel (CVE-2026-41940, puntuación CVSS: 9,8) como explotada activamente por actores de amenazas desconocidos para implementar variantes de botnet Mirai y una cepa de ransomware llamada Sorry.