PTC Windchill y FlexPLM: RCE pre-auth por deserialización (CVE-2026-12569)

Contexto del incidente

El 25 de junio de 2026 CISA agregó CVE-2026-12569 a su catálogo Known Exploited Vulnerabilities con un plazo de remediación de tres días (BOD 26-04) que vence el 28 de junio de 2026. La vulnerabilidad —asignada por el propio CNA de PTC— alcanza un puntaje CVSS v4.0 de 9.3 (vector CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/AU:Y/R:U/V:C/U:Red) y un CVSS v3.1 de 9.0 según el aviso de EAC Product Development Solutions; el NVD todavía no publicó su assessment (figura "NVD assessment not yet provided"), así que por ahora se cita el del CNA. Las CWEs son CWE-20 (Improper Input Validation) y CWE-502 (Deserialization of Untrusted Data): la falla raíz está en el servlet wt.fv.uploadtocache.DoUploadToCache_Server expuesto bajo los gateways WindchillGW y WindchillAuthGW, que acepta objetos serializados Java firmados o sin firmar y los deserializa dentro del classpath del servidor de aplicaciones.

El alcance de producto es amplio. PTC publicó el aviso CS473270 el 17 de junio, y la lista de afectados cubre tres líneas: Windchill PDMlink, FlexPLM y Creo Parametric Server (CPS). Para Windchill y FlexPLM están alcanzadas todas las versiones anteriores a 11.0 M030; para CPS la advisory indica que están afectados todas las versiones porque el servlet vulnerable es parte del classpath común que comparte el stack con las versiones modernas. Los parches ya están publicados en el portal de soporte de PTC: 13.1.2.8, 13.1.3.4, 13.0.2 (Critical Patch Set bundle), 12.1.2 con los hotfixes CPSXB8/CPSXB9/CPSXB10 según el CPS instalado, y 12.0.2 con su patch equivalente. Si administrás una instancia on-prem de cualquiera de esos productos, tu ventana operativa para aplicar el fix es de tres días naturales — el KEV no espera ventanas de cambio.

El PLM no es un activo periférico: es el sistema donde viven los diseños de tus próximos cinco años de producto. Un RCE pre-auth ahí no es solo una máquina caída — es la llave a la IP que sostiene el negocio.

El contexto sectorial pesa tanto como el bug en sí. PTC Windchill es el PLM más desplegado en manufactura discreta —automotriz, aeroespacial, defensa,医療機器, electrónica— y FlexPLM es el PLM de referencia en retail, indumentaria y calzado (Nike, Adidas, LVMH, Patagonia y un largo etc. lo operan). Eso significa que detrás de un Windchill expuesto en Internet o accesible desde una VPN corporativa con un cliente con sesión activa, hay CAD no publicado todavía, listas de materiales (BOMs) con proveedores y costos, datos de propiedad intelectual que sustentan patentes en trámite, y documentos regulatorios (FDA, FAA, CE) que demoran meses volver a producir si se filtran. La cadena completa —upload de un objeto serializado malicioso, deserialization gadget que ejecuta Runtime.exec() o equivalente, y RCE como el usuario del servidor de aplicaciones— está documentada por OpenCVE y por el aviso de PTC, sin requerir autenticación ni interacción humana. La SSVC clasifica el caso como automatable=yes, technical_impact=total, que es exactamente la combinación para la que el KEV existe.

¿Cómo proteger tu infraestructura?

1. Aplicá el patch de PTC correspondiente a tu versión antes del 28 de junio

El paso obligatorio es el patch oficial. Para cada release line, descargá el hotfix desde el portal de soporte de PTC (support.ptc.com/appserver/auth/it/esd/product.jsp?prodFamily=WPD): 13.1.2.8 o 13.1.3.4 para la línea 13.1 (elegí el más reciente que aplique a tu base instalada), 13.0.2 con el CPS bundle correspondiente para la línea 13.0, 12.1.2 con el hotfix CPSXB8/CPSXB9/CPSXB10 según el CPS específico instalado (CPS04, CPS05–CPS08 o CPS09–CPS22 respectivamente) para 12.1, y 12.0.2 para la línea 12.0. Si tu Windchill corre en una versión anterior a 11.0 M030, la nota oficial dice que el fix se entrega por backport; contactá al soporte de PTC con tu número de versión exacto para que te asignen el bundle. Para CPS (Creo Parametric Server) la advisory cubre todas las versiones con un único lineamiento de remediación: aplicar el patch de Windchill asociado a la línea de release con la que CPS convive. Si tenés una instancia hosted en PTC Cloud, no hacés nada del lado de la infraestructura —el vendor te contacta directo con la ventana de mantenimiento, pero confirmá que efectivamente la notificación te llegó.

2. Si no podés patchear hoy, aplicá el workaround de Apache en el front-end

