Cómo eliminar el código oculto de ChatGPT y otros LLM

A medida que los modelos de lenguaje grandes (LLM) generan cada vez más código funcional y se integran en los canales de desarrollo y las pilas de agentes, existe un riesgo creciente de que hidden or malicioso Las instrucciones, ya sea integradas en las salidas del modelo, inyectadas a través de páginas web o complementos de terceros, o introducidas durante el entrenamiento del modelo, pueden provocar un comportamiento inseguro cuando se ejecuta ese código.

Según informes de usuarios que circulan en las comunidades de desarrolladores, un desarrollador de software experimentó una pérdida de datos catastrófica, aproximadamente Se eliminaron 800 GB de archivos, incluyendo la toda la aplicación CursorAI en sí — después de ejecutar el código generado con la ayuda de Gemini 3 mientras trabajaba dentro de la IDE de CursorAIA medida que los desarrolladores dependen cada vez más de los LLM para la generación de código, las consecuencias de los scripts no revisados o inseguros se vuelven más graves.

Por lo tanto, es muy importante saber cómo detectar y eliminar los códigos peligrosos generados por LLM.

¿Qué es el “código oculto” en el contexto de ChatGPT y LLMs?

¿Qué quiere decir la gente con “código oculto”?

"Código oculto" es un término general que utilizan los desarrolladores para describir cualquier instrucción incrustada o contenido ejecutable dentro del texto (o archivos) que un LLM ingiere o emite, incluyendo:

Instrucciones de estilo rápido incrustado dentro del contenido del usuario (por ejemplo, “Ignorar instrucciones anteriores…” oculto en un PDF).
Personajes invisibles o espacios de ancho cero utilizados para ocultar tokens o romper suposiciones de tokenización.
Cargas útiles codificadas (base64, URL codificada, incrustaciones esteganográficas dentro de imágenes o documentos).
HTML/JS oculto o bloques de script incluidos en contenido formateado que podrían ser interpretados por renderizadores posteriores.
Metadatos o anotaciones (comentarios de archivos, capas ocultas en PDF) que instruyen a los sistemas de recuperación o al modelo.
Comportamientos implícitos que surgen del código generado que utiliza API peligrosas (por ejemplo, eval, exec, subprocess, o llamadas de red/sistema), incluso cuando la intención no sea explícitamente maliciosa.
Instrucciones inyectadas con indicaciones que hacen que el modelo genere código que incluye comandos ocultos o lógica similar a una puerta trasera porque un atacante diseñó el mensaje o el contexto.

Estos vectores de ataque a menudo se denominan inyección inmediata or inyección indirecta inmediata Cuando el objetivo es cambiar el comportamiento del modelo, la comunidad de seguridad ahora considera la inyección inmediata como una vulnerabilidad LLM fundamental y OWASP la ha formalizado como una categoría de riesgo LLM.

¿En qué se diferencia del malware normal o XSS?

La diferencia es la semántico Capa: la inyección de prompts se dirige al comportamiento de seguimiento de instrucciones del modelo, en lugar del sistema operativo host o el motor de renderizado del navegador. Dicho esto, el HTML o script oculto que se ejecuta en un renderizador web sigue siendo un ataque ejecutable (similar a XSS); tanto la capa semántica como la de ejecución deben protegerse. Los líderes de la industria e investigadores han calificado la inyección de prompts como un "desafío de seguridad fronterizo" y siguen publicando estrategias de mitigación.

¿Por qué LLM puede producir código oculto o peligroso?

Comportamiento del modelo, datos de entrenamiento y contexto de instrucción

Los LLM están entrenados para producir continuaciones plausibles según el contexto y las instrucciones. Si el contexto contiene señales adversas, o si un usuario solicita al modelo código que realice acciones potentes, este puede generar código que incluya un comportamiento sutil o activo.

Los LLM producen código plausible pero inseguro

Los LLM están optimizados para la fluidez y la utilidad, no para la seguridad ante la presencia de efectos secundarios destructivos. Generarán con gusto un resumen conciso. rm -rf /path/to/dir or shutil.rmtree() Llaman cuando se les pide que "limpien", y como sus respuestas suelen expresarse con seguridad, los usuarios pueden copiar y correr sin un escrutinio adecuado. Este problema de "alucinación segura" es la razón por la que solicitudes aparentemente inocuas se vuelven peligrosas.

Automatización de flujos de trabajo de ofuscación

