Evaluación inicial sin contraseñas Presupuesto antes de intervenir Especialista responsable de principio a fin

Malware y seguridad

PHP ofuscado con base64, eval o gzinflate: cómo revisarlo sin borrar código legítimo

Respuesta directa: PHP ofuscado con base64, eval o gzinflate: cómo revisarlo sin borrar código legítimo debe resolverse como una decisión operativa, no…

`base64_decode`, `eval` o `gzinflate` son señales de investigación, no prueba automática de que un PHP sea malicioso. Hay software legítimo con código generado u ofuscado. Conserva el fichero, establece su procedencia y compáralo con una versión fiable antes de borrar.

Registra la identidad del fichero

Guarda ruta, propietario, permisos, fecha y hash criptográfico antes de tocarlo. Así conservas un artefacto estable aunque luego se reemplace.

Establece la procedencia esperada

Identifica qué plugin, tema, dependencia o deploy debería ser propietario de esa ruta. Compara la versión exacta con paquete o repositorio fiable. Conserva el hash del fichero legítimo de referencia para que la comparación sea reproducible y no dependa solo de una inspección visual.

Inspecciona transformaciones sin ejecutar

Lee cadenas codificadas como datos y decodifícalas en un contexto aislado; no ejecutes payload desconocido para “ver qué hace”. Busca carga remota, acceso a credenciales o escrituras inesperadas.

Rastrea cómo se carga el fichero

Un helper sospechoso nunca incluido no equivale a código ejecutado en cada request. Sigue includes, hooks y bootstrap para entender exposición.

Busca artefactos relacionados por evidencia

Usa strings distintivos, hashes, timestamps o rutas. No borres todo fichero que contenga una función PHP común.

Restaura desde fuente fiable y prueba

Si confirmas modificación maliciosa, sustituye el componente por una release conocida y valida funcionalidad y ausencia de los indicadores concretos.

Empieza por la revisión segura de PHP ofuscado y conserva artefactos con la guía de evidencias.

ANTES DE ENVIAR LA SOLICITUD

Preguntas frecuentes.

¿Pedís contraseñas en el formulario?+

No. El formulario público nunca solicita accesos. Los datos seguros se piden únicamente después de aprobar el alcance y el presupuesto.

¿Quién revisa la incidencia?+

La solicitud llega a Jordi Ensenyat, fundador de Code Barcelona y especialista WordPress con más de 15 años de experiencia.

¿Se cambia algo antes del presupuesto?+

No. Primero se revisan los síntomas visibles y se define el alcance. La intervención empieza tras la aprobación y con una vía de vuelta preparada.

¿Trabajáis con webs en inglés y fuera de España?+

Sí. WP Repair atiende incidencias WordPress y WooCommerce en inglés y español, con servicio remoto.

Evaluar mi incidencia↗