PTC publicó un workaround temporal basado en una regla del reverse proxy Apache que el stack Windchill trae delante. El bloqueo apunta al parámetro UploadInChunks=true en el query string de los servlets vulnerables, que es el camino que el gadget de deserialización necesita para disparar la cadena completa. Creá un archivo nuevo en <APACHE_HOME>/conf/conf.d/90-app-Windchill-Auth.conf con el <LocationMatch> que publica PTC en el artículo CS473270, recargá Apache con apachectl graceful, y verificá que las requests legítimas al endpoint de upload no rompen. Atención: este workaround es una mitigación, no un fix; cuando salga el patch oficial tenés que sacar la regla para no romper funcionalidad. Si tu Windchill está detrás de un F5, NGINX, HAProxy o un WAF comercial (Cloudflare, Akamai, Imperva) en vez de Apache, replicá la misma lógica de match en ese front — el patrón unescape(%{QUERY_STRING}) =~ /(^|&)UploadInChunks=(?i:true)(&|$)/ es portable a cualquier motor que hable regex sobre query string.

3. Sacá Windchill del alcance directo de Internet y restringí el acceso al servlet vulnerable

Windchill no debería estar expuesto a Internet en ningún escenario normal — el patrón de uso esperado es VPN corporativa con cliente autenticado, o al menos un reverse proxy con autenticación mutua (mTLS) y un WAF delante. Si tenés un Windchill con la GUI accesible desde afuera, retirá esa regla hoy y bloqueá el acceso por firewall a nivel de appliance hasta confirmar que el patch está aplicado. A nivel de segmentación interna, mové la management console a una VLAN dedicada con ACLs que limiten qué redes corporativas pueden hablar con el servidor PLM: la realidad es que la mayoría de los departamentos que necesitan acceso a Windchill (ingeniería, calidad, manufacturing IT) lo hacen desde un puñado de subnets conocidas. Si tenés integraciones automatizadas (servicios B2B, APIs REST internas, scripts de extracción de BOMs) que pegan contra los servlets WindchillGW o WindchillAuthGW, mapeá quién los consume, validá que las IPs de origen estén dentro del rango esperado, y bloqueá todo lo demás en el WAF.

4. Asumí compromiso previo y revisá logs del servlet y del servidor de aplicaciones

CISA agregó CVE-2026-12569 a KEV con la columna "Known To Be Used in Ransomware Campaigns?" en Unknown, pero el KEV no se llena sin evidencia de explotación en mundo real. Si tu Windchill estuvo accesible desde una red con tráfico de origen no confiable desde el 17 de junio de 2026 (fecha del advisory CS473270 y del NVD publish date), el servidor puede ya estar comprometido. Revisá los logs del servlet container (Tomcat, WebLogic o el que use tu deployment) buscando requests a los paths /servlet/WindchillGW/wt.fv.uploadtocache.DoUploadToCache_Server y /servlet/WindchillAuthGW/wt.fv.uploadtocache.DoUploadToCache_Server: cualquier hit con un body que no sea multipart limpio es candidato a explotación. Después revisá el classloader y los temporales del JVM: objetos serializados dejados en <TEMP_DIR>/windchill_*, clases nuevas en <WINDCHILL_HOME>/codebase/ que no estaban la semana pasada, y procesos hijos del servidor de aplicaciones que no son los documentados por PTC. Si tenés EDR en el host, cruzá la línea de tiempo del proceso Java con el momento exacto de cualquier request sospechosa al servlet.

Indicadores de compromiso (IoC)

Estos son los indicadores específicos que dejó CVE-2026-12569 en el aviso CS473270 de PTC, en la entrada de NVD y en el análisis de OpenCVE. Si los cazás en logs del WAF, del reverse proxy Apache, del servidor de aplicaciones o del EDR del host, el Windchill está bajo ataque activo o ya fue comprometido:

• Endpoints vulnerables: /servlet/WindchillGW/wt.fv.uploadtocache.DoUploadToCache_Server y /servlet/WindchillAuthGW/wt.fv.uploadtocache.DoUploadToCache_Server. Cualquier hit a estos paths sin cookie de sesión válida de Windchill (JSESSIONID o wt.wicket) o sin mTLS establecido es candidato a intento de explotación, especialmente si el método HTTP no es GET.
• Parámetro detonante en query string: presencia del flag UploadInChunks=true (case-insensitive) en el query string de cualquier request al servlet DoUploadToCache_Server. Es la condición que el workaround de Apache explícitamente bloquea y la que abre la puerta al gadget de deserialización.
• Patrones de payload en el body: contenido del request con magic bytes AC ED 00 05 (Java serialization stream magic), strings sr (SerialVersionUID marker) o clases de paquetes org.apache.commons.collections., com.sun.rowset., javax.management. en la primera decodificación. Estos son fingerprints clásicos de cadenas de gadget conocidas (ysoserial, marshalsec) aplicadas a Java.
• User-Agents anómalos: campañas automatizadas contra Windchill históricamente usan python-requests, curl, Go-http-client, Java/1.X sin versión de negocio, o UA personalizados. Los clientes legítimos son navegadores o integraciones internas con UA declarado — si ves scripts genéricos pegándole al servlet sin un Referer válido de la GUI de Windchill, es tráfico de scanning.
• Procesos hijos sospechosos del servidor de aplicaciones: tras una deserialization exitosa, es típico ver /bin/sh -c ..., curl, wget, bash -i o python -c spawneados por el proceso Java del servidor Windchill. Windchill no inicia esos procesos en operación normal — cualquier ejecución de un shell o un downloader hijo del JVM es señal fuerte de post-explotación.
• Artefactos de persistencia en el classpath: archivos .class nuevos en <WINDCHILL_HOME>/codebase/, JARs modificados en <WINDCHILL_HOME>/lib/ con timestamp posterior al último deploy limpio, scripts o binarios ELF en <WINDCHILL_HOME>/temp/ o <TEMP_DIR>/windchill_*, y entradas nuevas en el cron del usuario que corre Windchill.
• Tráfico outbound anómalo desde el servidor PLM: Windchill rara vez inicia conexiones hacia Internet por sí solo. Conexiones salientes a IPs que no son vendor (PTC), update server, NTP/Syslog internos o el IdP corporativo, especialmente a puertos 443 o 4444 sobre TLS con beacons periódicos, son señal de reverse shell o C2.
• Exposición del servlet confirmada: Shodan y Censys indexan instancias de Windchill con el path /Windchill/ o el servlet WindchillGW visible. Un dork simple (http.title:"Windchill" o http.component:"Windchill") permite verificar si tu organización aparece en esos feeds — si aparece, la superficie ya está siendo barrida.

Si tu organización opera PTC Windchill, FlexPLM o Creo Parametric Server con cualquiera de las versiones alcanzadas — propio, de un cliente, o de un proveedor de PLM como servicio — y todavía no aplicaste el patch correspondiente, la ventana de exposición está en cero: el plazo CISA vence el 28 de junio y el servlet vulnerable está en el classpath por defecto de cada release anterior a los hotfixes listados. En este caso la pregunta operativa no es "si van a pegar" sino "cuánto tiempo pasó entre que el primer script automatizado llegó a tu instancia y la fecha de hoy".

# Detección en logs del WAF o del Apache front de Windchill: requests a los servlets vulnerables
# (asume acceso al access_log consolidado del reverse proxy)
zgrep -iE 'servlet/(WindchillGW|WindchillAuthGW)/wt\.fv\.uploadtocache\.DoUploadToCache_Server' \
  /var/log/*/access*.log \
  | awk '{print $1, $4, $7, $9, $11}' \
  | sort -u

# Misma búsqueda, filtrando además por el parámetro detonante UploadInChunks=true
zgrep -iE 'servlet/(WindchillGW|WindchillAuthGW)/wt\.fv\.uploadtocache\.DoUploadToCache_Server' \
  /var/log/*/access*.log \
  | grep -iE 'UploadInChunks=true' \
  | awk '{print $1, $4, $7, $11, $13}' \
  | sort -u

# Regla Suricata para los dos endpoints vulnerables de PTC Windchill
alert http any any -> $WINDCHILL_SERVER any (
  msg:"CVE-2026-12569 PTC Windchill/FlexPLM DoUploadToCache_Server deserialization attempt";
  flow:to_server,established;
  http_uri; content:"servlet"; nocase;
  http_uri; content:"Windchill"; nocase;
  http_uri; content:"wt.fv.uploadtocache.DoUploadToCache_Server"; nocase;
  http_uri; content:"UploadInChunks=true"; nocase;
  classtype:attempted-admin;
  sid:2026125691; rev:1;
)

# Regla YARA para hunting de artefactos de post-explotación en el classpath
# (corré desde el host Windchill con cuidado de no interferir con el proceso en curso)
rule CVE_2026_12569_PostExploit_Artifact
{
  meta:
    description = "PTC Windchill CVE-2026-12569 post-exploitation indicators"
    author = "IPSecureNetwork"
    cve = "CVE-2026-12569"
  strings:
    $java_magic = { AC ED 00 05 }
    $ysoserial_marker = "ysoserial" ascii
    $marshalsec_marker = "marshalsec" ascii
    $cmd_exec = "Runtime.getRuntime().exec" ascii
  condition:
    $java_magic at 0 and ($ysoserial_marker or $marshalsec_marker or $cmd_exec)
}

# Query Sigma para hunting de procesos hijos anómalos del servidor Windchill
# (aplica para EDR tipo Sysmon/Wazuh/Elastic en el host Windchill)
title: PTC Windchill CVE-2026-12569 Suspicious Child Process from Java
logsource:
  product: windows
  category: process_create
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\curl.exe'
      - '\wget.exe'
      - '\bash.exe'
  condition: selection_parent and selection_child
level: high
tags:
  - attack.execution
  - attack.t1059
  - cve.2026.12569

# Dorks para auditoría de exposición del servlet vulnerable
# Censys / Shodan / FOFA:
#   http.title:"Windchill"
#   http.component:"Windchill"
#   http.body:"DoUploadToCache_Server"