Los actores de amenazas ahora automatizan la ofuscación de código mediante el encadenamiento de llamadas LLM: un modelo genera una carga útil, otro la reelabora para evitar la detección de firmas, y así sucesivamente. Los informes de amenazas de la industria y los análisis de proveedores de 2025 documentan esta «ofuscación asistida por IA» como una técnica emergente.

¿Cómo se puede detectar código oculto dentro de las salidas del modelo?

Lista de verificación de triaje rápido

Escanear en busca de Unicode invisible o inusual (uniones de ancho cero, espacios de ancho cero, marcas de orden de bytes, homoglifos no ASCII).
Ejecutar análisis estático/análisis AST para identificar el uso de API potentes (eval, exec, subprocess, os.system, llamadas reflexivas).
Busque cargas útiles codificadas (base64, blobs hexadecimales, cadenas largas repetidas o contenido comprimido).
Compruebe si hay patrones de ofuscación (concatenación de cadenas que construye nombres de API, aritmética de caracteres, chr() cadenas).
Utilice el análisis semántico para confirmar si el código realmente realiza E/S, operaciones de red o mutación del sistema de archivos.

Detección de patrones estáticos (rápida, primera línea)

Análisis y análisis sintáctico teniendo en cuenta el lenguaje. Analizar inmediatamente la salida generada en bloques de código y prosa. Ejecutar formateadores y linters (Black/Prettier, pylint, eslint). Las reglas de lint deben marcar el uso de eval, exec, rm -rf, llamadas de subprocesos sin procesar o tuberías de shell que construyen comandos dinámicamente.
Escáneres de patrones de cadenas y tokens. Búsqueda de tokens y patrones de alto riesgo: sudo, rutas absolutas como /home/, C:\, rm -rf, shutil.rmtree, subprocess.Popen, blobs base64 en línea, cadenas largas no interpretables y shebangs que cambian el contexto del intérprete.
Escaneo secreto y verificación de procedencia. Detecta credenciales codificadas, URL que apuntan a registros no confiables o código que extrae paquetes dinámicamente de fuentes arbitrarias.

El análisis estático detecta rápidamente muchos problemas obvios y es económico de ejecutar como parte de una puerta CI.

Detección semántica y contextual (más profunda)

Análisis de intenciones. Utilice un modelo secundario o un motor de reglas para clasificar la intención del código generado: ¿es "lectura", "escritura", "eliminación", "red", "instalación"? Cualquier acción categorizada como "eliminación/escritura" debería activar la escalada.
Análisis del flujo de datos. Analice el código para detectar si las rutas no validadas o proporcionadas por el usuario pueden acceder a APIs destructivas. Por ejemplo, si una variable derivada de una salida LLM o un archivo remoto se concatena posteriormente en un comando de shell, márquelo.
Correlación de procedencia. Mantenga un registro completo de la conversación, el mensaje del sistema y las páginas de contexto. Si los resultados sospechosos se correlacionan con un documento externo o una llamada a un complemento, esto puede indicar una inyección de mensaje o un contexto corrupto.

Detección dinámica y de comportamiento (la más confiable)

Ejecución de sandbox con monitorización. Ejecute el código generado en un entorno efímero con restricciones estrictas, sin red, sin montajes de host y con filtrado de llamadas al sistema (seccomp). Supervise la actividad del sistema de archivos, los intentos de llamadas de red, la generación de procesos y las E/S inusuales.
Prueba canaria. Antes de ejecutarlo en datos reales, ejecute el código contra directorios sintéticos que contengan archivos centinela; controle si hay eliminaciones o sobrescrituras.
Heurística del comportamiento. Busque bucles que atraviesen directorios principales, operaciones recursivas sin comprobaciones de profundidad o patrones de cambio de nombre que puedan dañar muchos archivos (por ejemplo, escribir repetidamente el mismo nombre de archivo).
El análisis dinámico es la única forma de detectar cargas útiles que están ofuscadas, retrasadas o se activan solo en tiempo de ejecución.

¿Cómo se debe eliminar o neutralizar el código oculto antes de ejecutar las salidas de LLM?

Eliminación defensiva vs. alteración de la semántica

Hay dos objetivos al “eliminar código oculto”:

Sanitización — Eliminar contenido que claramente no sea código o que sea sospechoso (Unicode invisible, caracteres de ancho cero, cargas útiles base64 añadidas). Esto no debería alterar la lógica benigna prevista.
Neutralización — para cualquier cosa que ejecute o llame a servicios externos, deshabilite esas llamadas o conviértalas en operaciones no operativas hasta que se verifiquen.

