El codi desconegut al checkout, els comptes d’administració alterats o les comandes absents després d’una restauració urgent requereixen un pla que cobreixi tant l’atac com els registres de venda. Que carregui la pàgina d’inici només resol una part de l’avaluació.
Contenir l’atac abans d’acceptar més comandes
Si el checkout pot exposar clients a codi desconegut, valora aturar aquest recorregut de venda mentre es conserven les proves. Anota el primer avís, les URL afectades, els canvis recents d’accés i qualsevol restauració ja feta. No repeteixis pagaments amb targeta real per comprovar si ha desaparegut el símptoma.
La investigació pot incloure fitxers, contingut de la base, comptes amb privilegis, tasques programades i accessos rellevants a l’allotjament o al desplegament. Les capes afectades determinen l’abast; buidar la memòria cau no permet donar per eliminat un atac.
Recuperar la botiga sense fer retrocedir comandes a cegues
Abans de triar una còpia, compara’n la data amb l’incident i l’activitat comercial recent. Identifica quin emmagatzematge de comandes era actiu, quines captures posteriors existeixen i quins registres de pagament o lliurament poden ajudar a conciliar.
Una base antiga pot ometre comandes noves. Un càrrec no conserva necessàriament tota la cistella. La recuperació ha de distingir registres validats de dades desconegudes i evitar cobrar una altra vegada, descomptar estoc dues vegades o repetir avisos al client.
Comprovar pagaments i comandes com a parts diferents del recorregut
Un pagament capturat amb una comanda pendent o absent pot estar relacionat amb el lliurament del callback, errors en processar-lo, un canvi d’emmagatzematge o una restauració. L’estat de la comanda no identifica tot sol la causa. Contrasta proves de la passarel·la i de l’aplicació abans de modificar-lo.
Si la passarel·la ho permet, acorda una prova en sandbox que cobreixi la creació de la comanda, la confirmació del pagament, l’estoc, el traspàs a logística i el correu transaccional. Si cal una comprovació real, concreta’n abans els límits i l’autorització; les compres de clients no han de convertir-se en una prova sense control.
Acordar què ha de lliurar la recuperació
La proposta ha de concretar contenció, conservació de proves, reparació justificada, conciliació de comandes si escau i comprovacions abans de reobrir. Restaurar una còpia i importar comandes són operacions diferents i tenen riscos diferents.
El tancament documenta què s’ha trobat, què s’ha canviat, quins recorreguts s’han provat i què queda sense resoldre. La manca de registres pot limitar la recuperació. Disponibilitat, terminis i pressupost es confirmen després d’avaluar; aquesta pàgina no promet recuperar totes les comandes ni evitar qualsevol atac futur.
Sol·licitar una avaluació amb el període afectat
Envia l’URL, les hores del primer avís i de la restauració amb la zona horària, el recorregut afectat, una estimació de comandes absents i si el checkout està aturat. Descriu quines captures i proves de la passarel·la o de logística existeixen, sense adjuntar aquests registres.
Comença amb una descripció, no amb accessos. No enviïs exportacions de clients, targetes, contrasenyes ni bases compromeses pel formulari públic. Si cal evidència detallada, s’acordarà un canal segur un cop definit l’abast.
Sol·licitar una avaluació de WooCommerce hackejat
- Què fer si una restauració elimina comandes recents de WooCommerce
- Restaurar WordPress sense reintroduir la intrusió
RECUPERACIÓ DE WORDPRESS BASADA EN EVIDÈNCIES
Proves i criteris d’acceptació de la recuperació
L’avaluació relaciona el possible atac amb les funcions i els registres de la botiga que estan en risc. L’abast acordat determina quines capes i integracions es revisen.
Què comprovem
- Cronologia de l’incident i la restauració, URL afectades i contenció aplicada
- Codi, comptes i persistència rellevants dins de l’abast acordat
- Captures de comandes i proves de pagament o lliurament disponibles
- Proves controlades de checkout, callbacks, estoc i notificacions
- Troballes documentades, registres sense resoldre i responsables de reobertura
Què significa un resultat verificat
El tancament distingeix contenció, correccions fetes i proves que donen suport al recorregut de venda comprovat. Queden explícites les comandes sense resoldre, les dependències d’accés i les tasques posteriors. Superar una prova no demostra haver recuperat totes les comandes històriques.
ABANS DE L’AVALUACIÓ
Preguntes freqüents sobre aquesta incidència
Restaurar una còpia recupera totes les comandes pagades?+
No necessàriament. Una còpia anterior pot ometre comandes recents i els registres de pagament poden no tenir el detall de la cistella o del lliurament. Primer s’avaluen les captures i les proves independents per acordar què es pot recuperar.
Una comanda pendent demostra que ha fallat el webhook de pagament?+
No. Pot haver-hi problemes de lliurament del callback, errors en processar-lo, canvis d’emmagatzematge o una restauració de la base. Cal contrastar els registres de la passarel·la i l’aplicació abans de canviar l’estat o repetir el pagament.
Es pot verificar el checkout sense un càrrec real?+
Es prefereix un sandbox compatible per a les proves controlades. Si una comprovació exigeix una transacció real, se n’acorden abans l’abast i l’autorització. La prova en sandbox té límits i no demostra tots els recorreguts de producció.
Quan pot començar el treball i quant costarà?+
L’avaluació inicial concreta urgència, proves disponibles, accessos necessaris i treball proposat. Disponibilitat, terminis i pressupost es confirmen abans d’intervenir; enviar la sol·licitud no autoritza per si sol un càrrec.