PHP2Shell es un tema de seguridad examinado recientemente que implica el riesgo de ejecución remota de código en servidores PHP. Se refiere principalmente a que los atacantes exploten entornos de ejecución de PHP vulnerables o componentes de aplicaciones relacionados para ejecutar código del lado del servidor sin autorización. PHP se utiliza ampliamente en sitios web, sistemas de gestión de contenido y diversos servicios de backend. Por ello, cuando las vulnerabilidades relacionadas afectan a servicios expuestos a internet, también pueden poner en riesgo la seguridad de los datos de los usuarios, la autenticación de identidad y los sistemas empresariales.
Para el sector de las criptomonedas, los riesgos de las vulnerabilidades de PHP no se limitan a los sitios web tradicionales. Las plataformas de trading de criptomonedas, los sitios web de proyectos, los servicios relacionados con billeteras y las aplicaciones Web3 también dependen de servidores, bases de datos y API para proporcionar gestión de cuentas, datos de mercado e interacciones de trading. Si estos sistemas presentan fallos de seguridad graves, los atacantes pueden acceder a credenciales confidenciales o manipular las interacciones de los usuarios mediante la intrusión en un servicio web, ampliando el impacto potencial del incidente de seguridad.
Sin embargo, los riesgos de seguridad de los servidores y la seguridad de los protocolos de cadena de bloques no son lo mismo. Una vulnerabilidad de PHP no descifra automáticamente las claves privadas de las billeteras, y un servidor comprometido por sí solo no basta para determinar que se hayan robado activos de los usuarios. Este artículo parte de los conceptos básicos de PHP2Shell y explica los principios técnicos de la ejecución remota de código, las posibles vías mediante las cuales las vulnerabilidades pueden afectar a las cuentas cripto y cómo las plataformas, los desarrolladores y los usuarios particulares pueden establecer protecciones de seguridad más eficaces.
PHP2Shell es una denominación examinada recientemente asociada a riesgos de seguridad de ejecución remota de código en PHP. El problema principal es que los atacantes pueden ejecutar código no autorizado mediante entornos de servidor vulnerables.
La ejecución remota de código (RCE) se diferencia de las vulnerabilidades web comunes. En casos graves, puede afectar a los privilegios del servidor, al acceso a bases de datos y a la lógica empresarial del backend.
Un servidor PHP comprometido no significa que se haya vulnerado la red de cadena de bloques ni las claves privadas de los usuarios. Que los activos cripto se vean afectados depende de las relaciones de permisos entre el servidor y los sistemas de autenticación de cuentas, firma de transacciones y custodia de activos.
En las plataformas de trading centralizadas, los riesgos potenciales pueden afectar a las sesiones de usuario, las credenciales de API, los datos de las cuentas y las interfaces empresariales. En el caso de las billeteras sin custodia, los usuarios deben prestar atención principalmente a páginas web maliciosas, interacciones de phishing y firmas de transacciones peligrosas.
Instalar parches de seguridad con rapidez, restringir los permisos del servidor, aislar las credenciales confidenciales, activar la autenticación multifactor y verificar de forma independiente las firmas de las transacciones son medidas importantes para reducir los riesgos relacionados.
PHP2Shell no es una única función de PHP ni un plugin de terceros. Es un término colectivo para dos vulnerabilidades de seguridad del núcleo de PHP: CVE-2026-109618 y CVE-2026-109619. Ambas vulnerabilidades se divulgaron el 21 de octubre de 2026. Las dos implican posibles problemas de seguridad en la forma en que PHP gestiona solicitudes excepcionales y estados de memoria, y ambas recibieron una puntuación CVSS v4.0 de 9,2, lo que las sitúa en la categoría de gravedad crítica.
A diferencia de las vulnerabilidades tradicionales de las aplicaciones PHP, PHP2Shell se produce dentro del entorno de ejecución de PHP. Esto significa que, incluso si los desarrolladores de sitios web han aplicado un filtrado estándar de las entradas de usuario y la propia aplicación no presenta fallos evidentes de inyección SQL o carga de archivos, los componentes subyacentes de PHP pueden seguir expuestos a ataques debido a estas vulnerabilidades.
El principal peligro de PHP2Shell es que los atacantes pueden no necesitar iniciar sesión previamente en el sitio web objetivo. Podrían tener la oportunidad de activar operaciones anómalas de memoria mediante solicitudes especialmente diseñadas y lograr posteriormente la ejecución remota de código. Las condiciones reales de explotación dependen de la versión de PHP, el modo de funcionamiento del servidor y la configuración de despliegue. No todos los sitios web PHP tienen exactamente la misma superficie de ataque.
| ID de vulnerabilidad | Problema principal | Impacto potencial en la seguridad |
|---|---|---|
| CVE-2026-109618 | Error de estado de memoria durante la gestión de excepciones por falta de memoria (OOM) | Ejecución remota de código |
| CVE-2026-109619 | Uso de referencias de memoria no válidas durante el procesamiento y la limpieza de solicitudes | Ejecución remota de código, divulgación de información de memoria |
PHP ya ha publicado versiones corregidas y recomienda claramente a los usuarios afectados que actualicen lo antes posible.