Siempre prefiero neutralización + revisión Eliminación a ciegas: eliminar partes del código arbitrariamente puede producir un comportamiento defectuoso o inesperado. En su lugar, reemplace las construcciones sospechosas con fragmentos explícitos registrados que fallen de forma segura (generando excepciones o devolviendo valores predeterminados seguros).

Paso 1: Tratar el código generado como datos no confiables

Nunca ejecute código directamente desde ChatGPT (ni ningún LLM) sin pasarlo por un proceso de eliminación y endurecimiento. Este proceso debe implementarse mediante políticas y automatizarse en CI/CD.

Paso 2: Extraer y canonizar el código

Normalizar el texto y eliminar caracteres de ancho cero: Elimine caracteres como U+200B, U+200C, U+200D, U+FEFF y otros puntos de código de formato de ancho cero. Registre lo eliminado para su auditoría. Este paso elimina muchas codificaciones ocultas utilizadas para ocultamiento visual.
Eliminar todo el contexto que no sea de código: Eliminar la narrativa, los comentarios ocultos y cualquier contenedor HTML/Markdown. Convertir el código a formato canónico mediante formateadores de lenguaje (Black, Prettier) para normalizar los espacios en blanco ofuscados o los caracteres de control.
Rechazar o poner en cuarentena el código con estas construcciones: dinámico eval, llamadas de subprocesos sin procesar (os.system, subprocess.Popen), blobs base64 en línea decodificados para su ejecución o incrustados #! directivas que intentan cambiar el contexto del intérprete. Normalizar el texto y eliminar caracteres de ancho cero
Elimine caracteres como U+200B, U+200C, U+200D, U+FEFF y otros puntos de código de formato de ancho cero. Registre lo eliminado para su auditoría. Este paso elimina muchas codificaciones ocultas utilizadas para ocultamiento visual.

Paso 3: analizar en AST y reemplazar los nodos riesgosos

Con el código analizado en un AST, busque nodos que llamen a la ejecución dinámica (por ejemplo, exec) o que generen nombres de funciones mediante programación. Reemplácelos con stubs seguros que generen una excepción controlada que indique "comportamiento dinámico inseguro bloqueado". Genere una copia depurada del código fuente respaldado por AST para su revisión. Ejecute comprobaciones de patrones de seguridad (reglas semgrep personalizadas para su entorno). Si encuentra coincidencias, márquelas y neutralícelas.

Paso 4: Endurecimiento estático y reescritura

Reescritura automatizada: pasar el código a través de un desinfectante automático que reemplaza las llamadas peligrosas con envoltorios seguros, por ejemplo, reemplazar os.system() / subprocess con un ejecutor de espacio aislado aprobado que aplica tiempos de espera y bloqueos de red.
Control de capacidadModificar o eliminar claves de API, tokens o llamadas a endpoints privilegiados; reemplazarlos con adaptadores simulados para pruebas locales. Evitar la inclusión accidental de secretos o URL.
Reescrituras de dependencia: bloque dinámico pip / npm Instalaciones creadas por el código. Requiere que las dependencias se declaren y aprueben mediante el registro.

Paso 5: corre dentro de un sandbox agresivo

Contenedores efímeros / microVMsEjecutar el código en un contenedor/VM sin red, sin acceso a las credenciales del host y con acceso limitado al sistema de archivos. Tecnologías como gVisor, Firecracker o servicios de ejecución efímera dedicados son adecuadas. Si el código debe acceder a E/S, utilice un proxy que aplique la política.
Filtros de llamadas del sistema y seccomp: Limita las llamadas al sistema permitidas. Se debe bloquear la escritura de archivos fuera de un directorio temporal.
Límites de recursos/tiempo:establece límites de CPU/memoria/tiempo para que ni siquiera las bombas lógicas puedan ejecutarse indefinidamente.

La ejecución y la monitorización de entornos aislados a menudo detectan cargas útiles que las comprobaciones estáticas pasan por alto. Las directrices del sector y los informes técnicos recientes recomiendan el uso de entornos aislados como una medida fundamental de mitigación.

¿Qué herramientas y reglas automatizadas debería tener en su pipeline?

Componentes de la cadena de herramientas recomendados

