El PoC suministrado está restringido intencionalmente:

• Ejecuta únicamente touch /tmp/CVE-2026-82222-RCE-GETBAG.
• No ofrece opción de comando arbitrario.
• No crea shell, callback, persistencia ni escalada de privilegios.
• Rechaza objetivos que no sean de loopback a menos que el operador proporcione explícitamente la bandera --allow-authorized-non-loopback.
• Docker publica WordPress solo en 127.0.0.1.
• El nombre del proyecto de Compose se deriva de la ruta del checkout, por lo que un clon no puede derribar los contenedores o volúmenes de otro clon.
• El laboratorio usa el código fuente oficial pristino del plugin; no instrumenta ni parchea el objetivo vulnerable.

La prueba HTTP crea un usuario donante desechable, metadatos y filas de sesión de GiveWP. Use el comando de reinicio incluido después de las pruebas.

Inicio rápido

Requisitos:

• Docker con Compose v2
• Python 3.10 o posterior
• curl
• unzip
• sha256sum o shasum
• Acceso de red a downloads.wordpress.org para los archivos oficiales del plugin

Ejecute la matriz completa vulnerable/parcheado:

El comando:

1. Descarga GiveWP 4.16.5.1 y 4.16.7.2 desde WordPress.org.
2. Verifica ambos hashes SHA-256.
3. Construye un laboratorio nuevo de solo-loopback de WordPress 6.6.2/PHP 8.1 con el registro normal de WordPress deshabilitado explícitamente.
4. Prueba el 4.16.5.1 pristino y exige la creación del marcador por el usuario web.
5. Construye un segundo laboratorio nuevo con el 4.16.7.2 pristino.
6. Exige que el marcador HTTP permanezca ausente.
7. Omite el ingreso en un control directo y confirma que el terminal ProviderForwarder parcheado también rechaza el callable de cadena.

El laboratorio parcheado permanece en ejecución al final. Elimínelo con:

Para usar otro puerto de loopback:

Evidencia esperada

El control vulnerable debe terminar con evidencia terminal concreta:

El control parcheado debe mostrar:

Un HTTP 500, payload almacenado, excepción o detección sin el marcador no se acepta como prueba de RCE.

Ciclo de vida manual del laboratorio

Inicie y pruebe la versión vulnerable:

Inicie y pruebe la versión parcheada:

Inspeccione el estado actual:

Elimine contenedores, volúmenes, usuarios de prueba, sesiones y estado del marcador:

Los ZIP de plugins en caché y los activos extraídos se conservan para reejecuciones más rápidas. Elimine también esos activos generados exactos con:

Versiones afectadas y probadas

El aviso público identifica las versiones hasta la 4.16.7.1 como afectadas. Este repositorio prueba directamente solo las dos versiones en su matriz de pruebas positiva/negativa.

Referencias:

• Aviso de Patchstack
• CVE-2026-82222
• Commit de endurecimiento de GiveWP
• Página oficial del plugin GiveWP

Causa raíz

El exploit combina varios comportamientos:

1. GiveWP 4.16.5.1 expone una acción de registro que crea y autentica un donante de bajo privilegio incluso cuando el registro normal de WordPress está deshabilitado.
2. Ese usuario puede persistir datos serializados en sus propios metadatos de nombre.
3. Give\Helpers\Utils::maybeSafeUnserialize() usa allowed_classes => false, produciendo __PHP_Incomplete_Class, pero una serialización posterior conserva los nombres de clase y propiedades originales.
4. El grafo se almacena en una sesión de compra de GiveWP.
5. Un maybe_unserialize() sin restricciones posterior revive las clases incluidas.
6. La destrucción automática entra en una cadena POP completa hasta system().

Se requieren cuatro barras invertidas literales de espacio de nombres en el transportador HTTP. Las dos pasadas de eliminación efectivas las reducen 4 -> 2 -> 1. El payload no contiene NUL, y se verificó que PHP 8.1.30 hidrata el nombre serializado simple para la propiedad privada Session::$attributeName.

Cadena POP completa

Grafo controlado por el atacante:

La transición oculta crítica es el despacho implícito de IteratorAggregate de PHP. TCPDF::$imagekeys no está tipado, por lo que asignar una Session de Symfony hace que foreach invoque Session::getIterator().