Para comprender los riesgos de PHP2Shell, primero es necesario entender cómo procesan los servidores PHP las solicitudes de los usuarios.
Cuando un usuario visita un sitio web, envía un formulario o llama a una API, el servidor web transfiere la solicitud correspondiente al entorno de ejecución de PHP para su procesamiento. PHP analiza los datos de la solicitud, ejecuta el código de la aplicación y devuelve el resultado al usuario. Durante este proceso, el servidor debe asignar memoria, conservar el estado de la solicitud y liberar los recursos relacionados cuando finaliza la solicitud.
En circunstancias normales, PHP debería limpiar de forma segura los recursos asignados incluso cuando falla el procesamiento de una solicitud. Sin embargo, las dos vulnerabilidades asociadas a PHP2Shell se producen precisamente durante la gestión de excepciones y la limpieza de memoria.
CVE-2026-109618 está relacionada con la gestión de falta de memoria. Cuando se produce un fallo de asignación de memoria mientras PHP analiza una solicitud, es posible que algunos datos internos aún no se hayan inicializado por completo. Si una rutina de limpieza posterior trata incorrectamente estos datos como un estado válido, puede producirse corrupción de memoria.
CVE-2026-109619 implica referencias de memoria no válidas durante el procesamiento de solicitudes. Cuando ciertos recursos ya se han liberado, pero se conservan los punteros o estados relacionados, operaciones posteriores pueden acceder incorrectamente a regiones de memoria que ya no son válidas. Este tipo de problema se conoce habitualmente como uso después de liberación.
Cuando se cumplen condiciones específicas de explotación, los atacantes pueden utilizar estos errores de memoria para alterar el flujo de ejecución normal del programa y hacer que el servidor ejecute código no autorizado. Por lo general, los privilegios de ejecución están limitados por los permisos de la cuenta de trabajo de PHP. Sin embargo, si los permisos del servidor se configuran de forma inadecuada, los atacantes aún pueden acceder a archivos confidenciales o intentar ampliar su control.
Es importante tener en cuenta que los riesgos reales varían según los modos de despliegue. Por ejemplo, se han validado algunas vías de explotación que implican Apache mod_php, mientras que las condiciones de activación y la posibilidad de explotación de otros entornos, como PHP-FPM, no son exactamente las mismas.
PHP2Shell afecta a varias versiones de PHP que siguen en uso. El 21 de octubre de 2026, PHP publicó las actualizaciones de seguridad correspondientes para corregir las dos vulnerabilidades críticas.
A fecha del 27 de octubre de 2026, las principales versiones afectadas y corregidas son las siguientes:
| Rama de PHP | Versiones afectadas | Versión corregida |
|---|---|---|
| PHP 8.2 | Anteriores a 8.2.35 | 8.2.35 |
| PHP 8.3 | Anteriores a 8.3.36 | 8.3.36 |
| PHP 8.4 | Anteriores a 8.4.27 | 8.4.27 |
| PHP 8.5 | Anteriores a 8.5.12 | 8.5.12 |
Las versiones anteriores de PHP también pueden verse afectadas por problemas relacionados. Para las versiones que ya no reciben mantenimiento oficial, los desarrolladores deben confirmar si los distribuidores de sistemas operativos o los servicios de mantenimiento comercial proporcionan parches de seguridad, en lugar de basarse únicamente en los números de versión para evaluar el riesgo.
Además, algunas distribuciones de Linux pueden corregir vulnerabilidades mediante la retroportación de parches de seguridad, aplicando la corrección mientras mantienen el número de versión original. Por lo tanto, para determinar si un servidor es seguro, es necesario comprobar tanto la versión real de compilación del paquete como los avisos de seguridad del proveedor.
En cuanto a los métodos de despliegue, PHP2Shell puede afectar a Apache mod_php, PHP-FPM, php-cgi, FrankenPHP y otros entornos de ejecución de PHP. Sin embargo, las condiciones de explotación difieren entre los distintos modos. Los administradores de servidores deben evaluar el impacto según su propia pila tecnológica, en lugar de asumir que todos los sitios web que utilizan PHP pueden verse comprometidos mediante el mismo método de ataque.
Las plataformas de trading de criptomonedas suelen estar formadas por múltiples sistemas independientes, incluidos el inicio de sesión de usuarios, la verificación de identidad, la coincidencia de operaciones, la gestión de cuentas, la custodia de activos, la aprobación de retiros y el control de riesgos.
PHP2Shell afecta directamente a servidores PHP vulnerables, no a la propia red de cadena de bloques. Si el sitio web público o el servicio de backend de una plataforma utiliza una versión afectada de PHP, los atacantes pueden intentar acceder al servidor relacionado mediante la vulnerabilidad.
Una vez comprometido un servidor, los atacantes pueden buscar información de conexión a bases de datos, datos de sesión de usuarios, credenciales de API u otras configuraciones confidenciales. Si esta información permite acceder a un sistema de gestión de cuentas, puede aumentar el riesgo de divulgación de información de cuentas o suplantación de identidad.
Por ejemplo, una plataforma de servicios cripto puede utilizar PHP para desarrollar interfaces de gestión de cuentas y almacenar en su servidor credenciales internas de API con elevados privilegios. Si un atacante obtiene acceso al servidor mediante ejecución remota de código, puede intentar leer estas credenciales y utilizarlas para llamar a interfaces empresariales que no deberían ser accesibles públicamente.
Sin embargo, esto no significa que los atacantes puedan retirar directamente todos los activos de los usuarios. Las plataformas de trading maduras suelen aislar de los servicios web públicos capacidades críticas como la custodia de fondos, la firma de transacciones, la aprobación de retiros y la autenticación de cuentas. También utilizan controles de permisos y verificaciones de riesgo independientes.
Por lo tanto, el impacto real de PHP2Shell en las cuentas cripto depende de los permisos del servidor, el aislamiento de la red interna, la gestión de credenciales confidenciales y los mecanismos de aprobación de operaciones con activos. Una vulnerabilidad en un sitio web público no significa que el sistema principal de custodia de activos ya se haya vulnerado.
PHP2Shell no puede descifrar directamente las claves privadas de las billeteras de cadena de bloques ni alterar los mecanismos de seguridad criptográfica de una cadena de bloques.
En las billeteras sin custodia, como MetaMask, las claves privadas suelen gestionarse mediante software de billetera local o dispositivos de hardware. Si una clave privada nunca se ha cargado en un servidor PHP vulnerable, la ejecución remota de código en ese servidor por sí sola normalmente no puede obtenerla directamente.
Sin embargo, una vulneración del servidor aún puede afectar a los usuarios de billeteras de otras maneras.
Por ejemplo, después de obtener el control del sitio web oficial de un proyecto Web3, un atacante puede modificar la página de frontend para inducir a los usuarios a conectar sus billeteras y firmar transacciones maliciosas. Si los usuarios no verifican cuidadosamente los detalles de la transacción, pueden autorizar sin saberlo transferencias de tokens o realizar operaciones peligrosas.
Otro riesgo afecta a los servicios relacionados con billeteras. Algunas aplicaciones Web3 dependen de servidores para proporcionar datos de transacciones, solicitudes de firma, configuraciones de usuario o información de operaciones entre cadenas. Si estos datos se modifican después de una vulneración del servidor, los usuarios pueden recibir parámetros de transacción incorrectos o indicaciones de interacción maliciosas.
Por lo tanto, es necesario distinguir entre dos tipos de problemas de seguridad:
La exposición de una clave privada significa que un atacante obtiene directamente el material de clave necesario para controlar los activos de una billetera. La firma maliciosa puede producirse sin exposición de la clave privada, cuando un usuario aprueba activamente una transacción con permisos peligrosos.
Para los usuarios de billeteras sin custodia, este último suele ser el riesgo indirecto más importante que deben vigilar.
PHP2Shell, la inyección SQL, las secuencias de comandos entre sitios (XSS) y las vulnerabilidades de carga de archivos pueden amenazar la seguridad de los sitios web, pero sus orígenes técnicos y métodos de ataque difieren significativamente.
La inyección SQL suele producirse cuando una aplicación no gestiona correctamente los parámetros de consultas de bases de datos. Los atacantes pueden utilizar entradas maliciosas para alterar la lógica de las consultas a la base de datos. XSS implica principalmente una gestión inadecuada de la salida de páginas web, que puede provocar la ejecución de scripts maliciosos en el navegador del usuario.
Lo que distingue a PHP2Shell es que la vulnerabilidad se produce en el entorno de ejecución del núcleo de PHP. Incluso si una aplicación utiliza un filtrado de entradas y una verificación de permisos relativamente exhaustivos, los fallos de seguridad de la memoria en los componentes subyacentes aún pueden proporcionar un punto de entrada para los ataques.
| Dimensión de comparación | PHP2Shell | Inyección SQL | XSS |
|---|---|---|---|
| Ubicación de la vulnerabilidad | Entorno de ejecución de PHP | Interacción entre la aplicación y la base de datos | Procesamiento de contenido web |
| Riesgo principal | Ejecución remota de código, divulgación de memoria | Divulgación y manipulación de datos | Ejecución de scripts maliciosos en el navegador |
| ¿Puede afectar al servidor? | Sí | Depende de los permisos de la base de datos y del sistema | Por lo general, afecta al navegador |
| Medidas de protección principales | Actualizar PHP, aislamiento de seguridad | Consultas parametrizadas, mínimo privilegio | Codificación de salida, política de seguridad de contenido |
| Impacto en los usuarios cripto | Impacto indirecto en la seguridad de cuentas y servicios | Puede exponer datos de cuentas | Puede inducir operaciones peligrosas con billeteras |
Esto también demuestra que la seguridad de un sitio web no puede depender únicamente de la revisión del código a nivel de aplicación. Los entornos de ejecución de los servidores, las dependencias y las configuraciones del sistema también requieren mantenimiento continuo.
Para las plataformas cripto y los proyectos Web3 que utilizan PHP, la medida principal para prevenir PHP2Shell es instalar rápidamente los parches de seguridad oficiales y confirmar que todos los servicios PHP actualmente en funcionamiento se han actualizado.
Dado que las vulnerabilidades se producen en el entorno de ejecución del núcleo de PHP, no puede considerarse una solución completa limitarse a modificar el código empresarial del sitio web, añadir filtros de entrada o implementar reglas de firewall convencionales. PHP ha indicado claramente que actualizar a una versión corregida es la solución fiable. Además de actualizar las versiones, las plataformas deben centrarse en las siguientes áreas.
Realizar una revisión exhaustiva de los servicios PHP. Además de los sitios web públicos, se deben comprobar los backends administrativos, las API internas, los entornos de prueba, los proyectos heredados y los componentes de terceros. Algunos servicios con menor mantenimiento pueden seguir ejecutando versiones antiguas de PHP y convertirse en puntos de entrada a la red interna.
Aplicar el principio de mínimo privilegio. Los procesos de trabajo de PHP no deben tener privilegios innecesarios de administrador del sistema ni acceso directo a claves privadas de billeteras, sistemas principales de firma o cuentas de bases de datos con elevados privilegios. Incluso si un atacante obtiene acceso a un servicio web, los recursos a los que pueda acceder deben seguir estando restringidos.
Aislar los sistemas críticos de operaciones con activos. Los servicios de cuentas, la custodia de fondos, la aprobación de retiros y la firma de transacciones deben tener límites de permisos independientes. Para las operaciones que implican transferencias de activos, también se deben utilizar autenticación multifactor, límites de transacción, detección de comportamientos anómalos y aprobación independiente para reducir el riesgo.
Reforzar la gestión de credenciales y registros. Las claves de API, las contraseñas de bases de datos y otras configuraciones confidenciales deben almacenarse mediante mecanismos especializados de gestión de claves y rotarse periódicamente. En los servidores que se sospeche que han sido comprometidos, se deben comprobar procesos anómalos, cambios de archivos, conexiones de red y registros de operaciones de cuentas.
Establecer un mecanismo de actualización continua. PHP2Shell demuestra que pueden surgir problemas graves de seguridad en los entornos de ejecución subyacentes en un periodo breve. Los equipos de proyecto deben supervisar continuamente los avisos de seguridad y establecer procesos para la clasificación de vulnerabilidades, las pruebas de parches y las actualizaciones de emergencia.
Para los sistemas que no pueden actualizarse de inmediato, medidas como las restricciones de acceso y el aislamiento de servicios pueden reducir la exposición. Sin embargo, estas medidas no pueden sustituir a los parches de seguridad.
Para los usuarios particulares, PHP2Shell es una vulnerabilidad del lado del servidor que, por lo general, no puede solucionarse mediante acciones en un dispositivo personal. Por ello, los usuarios deben prestar más atención a la seguridad de los proveedores de servicios y reducir los riesgos indirectos que puede generar una vulneración del servidor.
Prioriza las plataformas de trading y los servicios de billetera con mecanismos de seguridad completos, y activa la autenticación multifactor en las cuentas de trading. Para operaciones que impliquen grandes cantidades de activos, funciones como las listas de direcciones de retiro permitidas, la verificación independiente y las notificaciones de seguridad pueden ayudar a reducir posibles pérdidas tras una suplantación de cuenta.
No introduzcas la frase semilla ni la clave privada de tu billetera en el sitio web de un proyecto. Aunque un sitio web haya funcionado normalmente durante mucho tiempo, puede modificarse de forma maliciosa después de una vulneración del servidor.
Al conectarte a una aplicación Web3, verifica el dominio del sitio web, el destinatario de la transacción y los detalles de autorización. No apruebes solicitudes de firma desconocidas basándote únicamente en las indicaciones de la página web o en el nombre de un proyecto.
Minimiza el uso de claves de API con elevados privilegios. Si necesitas gestionar una cuenta de trading mediante una API, configura los permisos mínimos necesarios para el uso previsto y evita activar permisos de retiro cuando no sean necesarios.
Cuando una plataforma de trading o un proyecto Web3 publique un anuncio sobre un incidente de seguridad, confirma primero el alcance del impacto a través de sus canales de confianza. No hagas clic en enlaces desconocidos que afirmen proporcionar migración urgente de activos, verificación de billeteras o compensación de seguridad.
Estas medidas no pueden eliminar todos los riesgos del lado del servidor, pero pueden reducir la posibilidad de que los atacantes afecten posteriormente a los activos de los usuarios mediante suplantación de identidad, páginas de phishing o firmas maliciosas.
Después de que PHP2Shell se divulgara el 21 de octubre de 2026, instituciones de investigación de seguridad y proveedores de servicios de infraestructura publicaron sucesivamente análisis de riesgos y recomendaciones de mitigación. A fecha del 27 de octubre de 2026, algunas organizaciones de seguridad habían informado de intentos de ataque dirigidos a las vulnerabilidades relacionadas. Sin embargo, en algunas intrusiones presuntamente exitosas, sigue sin estar clara la relación entre el vector de ataque y los CVE específicos.
Por ejemplo, Unit 42 de Palo Alto Networks informó de una campaña de intrusión presuntamente relacionada con PHP2Shell. Sin embargo, tras una investigación adicional, retiró el 25 de octubre su evaluación anterior sobre la relación entre la intrusión inicial y una vulnerabilidad específica, indicando que no podía confirmar si los atacantes utilizaron PHP2Shell para obtener acceso inicial.
Esta evolución demuestra que es necesario distinguir entre la posibilidad técnica de explotación de una vulnerabilidad, los intentos de ataque reales y las intrusiones exitosas verificadas. Estas tres situaciones no son exactamente iguales.
Para el sector cripto, la gravedad de PHP2Shell por sí sola no basta para concluir que una plataforma de trading importante haya sido atacada. Tampoco puede atribuirse a esta vulnerabilidad cada incidente de robo de cuentas del que se informe en el mercado.
No obstante, PHP2Shell afecta a tecnología del lado del servidor ampliamente utilizada y conlleva un grave riesgo de ejecución remota de código. Por ello, los desarrolladores y proveedores de servicios deben seguir adoptando medidas de mitigación oportunas.
PHP2Shell es un término colectivo para dos vulnerabilidades críticas de seguridad del núcleo de PHP divulgadas en octubre de 2026: CVE-2026-109618 y CVE-2026-109619. Los principales riesgos surgen de posibles fallos de seguridad en la forma en que PHP gestiona solicitudes excepcionales y la limpieza de memoria. En condiciones específicas, los atacantes pueden lograr la ejecución remota de código no autorizado.
Para el sector cripto, el impacto de PHP2Shell se concentra principalmente en las capas de servicios web, sistemas de cuentas e infraestructura de backend. Después de comprometer un servidor, los atacantes pueden intentar acceder a credenciales confidenciales, manipular interfaces empresariales o modificar páginas orientadas a los usuarios. Sin embargo, esto no significa que se haya vulnerado el protocolo de cadena de bloques ni que las claves privadas de las billeteras sin custodia se expongan automáticamente.
Este incidente demuestra además que la seguridad de los activos cripto depende no solo de las cadenas de bloques y los contratos inteligentes, sino también de la fiabilidad de la infraestructura tradicional de internet. La gestión de parches de servidores, el aislamiento de permisos, la autenticación de cuentas y la verificación de firmas de transacciones son componentes importantes de un sistema de seguridad integral.
Para los desarrolladores, actualizar rápidamente las versiones afectadas de PHP es la máxima prioridad. Para los usuarios particulares, proteger las credenciales de las cuentas, autorizar cuidadosamente las transacciones de billeteras y supervisar los anuncios de seguridad de fuentes fiables siguen siendo medidas básicas para reducir el riesgo.
PHP2Shell es un término colectivo para las dos vulnerabilidades del núcleo de PHP CVE-2026-109618 y CVE-2026-109619. Implican problemas de gestión de solicitudes excepcionales y de seguridad de memoria que pueden provocar ejecución remota de código.
Ambas vulnerabilidades tienen una puntuación CVSS v4.0 de 9,2, lo que las sitúa en la categoría de gravedad crítica. En condiciones específicas de despliegue, atacantes no autenticados pueden explotar las vulnerabilidades para ejecutar código del lado del servidor.
No provocará automáticamente el robo de activos de las billeteras. El impacto real depende de si el servidor tiene acceso a credenciales confidenciales, claves privadas o sistemas de firma de transacciones, así como de si el atacante puede eludir los controles de seguridad relacionados.
Las principales versiones afectadas incluyen las anteriores a PHP 8.2.35, 8.3.36, 8.4.27 y 8.5.12, respectivamente. Las ramas anteriores de PHP también pueden verse afectadas y deben comprobarse con las actualizaciones de seguridad proporcionadas por los distribuidores correspondientes.
PHP2Shell afecta al entorno de ejecución de PHP del lado del servidor, mientras que las vulnerabilidades de contratos inteligentes se producen en el código de los contratos o en la lógica empresarial desplegada en una cadena de bloques. Ambas pueden afectar indirectamente a la seguridad de los activos cripto, pero sus orígenes técnicos son diferentes.
Algunas vías de ataque validadas no requieren que el atacante inicie sesión previamente en el sitio web. Sin embargo, las condiciones específicas de explotación dependen de la versión de PHP, el modo de funcionamiento del servidor y la configuración de despliegue.
Si la clave privada de la billetera se almacena únicamente de forma local por el usuario, PHP2Shell normalmente no puede obtenerla directamente. Sin embargo, un sitio web Web3 comprometido puede inducir a los usuarios a ejecutar transacciones maliciosas, por lo que las solicitudes de firma deben verificarse cuidadosamente.
Instala los parches de seguridad proporcionados por PHP o el distribuidor del sistema operativo y confirma que los servicios PHP correspondientes hayan recargado el entorno de ejecución actualizado. Los firewalls o el filtrado de entradas por sí solos no pueden sustituir la mitigación.
A fecha del 27 de octubre de 2026, no existe suficiente evidencia pública fiable que demuestre que alguna plataforma importante de trading de criptomonedas haya sido comprometida con éxito debido a PHP2Shell. La existencia de una vulnerabilidad no puede equipararse directamente a pérdidas reales de activos.
Activa la autenticación multifactor, protege las credenciales de API de tus cuentas, no proporciones frases semilla de billeteras a sitios web, verifica las firmas de transacciones Web3 y supervisa los anuncios de seguridad de las plataformas a través de canales de confianza.
* La información no pretende ser ni constituye un consejo financiero ni ninguna otra recomendación de ningún tipo ofrecida o respaldada por Gate.
* Este artículo no se puede reproducir, transmitir ni copiar sin hacer referencia a Gate. La contravención es una infracción de la Ley de derechos de autor y puede estar sujeta a acciones legales.





