{"schema_version":"1.0","service":"Publicasta","type":"article","id":604,"slug":"adobe_commerce_magento_cve_2026_75650_patch_and_investigate","title":"CVE-2026-75650 en Adobe Commerce y Magento: parchea la tienda y después investígala","excerpt":"La vulnerabilidad CVE-2026-75650 ya está siendo explotada. Instalar el hotfix de Adobe cierra la vía crítica de ejecución remota sin autenticación, pero no demuestra que la tienda no haya sido comprometida antes de la corrección.","language":"es","default_language":"en","canonical_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=es","image":{"url":"https://publicasta.com/storage/projects/9/pages/604/2026/09/6d8f9035-e78e-4dcb-9cd1-e2e5c85e1517.webp","alt":"Ilustración editorial de ciberseguridad: una tienda en línea protegida por un parche y un escudo frente a amenazas de red"},"publisher":{"id":9,"slug":"cybersecurity","name":"Ciberseguridad sin pánico","url":"https://publicasta.com/cybersecurity"},"author":{"name":"Anton R"},"published_at":"2026-09-13T17:26:21+00:00","updated_at":"2026-09-13T17:26:21+00:00","content_markdown":"Adobe ha publicado un hotfix de emergencia para la CVE-2026-75650, una vulnerabilidad crítica de Adobe Commerce y Magento Open Source que puede permitir la ejecución remota de código sin autenticación. Adobe ha valorado el fallo con una puntuación CVSS de 10,0 y afirma que está siendo explotado en la práctica. El Australian Cyber Security Centre y la Cyber Security Agency de Singapur también han instado a las organizaciones afectadas a aplicar el parche de inmediato.\n\n ![Ilustración editorial de ciberseguridad: una tienda en línea protegida por un parche y un escudo frente a amenazas de red](https://publicasta.com/storage/projects/9/pages/604/2026/09/6d8f9035-e78e-4dcb-9cd1-e2e5c85e1517.webp)\n\n Para los comercios, la distinción importante está entre cerrar la vulnerabilidad y demostrar que la tienda no había sido comprometida. Lo primero es una tarea de mantenimiento de software. Lo segundo corresponde a la respuesta ante incidentes. Una tienda expuesta durante la ventana de explotación no puede considerarse limpia simplemente porque su estado de parcheo ahora sea correcto.\n\n Este problema es sustancialmente distinto de una actualización mensual rutinaria. Los informes públicos sitúan el comienzo de la explotación antes del hotfix de Adobe del 7 de septiembre, y el investigador que divulgó el problema afirma que los atacantes han ido modificando sus cargas mientras apuntaban a tiendas en funcionamiento. Por eso, la respuesta más segura es una secuencia breve y ordenada: identificar cada instalación afectada, aplicar la corrección del proveedor, conservar las pruebas, revisar el host y la aplicación, rotar los secretos que puedan haber quedado expuestos y solo entonces devolver la tienda a su funcionamiento normal.\n\n ## Qué afecta la CVE-2026-75650\n\n La CVE-2026-75650 es un fallo de neutralización incorrecta en un motor de plantillas. Adobe clasifica su impacto como ejecución arbitraria de código, indica que no se requiere autenticación y asigna al problema una puntuación base de 10,0 según CVSS 3.1. La puntuación refleja una vía de ataque accesible por red, sin privilegios previos ni interacción del usuario, y con un impacto potencialmente alto en la confidencialidad, la integridad y la disponibilidad.\n\n La familia de productos afectada incluye Adobe Commerce, Adobe Commerce B2B y Magento Open Source. El boletín de Adobe del 7 de septiembre enumera como afectadas las versiones 2.4.4 a 2.4.9 de Adobe Commerce, incluidas las versiones identificadas con el marcador de compilación 2026-August. También enumera como afectadas las versiones 1.3.3 a 1.5.3 de Adobe Commerce B2B y las versiones 2.4.6 a 2.4.9 de Magento Open Source. El aviso de Adobe es la autoridad para determinar la combinación exacta de paquete y compilación. Por tanto, el comercio debe comparar la instalación que está ejecutándose y el código desplegado con ese boletín, en lugar de basarse únicamente en el nombre de la familia de producto.\n\n El Australian Cyber Security Centre añade un detalle operativo relevante para el triaje: la explotación requiere que el endpoint `/graphql` esté expuesto. Eso no convierte en segura una tienda accesible desde Internet si GraphQL solo se ha desactivado como supuesto de desarrollo, se filtra de forma selectiva o sigue siendo accesible a través de un balanceador, una CDN, un nombre de host alternativo o una ruta antigua. Los equipos deben comprobar la exposición en el despliegue público real y también en cualquier entorno administrativo o de staging accesible desde fuera de la red de confianza.\n\n El software afectado se utiliza para operar tiendas en línea, procesar pedidos y conectarse con sistemas de pago, logística, analítica y otros servicios empresariales. Por eso, la vulnerabilidad no se limita al servidor web. Un compromiso exitoso podría abrir una vía hacia credenciales, tokens de integración, datos de la aplicación visibles para clientes, flujos de pedidos u otros servicios disponibles para el proceso de Commerce. El impacto empresarial probable dependerá de los privilegios de la cuenta de servicio, la configuración del host y los secretos almacenados o accesibles desde la aplicación.\n\n ## Por qué el momento cambia la respuesta\n\n Adobe publicó APSB26-146 el 7 de septiembre de 2026, con su nivel de prioridad más alto. El boletín de Adobe afirma que la compañía tiene conocimiento de explotación activa. Sansec, que publicó su investigación el 5 de septiembre, informó de ataques observados desde el 4 de septiembre y describió el problema, en el momento de la divulgación, como un zero-day de ejecución remota de código sin autenticación. La página de Sansec se actualizó el 13 de septiembre y señala que la corrección de emergencia se publicó tres días después de la primera explotación confirmada.\n\n Esas fechas establecen un límite de riesgo claro. Toda tienda que fuera accesible durante el periodo anterior al despliegue de la corrección necesita una evaluación de exposición, aunque no haya sufrido una interrupción visible. Un atacante que obtiene ejecución de código no tiene que desfigurar la portada ni interrumpir el proceso de compra para causar daños. Puede recopilar credenciales discretamente, instalar una web shell o un proceso en segundo plano, modificar la lógica de la aplicación, crear persistencia o utilizar la tienda como punto de paso. Una experiencia normal para el cliente no demuestra que el host esté limpio.\n\n La ausencia de una campaña pública confirmada contra una industria concreta tampoco debe interpretarse como tranquilidad para un comercio determinado. El aviso australiano indica que existe información sobre explotación activa, pero no señala que un sector específico esté siendo atacado. Ese lenguaje significa que el problema es amplio, no sectorial: cada organización que ejecute la plataforma afectada debe tomar su propia decisión sobre la exposición a partir de las versiones, la accesibilidad del endpoint, los registros y el historial de despliegues.\n\n ## La primera decisión: parchear o contener\n\n Si la tienda está afectada y el hotfix puede aplicarse de forma segura, la acción inmediata es seguir las instrucciones de instalación de Adobe para el hotfix de la CVE-2026-75650. Sansec identifica la corrección como el hotfix de Adobe `VULN-39341`, distribuido mediante un parche de Composer. El paquete exacto, la versión compatible y el método de despliegue deben obtenerse de las notas de lanzamiento de Adobe y del acuerdo de soporte del comercio. No hay que sustituir el parche por uno copiado de un foro no verificado ni asumir que un resultado normal de `security:patch-status` demuestra que esta corrección de emergencia está instalada.\n\n Antes de modificar producción, realiza una copia de seguridad protegida de los archivos relevantes de la aplicación, la configuración, las bases de datos y los registros. Registra la versión actual, el archivo de bloqueo de paquetes, el commit o identificador del artefacto desplegado, las versiones de PHP y del servidor web en ejecución, y la hora en que se tomó la instantánea. Conserva una copia fuera del host potencialmente comprometido. Así los investigadores tendrán algo con lo que comparar después del cambio y podrán distinguir un efecto secundario del parche de una intrusión preexistente.\n\n Si el hotfix no puede aplicarse de inmediato, reduce la exposición mientras preparas el despliegue. El aviso australiano recomienda actualizar a una versión que incluya el parche cuando sea necesario y, si no existe un parche para la versión utilizada, restringir y supervisar el acceso. En la práctica, esto puede implicar limitar temporalmente el acceso público a la tienda, restringir el endpoint vulnerable mediante un control confiable en el perímetro o poner el sitio en un modo de mantenimiento controlado. Una regla del Web Application Firewall puede reducir el tráfico oportunista, pero debe tratarse como una medida compensatoria, no como sustituto de la corrección de Adobe.\n\n Los equipos deben actuar con cautela con las ramas sin soporte. Sansec informa de que la cobertura probada del hotfix de Adobe está vinculada a las versiones compatibles con la compilación 2026-August y afirma que las ramas antiguas están afectadas, aunque Adobe no las ha verificado del mismo modo. Si una organización utiliza una versión fuera de soporte, la decisión responsable es involucrar al mantenedor de Commerce o a un proveedor cualificado de respuesta ante incidentes, probar una actualización compatible o un backport revisado y evitar un cambio de producción no probado mientras la tienda sigue procesando transacciones.\n\n ## Aplicar el parche no termina el trabajo\n\n El error operativo más frecuente ante una vulnerabilidad explotada activamente es detenerse en la comprobación de la versión. Un parche impide que la vía conocida vuelva a funcionar. No elimina el código escrito antes de la corrección, no deshace las credenciales copiadas ni muestra qué sistemas externos pudo utilizar un proceso comprometido.\n\n Comienza la investigación con una cronología precisa. Determina cuándo fue vulnerable cada instancia de Commerce expuesta a Internet, cuándo se podía acceder al endpoint `/graphql`, cuándo aparecieron los primeros indicios de solicitudes sospechosas, cuándo se aplicó el hotfix y si la aplicación se reinició o volvió a desplegarse después. Incluye los registros de CDN, WAF, proxy inverso, balanceador, servidor web, PHP-FPM, aplicación, sistema operativo, tareas programadas y auditoría en la nube. Usa una zona horaria coherente y conserva los archivos originales antes de filtrarlos o rotarlos.\n\n Busca evidencias en varias capas, en lugar de depender de una única firma. En el perímetro, revisa solicitudes inusuales a GraphQL, ráfagas que no se parezcan al tráfico normal de la tienda, agentes de usuario inesperados, errores repetidos y tráfico procedente de proveedores de alojamiento o redes que no estén asociadas con clientes legítimos. En la aplicación, examina cambios en plantillas, actividad relacionada con notificaciones de pagos fallidos, modificaciones inesperadas del CMS o de la configuración, nuevas cuentas de administrador, cambios en los permisos de integración y escrituras inusuales en ubicaciones de informes, medios o caché. En el host, busca procesos nuevos, tareas programadas nuevas, archivos de inicio modificados, archivos PHP inesperados y conexiones salientes que el proceso de Commerce normalmente no realizaría.\n\n El informe de Sansec describe un patrón en dos etapas en el que el atacante envenena código asociado al sistema de plantillas de Magento y después hace que Magento lo renderice mediante una ruta de notificación de pago fallido. Ese comportamiento general proporciona preguntas útiles para los defensores sin necesidad de intentar reproducir el exploit: ¿aumentaron de repente las notificaciones de pagos fallidos?, ¿cambiaron datos relacionados con plantillas fuera de un despliegue normal?, ¿realizó un worker de Commerce una escritura inusual en disco o una conexión saliente en ese momento? Una señal no constituye una prueba por sí sola. Los pagos rechazados, las extensiones y el mantenimiento programado pueden producir eventos parecidos, de modo que los hallazgos deben correlacionarse con los registros de despliegue y de solicitudes.\n\n No pegues registros sensibles, información de clientes, datos de sesión ni valores secretos en sistemas públicos de seguimiento de incidencias cuando busques ayuda. Comparte únicamente la evidencia mínima y saneada con el soporte de Adobe, un proveedor de respuesta ante incidentes de confianza o la autoridad nacional de ciberseguridad correspondiente. El aviso de Singapur remite a los administradores al boletín del proveedor y al registro del NVD, mientras que el aviso australiano ofrece a las organizaciones afectadas un canal de asistencia y notificación de incidentes.\n\n ## Secretos que pueden necesitar rotación\n\n Si la investigación encuentra explotación, o si la tienda no puede establecer que la explotación no ocurrió, rota las credenciales en un orden que limite la posibilidad de que el atacante siga operando. Primero protege las identidades y los sistemas administrativos utilizados para gestionar el host y la canalización de despliegue. Después rota la clave de cifrado de Commerce y todas las credenciales que puedan haber sido protegidas por ella, derivadas de ella o almacenadas junto a ella.\n\n El conjunto puede incluir contraseñas de administradores, tokens de integración REST, SOAP y GraphQL, secretos de clientes OAuth, credenciales de pasarelas de pago, contraseñas de bases de datos, claves SSH, claves de despliegue, credenciales de nube y claves de API de extensiones de terceros. Rótalas en su sistema emisor, no solo editando un valor en la configuración de Commerce. Por ejemplo, cambiar una credencial de pago dentro de la tienda no invalida la clave antigua en el proveedor de pagos; el proveedor debe emitir o revocar la credencial. El mismo principio se aplica a IAM de la nube, control de código fuente, monitorización, envíos y plataformas de marketing.\n\n La rotación debe ir acompañada de una revisión de acceso. Elimina integraciones que ya no se utilicen, reduce privilegios, acorta la vida de los tokens cuando sea práctico, confirma que las credenciales antiguas fueron revocadas y revisa los registros de autenticación para detectar usos posteriores al último despliegue legítimo. Si el mismo secreto se reutilizó en otro entorno, trata esos entornos como expuestos hasta que se comprueben. Una rotación que deja activa una copia olvidada en un host de staging o en una variable de CI solo crea una apariencia de recuperación.\n\n Cambiar únicamente la clave de cifrado de Commerce no es una respuesta completa. Puede proteger los valores futuros escritos con la clave nueva, pero no puede recuperar ni borrar nada que un atacante ya haya leído. Tampoco elimina una web shell, una tarea programada, una extensión modificada o una sesión robada. La rotación de credenciales debe realizarse después de conservar las pruebas y junto con la corrección del host, no en lugar de ellas.\n\n ## Quién debe actuar\n\n Los comercios que operen Adobe Commerce o Magento Open Source deben inventariar cada tienda, despliegue regional, sitio de staging, copia de recuperación ante desastres e instancia gestionada por un socio. Una empresa puede conocer su tienda principal y pasar por alto un sitio de marca inactivo, un portal interno de pedidos o un despliegue en la nube mantenido por una agencia. El inventario debe registrar la rama exacta del software, los nombres de host públicos, la exposición de GraphQL, el estado del parche, el responsable y la fecha de la última revisión verificada.\n\n Los proveedores de servicios gestionados y las agencias de comercio electrónico deben avisar a sus clientes, identificar las dependencias operativas compartidas y demostrar qué entornos fueron parcheados. La afirmación de un proveedor de que la plataforma está «actualizada» es menos sólida que un registro de despliegue que indique el hotfix, la instancia afectada y la hora de verificación. Los clientes deben solicitar esa evidencia y confirmar que los registros se conservaron si el servicio estuvo expuesto antes de la corrección.\n\n Los equipos de pagos, logística, atención al cliente y analítica deben participar cuando haya indicios de ejecución de código o exposición de secretos. Puede que sus sistemas no ejecuten Magento, pero quizá confíen en sus credenciales de API o acepten eventos de la tienda. La revisión de seguridad debe cubrir también tokens posteriores, secretos de firma de webhooks, cuentas de servicio y actividad inusual en los sistemas conectados.\n\n Los equipos de seguridad deben tratar el problema como gestión de vulnerabilidades y como respuesta ante incidentes. La gestión de vulnerabilidades responde si el software está protegido ahora. La respuesta ante incidentes responde si la organización ya había sido afectada. Mantener separadas ambas líneas de trabajo evita un fallo común: confundir un parche aplicado correctamente con una investigación completada correctamente.\n\n ## Qué no se debe deducir de las pruebas disponibles\n\n La CVE-2026-75650 es grave, pero los hechos no justifican cualquier afirmación posible. Los informes públicos confirman explotación activa y una vía crítica de ejecución sin autenticación. Por sí solos, no demuestran que todas las tiendas Magento hayan sido vulneradas, que los datos de pago de los clientes fueran robados en todas las víctimas ni que un grupo concreto sea responsable de toda la actividad observada. Los comercios deben evitar publicar esas conclusiones sin pruebas de su propio entorno.\n\n Del mismo modo, la presencia de una dirección IP sospechosa en un registro no demuestra que la solicitud tuviera éxito, y la ausencia de un indicador conocido no demuestra que fracasara. Los atacantes pueden cambiar de infraestructura y de carga útil. La detección debe combinar pruebas de solicitudes, efectos en la aplicación, cambios en archivos y procesos, registros de autenticación y momento del despliegue. Si persiste la incertidumbre, conserva el host y escala el caso para una revisión forense, en lugar de borrar inmediatamente los archivos sospechosos.\n\n La misma cautela se aplica a las mitigaciones. Una regla de CDN, una firma de WAF, un endpoint desactivado o una restricción de red pueden reducir el riesgo, pero cada control puede estar mal configurado o ser evadido mediante una ruta alternativa. Una medida compensatoria debe tener responsable, fecha de caducidad y una prueba de verificación. No debe convertirse en una excusa permanente para mantener una tienda sin soporte y sin parchear.\n\n ## Una secuencia práctica de respuesta\n\n Para una tienda que todavía está expuesta, la secuencia es lo bastante sencilla como para asignarla durante un incidente: identifica la instancia y su responsable, restringe el acceso si el hotfix no puede aplicarse de inmediato, conserva los registros y una copia de seguridad limpia, aplica el hotfix de Adobe para la CVE-2026-75650, verifica el despliegue a partir del artefacto en ejecución y vuelve a revisar la accesibilidad pública. No empieces borrando pruebas ni reconstruyendo desde una copia de seguridad no verificada.\n\n Para una tienda parcheada después del 4 de septiembre, trata el periodo anterior al parche como una ventana de investigación. Compara las solicitudes del perímetro con los registros de la aplicación, inspecciona cambios en plantillas y CMS, revisa las notificaciones de pagos fallidos, busca archivos y tareas programadas inesperados, examina las conexiones salientes y comprueba las autenticaciones administrativas y de integración. Si aparece cualquier indicio creíble de ejecución, aísla el host o traslada la tienda a un entorno conocido como limpio mientras continúa la respuesta.\n\n Para una tienda con compromiso confirmado o probable, conserva el sistema afectado, rota las credenciales en sus sistemas emisores, reconstruye a partir de artefactos confiables cuando corresponda, revisa los servicios conectados, notifica a los clientes o reguladores si lo exige la legislación aplicable y documenta las pruebas que respaldan la decisión final sobre el riesgo. El plan de recuperación debe incluir monitorización después de la restauración, porque parchear y reconstruir no garantiza que todas las cuentas dependientes hayan quedado protegidas.\n\n ## La lección útil para la seguridad del comercio electrónico\n\n La lección inmediata es aplicar el hotfix de Adobe. La más amplia tiene que ver con la diferencia entre una señal de parcheo correcto y un entorno limpio. Una tienda vulnerable puede convertirse en un problema de identidad y de sistemas de pago cuando la aplicación tiene acceso a secretos, flujos de clientes e integraciones automatizadas. El límite de seguridad no es solo el paquete de Commerce: también incluye el servidor, la canalización de despliegue, las extensiones, los endpoints, las credenciales y los servicios conectados.\n\n La CVE-2026-75650 muestra asimismo por qué una corrección de emergencia necesita un plan de preservación de pruebas. Cuando la explotación comienza antes de que exista un parche del proveedor, la organización debe hacer dos cosas en paralelo: reducir la superficie de ataque restante y determinar qué ocurrió durante la ventana de exposición. Ese enfoque produce un resultado más controlado y defendible que los cierres impulsados por el pánico o la afirmación tranquilizadora, pero sin respaldo, de que una versión parcheada significa que el incidente ha terminado.\n\n Para los comercios afectados, la decisión es clara. Aplica prioritariamente el hotfix compatible de Adobe, confirma que la corrección está presente en el despliegue activo e investiga cada instancia expuesta antes del parcheo. Si aparece actividad sospechosa, considera que los secretos pueden haber sido leídos hasta que los sistemas emisores correspondientes confirmen su rotación y revocación. La tienda podrá volver a la normalidad cuando el software esté corregido, el entorno haya sido examinado, las credenciales de los servicios conectados estén bajo control y las pruebas respalden esa conclusión.\n\n ## Fuentes\n\n - [Actualización de seguridad disponible para Adobe Commerce — APSB26-146](https://helpx.adobe.com/security/products/magento/apsb26-146.html), Adobe.\n- [Notas de lanzamiento del hotfix para CVE-2026-75650](https://experienceleague.adobe.com/en/docs/commerce-operations/tools/security/patches/vuln-39341), Adobe Experience League.\n- [Explotación activa de una vulnerabilidad de Adobe Commerce y Magento Open Source](https://www.cyber.gov.au/about-us/view-all-content/alerts-and-advisories/active-exploitation-of-adobe-commerce-and-magento-open-source-vulnerability), Australian Signals Directorate — Australian Cyber Security Centre.\n- [Explotación activa de una vulnerabilidad en productos de Adobe](https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-117/), Cyber Security Agency of Singapore.\n- [StyleSmuggler: zero-day de RCE de Magento y Adobe Commerce bajo ataque activo](https://sansec.io/research/stylesmuggler-0day), Sansec.\n- [Registro detallado de CVE-2026-75650](https://nvd.nist.gov/vuln/detail/CVE-2026-75650), National Institute of Standards and Technology.","available_translations":[{"language":"ar","title":"CVE-2026-75650 في Adobe Commerce وMagento: رقّع المتجر ثم حقّق في ما حدث","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=ar","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=ar","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=ar","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=ar"},{"language":"de","title":"CVE-2026-75650 in Adobe Commerce und Magento: Shop patchen und anschließend untersuchen","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=de","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=de","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=de","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=de"},{"language":"en","title":"CVE-2026-75650 in Adobe Commerce and Magento: Patch the Store, Then Investigate It","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=en","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=en","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=en","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=en"},{"language":"es","title":"CVE-2026-75650 en Adobe Commerce y Magento: parchea la tienda y después investígala","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=es","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=es","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=es","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=es"},{"language":"fr","title":"CVE-2026-75650 dans Adobe Commerce et Magento : corriger la boutique, puis l’enquêter","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=fr","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=fr","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=fr","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=fr"},{"language":"pl","title":"CVE-2026-75650 w Adobe Commerce i Magento: załataj sklep, a potem go zbadaj","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=pl","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=pl","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=pl","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=pl"},{"language":"ru","title":"CVE-2026-75650 в Adobe Commerce и Magento: сначала закройте уязвимость, затем расследуйте инцидент","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=ru","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=ru","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=ru","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=ru"},{"language":"zh","title":"Adobe Commerce 与 Magento 遭遇 CVE-2026-75650：先修补商店，再调查入侵迹象","html_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=zh","markdown_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=zh","json_url":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=zh","api_url":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=zh"}],"_links":{"self":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=es","api":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=es","html":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=es","canonical":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate?lang=es","markdown":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.md?lang=es","json":"https://publicasta.com/cybersecurity/adobe_commerce_magento_cve_2026_75650_patch_and_investigate.json?lang=es","channel":"https://publicasta.com/api/public/v1/channels/cybersecurity","channel_articles":"https://publicasta.com/api/public/v1/channels/cybersecurity/articles","search":"https://publicasta.com/api/public/v1/search","documentation":"https://publicasta.com/api-docs#reading-publicasta","openapi":"https://publicasta.com/api-docs/openapi.json","llms":"https://publicasta.com/llms.txt"}}