El comando marcador se ejecuta antes de que Symfony aplique el tipo de retorno getAttributeBag(): AttributeBagInterface. El TypeError resultante y el HTTP 500 son efectos posteriores al sumidero.

Lo que omitieron los intentos anteriores

El grafo candidato rechazado usaba:

Ese grafo no puede funcionar. TCPDF::_destroy() solo elimina objcopy; PHP no enruta la destrucción automática a través de __call('__destruct', ...).

La operación faltante era:

La revisión anterior siguió destructores y llamadas a métodos explícitos pero no inspeccionó recursivamente el protocolo de objetos implícito disparado por foreach. La Session de Symfony suministra el puente faltante:

• foreach invoca getIterator().
• getIterator() llega a getBag($attributeName).
• El storage controlado por el atacante es un DonationFactory.
• El getBag indefinido invoca ProviderForwarder::__call().
• loadedProviders['getBag'] = 'system' selecciona el callable.
• attributeName suministra el argumento del comando.

Evidencia de código fuente

Ubicaciones relevantes de GiveWP 4.16.5.1:

Hashes de las versiones oficiales:

El laboratorio re-extrae cada plugin de su ZIP verificado antes de cada inicio nuevo, lo copia en WordPress sin modificación y compara byte a byte el árbol de archivos completo del plugin desplegado con el código fuente verificado. Las tres imágenes base oficiales de Docker también están fijadas a sus resúmenes de manifiesto multiarquitectura.

Por qué 4.16.7.2 bloquea la cadena

GiveWP 4.16.7.2 añade defensas independientes en el registro, el manejo de entrada serializada, la revitalización de sesión, la migración de datos y el endurecimiento de gadgets.

El endurecimiento terminal requiere que el objeto resuelto implemente el contrato de proveedor esperado:

Por lo tanto, la cadena system controlada por el atacante es rechazada. El control directo en este repositorio omite el transportador HTTP y verifica que esta defensa terminal por sí sola deja su marcador ausente.

Comprobación de una implementación real

Un resultado negativo del PoC por sí solo no prueba que un sitio esté parcheado. Un WAF, un enrutamiento diferente, el registro deshabilitado, un formulario heredado faltante, la configuración de sesión o las funciones de comandos PHP deshabilitadas pueden impedir el marcador en una base de código aún vulnerable.

Procedimiento de validación preferido:

1. Registre la versión de GiveWP implementada y la revisión del código fuente.
2. Haga una copia de seguridad o instantánea del sitio de WordPress y la base de datos.
3. Restaure esa instantánea en un entorno de ensayo aislado.
4. Deshabilite el acceso de red saliente innecesario.
5. Ejecute este verificador solo-marcador contra el clon.
6. Actualice GiveWP a la última versión compatible, con 4.16.7.2 como la versión mínima que contiene las correcciones probadas.
7. Repita la prueba idéntica y exija la ausencia del marcador.
8. Verifique de forma independiente la versión del plugin instalado y el código fuente parcheado.

Verificación de versión:

Remediación y revisión de incidentes

Actualice GiveWP a la última versión compatible. Después de actualizar:

• Limpie las cachés de opcode de PHP donde corresponda.
• Confirme que no quede ninguna copia anterior de GiveWP activa o accesible por web.
• Revise cuentas inesperadas de WordPress o donantes.
• Busque en los metadatos de usuario y las sesiones de GiveWP grafos serializados de TCPDF, Session de Symfony o loadedProviders.
• Correlacione el registro, los cambios de perfil, las solicitudes de donación y las respuestas HTTP 500 posteriores de la misma sesión.
• Investigue procesos hijos inesperados del servidor web o cambios en el sistema de archivos.

Si una instalación vulnerable expuesta a internet contiene artefactos de inyección de objetos, trátela como un posible compromiso en lugar de solo actualizar el plugin.

Estructura del repositorio

No confirmado:

Límites de validación

El estándar de prueba es deliberadamente estricto: solo un marcador de comando observable a través de la cadena de stock sin modificar se etiqueta como RCE. La aceptación HTTP, la serialización, las excepciones y las detecciones son evidencia intermedia.