El codi d’emergència copiat en un tema, un administrador ocult o una eina de base pública poden sobreviure a l’incident. Una via de recuperació ha de ser atribuïble, temporal, reversible i eliminar-se dins del mateix treball.
Utilitza controls fiables existents sempre que sigui possible.
Verifica propietari i abast
Confirma que qui autoritza controla el domini, subscripció de hosting o organització. Identifica instal·lació, usuari i finalitat exactes.
No acceptis un nom conegut en un correu o una afirmació pública com a prova. Utilitza el procés de propietat del hosting o l’organització. Registra aprovació i hora prevista de retirada.
Prefereix rutes compatibles
Utilitza el restabliment normal si la bústia és fiable, o WP-CLI, hosting o base per a un administrador existent verificat. Captura la base abans de canvis directes.
Evita editar el nucli, afegir un bypass per query string o pujar una shell de recuperació. Creen rutes executables que algú pot descobrir. Executa com a propietari de la web, no com a usuari il·limitat.
Fes visible l’accés temporal
Si necessites un usuari temporal, dona-li nom identificable, rol mínim, credencial única i responsable de caducitat. Registra’n la creació i els usos.
No amaguis un nom genèric ni reutilitzis el compte de suport en diverses webs. No l’ocultis mai de la pantalla Usuaris. Activa MFA i limita el hosting quan sigui possible.
Limita l’abast de la credencial
Separa WordPress, hosting, base, DNS i pagaments. Revisar formularis no requereix automàticament accés al registrador o root.
Utilitza invitacions gestionades i claus breus en lloc d’enviar contrasenyes per correu o xat. Dona un compte individual a cada persona. Revoca la seva identitat sense canviar una clau compartida quan la plataforma ho permeti.
Conserva l’auditoria
Registra hores, IDs, ordres o tiquets i rutes afectades. No desis contrasenyes, tokens ni files completes de la base.
Mantén evidència original separada de còpies de treball. La reparació no ha d’esborrar qui va crear l’usuari desconegut o va canviar credencials. Utilitza una sola zona horària.
Evita bypasses en fitxers
El codi que inicia sessió automàticament, restableix contrasenyes en cada petició o crea un administrador en carregar el tema és persistència, encara que la intenció sigui bona. Pot executar-se públicament i quedar en còpies.
Si el trobes, retira’l abans de provar en públic. Revisa temes, mu-plugins, snippets i wp-config.php per modificacions d’emergències anteriors. Substitueix fitxers mantinguts des de paquets fiables.
Protegeix el propietari recuperat
Quan entri el propietari, configura contrasenya única, MFA, revocació de sessions i revisió de contrasenyes d’aplicació. Confirma correu i rol.
Assegura correu principal, hosting i DNS perquè ningú reverteixi la recuperació. Rota MySQL i API exposades en ordre controlat. Busca administradors i tasques que recreïn comptes.
Tanca totes les rutes temporals
Elimina usuaris, claus, eines de base, regles IP i bypasses de manteniment temporals. Retira còpies locals de secrets i exportacions segons la política.
Comprova-ho a WordPress, hosting, SSH/SFTP i CDN, no només a les notes del suport. Registra evidència de tancament. No deixis accés d’«emergència» per comoditat futura.
Revisa còpies i repositoris de desplegament: treure el bypass de producció és temporal si reapareix en la propera restauració.
Comprova també plugins de snippets, tasques d’aprovisionament i documentació interna que pugui indicar tornar a instal·lar-lo. Marca com a retirat qualsevol procediment antic i conserva només una via compatible i aprovada.
Verifica l’operació normal
Prova login normal, restabliment, formularis, checkout, cron i correu. Confirma que no queden bypasses, sessions o regles provisionals.
Monitoritza creació d’administradors, canvis de rol i accés al hosting. Si la propietat o els privilegis no són clars, demana recuperació gestionada mitjançant una invitació autoritzada, mai credencials permanents, enllaços de reset o codi executable.