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

Errors & Diagnosis

Malware de WordPress almacenado en wp_options: localizar cargas autoload de forma segura

Los atacantes pueden almacenar scripts, redireccionamientos o configuración codificada en wp_options. Identifica al consumidor antes de eliminar datos.

Qué importa primero: Las opciones descargadas automáticamente están disponibles en casi todas las solicitudes, lo que las hace atractivas para la persistencia. La opción puede contener código directamente, un URL remoto o ajustes utilizados por un plugin comprometido.

Qué indica realmente este síntoma

Los valores grandes o sospechosos son pistas, pero legítimos plugins también almacenan datos seriados y codificados. Trace dónde se lee la opción y cómo afecta a la salida.

Recopila pruebas antes de cambiar nada

  • Exportar nombres de opciones sospechosos, tamaños, banderas de autocarga y valores de forma segura.
  • Busque en la base de códigos las lecturas del nombre exacto de la opción.
  • Compara el tiempo de creación o modificación con el incidente.
  • Inspecciona los transitorios, las opciones de sitio y las tablas multisitio cuando sean relevantes.

Causas más habituales

  • Opción de script inyectado: Malicious JavaScript o PHP-como carga útil se representa por el código comprometido.
  • Configuración remota de órdenes: Una opción almacena un punto final o token del atacante.
  • Ajustes modificados de plugin: Se cambia una opción legítima para cargar contenido no confiable.
  • Persistencia en serie: Los datos anidados ocultan valores maliciosos de búsquedas simples de texto.

Secuencia segura de diagnóstico y reparación

  1. Cree una copia de seguridad de la base de datos y conserve la fila original de la opción.
  2. Eliminar o corregir el código malicioso consumidor antes de eliminar el valor.
  3. Usa herramientas con WordPress para actualizar los datos seriados de forma segura.
  4. Flush caché de objetos y verificar que la opción no regresa de cron o sincronización remota.

Cómo distinguir entre las causas probables

No trates Opción de script inyectado y Configuración remota de órdenes como causas equivalentes. Malicious JavaScript o PHP-como carga útil se representa por el código comprometido. En cambio, una opción almacena un punto final o token del atacante. Para distinguirlas, usa estas dos comprobaciones: Exportar nombres de opciones sospechosos, tamaños, banderas de autocarga y valores de forma segura; y busque en la base de códigos las lecturas del nombre exacto de la opción. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Cree una copia de seguridad de la base de datos y conserve la fila original de la opción— o si debes conservar el estado actual y ampliar la investigación.

En una web comprometida, contener y limpiar son decisiones distintas. Conserva el archivo sospechoso y los registros de acceso antes de eliminar la persistencia, y rota las credenciales solo después de cerrar la vía activa. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.

Qué no debes hacer

No ejecute amplios reemplazos SQL contra opciones seriadas sin una copia de seguridad probada. Los metadatos de longitud pueden romper y dañar la configuración legítima.

Cómo verificar la reparación

  • La opción maliciosa y su escritor son eliminados.
  • Las páginas renderizadas, los feeds y las respuestas REST permanecen limpias después de la descarga de caché.
  • No reaparece ningún valor autocargado sospechoso.

Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.

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