Módulo de saneamiento Unicode (bibliotecas personalizadas o existentes). Debe registrar caracteres normalizados.
Analizador sintáctico + analizador AST para cada idioma de destino (Python ast, typed-ast, analizadores de JavaScript, analizadores de Java).
Analizadores estáticos / SAST:Bandit (Python), Semgrep (multilingüe, personalizable), ESLint con complementos de seguridad.
Entropía y heurística del decodificador: Detecta base64/hex/gzip y enruta a inspección.
Tiempo de ejecución de Sandbox: contenedor mínimo con perfil seccomp/AppArmor estricto o intérprete de nivel de lenguaje con llamadas al sistema deshabilitadas.
Ejecutor de políticas:un componente que decide los módulos permitidos, los puntos finales permitidos y los envoltorios de API seguros.
Registro de auditoría:registros inmutables que registran la salida original, la salida desinfectada, las diferencias y las decisiones.

Ejemplos de patrones semgrep (conceptuales)

Utilice reglas breves y conservadoras que indiquen el uso de funciones peligrosas. Por ejemplo:

Destacar eval, exec, Function constructor (JS), importaciones dinámicas o nombres de API creados a partir de cadenas.
Marcar llamadas de red fuera de la lista de permitidos (por ejemplo, requests.get a hosts desconocidos).
La bandera escribe en rutas sensibles (/etc, carpetas del sistema) o el inicio de procesos.

(Manténgalos como elementos de configuración por organización y ajústelos con el tiempo).

¿Cuáles son algunos consejos prácticos de desinfección (ejemplos seguros)?

A continuación se presentan ejemplos defensivos no peligrosos que puedes adaptar. Son Sanitización y detección fragmentos, no instrucciones de explotación.

Ejemplo: eliminar caracteres de ancho cero (Python, defensivo)

import re
ZERO_WIDTH_RE = re.compile(r'')
def strip_zero_width(s: str) -> str:
    cleaned = ZERO_WIDTH_RE.sub('', s)
    return cleaned

Esto elimina los caracteres que los atacantes suelen usar para ocultar código en texto visible. Registre siempre lo eliminado y considere la eliminación como parte del registro de auditoría.

Ejemplo: analizar e inspeccionar AST (Python, conceptual)

import ast

def has_dynamic_exec(source: str) -> bool:
    tree = ast.parse(source)
    for node in ast.walk(tree):
        if isinstance(node, ast.Call):
            if getattr(node.func, 'id', '') in ('eval', 'exec',):
                return True
        if isinstance(node, ast.Attribute):
            if getattr(node, 'attr', '') in ('popen', 'system'):
                return True
    return False

If has_dynamic_exec devuelve Verdadero, no ejecuta el código; en su lugar reemplaza el nodo dinámico con un código auxiliar seguro y requiere revisión.

Nota: Estos ejemplos son de carácter defensivo. No elimine el registro, la auditoría ni la revisión humana de su pipeline.

Reflexiones finales: trate siempre la salida de LLM como código no confiable

Los LM son potentes herramientas de productividad: pueden producir código elegante, acelerar borradores y automatizar el trabajo rutinario. Pero cuando se encuentran con la ejecución, las reglas de seguridad cambian: Las salidas del modelo deben tratarse como artefactos no confiablesLa combinación de inyecciones rápidas, investigación de puertas traseras y revelaciones de vulnerabilidades reales durante los últimos 18 a 30 meses deja en claro un punto: la superficie de riesgo ha crecido y seguirá evolucionando.

Las defensas prácticas que combinan análisis sintáctico, análisis estático, pruebas dinámicas en entornos aislados, gobernanza y trabajo en equipo continuo detendrán la mayoría de los ataques. Sin embargo, los equipos también deben invertir en controles organizacionales: mínimos privilegios, procedencia y una cultura que asuma que los resultados de LLM requieren verificación. La industria está desarrollando herramientas y marcos para facilitar estos patrones; mientras tanto, adoptar la lista de verificación anterior reduce la posibilidad de que se filtre una carga útil oculta.

Los desarrolladores pueden acceder a la última API de LLM, como por ejemplo: Claude Sonnet 4.5 API y Vista previa de Gemini 3 Pro etc. a través de CometAPI, la última versión del modelo Se actualiza constantemente con el sitio web oficial. Para empezar, explora las capacidades del modelo en el Playground y consultar el Guía de API Para obtener instrucciones detalladas, consulte la sección "Antes de acceder, asegúrese de haber iniciado sesión en CometAPI y de haber obtenido la clave API". CometAPI Ofrecemos un precio muy inferior al oficial para ayudarte a integrarte.

¿Listo para ir?→ Regístrate en CometAPI hoy !

Si quieres conocer más consejos, guías y novedades sobre IA síguenos en VK, X y Discord!