XML-RPC té usos legítims i també superfícies d’abús: publicació remota, apps mòbils o serveis tipus Jetpack poden dependre de xmlrpc.php. Per això un bloqueig total només és segur quan saps que ningú el necessita.
Identifica quins mètodes generen la càrrega
Mesura volum, origen i temps de resposta de les peticions. Quan sigui apropiat, utilitza logs d’aplicació o inspecció de mètode per saber si el trànsit apunta a autenticació múltiple, pingbacks o una integració real.
Inventaria dependències abans de restringir
- Apps mòbils i publicació remota.
- Jetpack o serveis equivalents.
- Integracions externes que encara utilitzin XML-RPC.
- Pingbacks si el lloc els necessita realment.
system.multicall i pingback.ping no són el mateix
El primer pot agrupar molts intents d’autenticació dins d’una sola petició; el segon pot fer que el lloc generi connexions cap a tercers. Cal limitar el mètode que causa el risc concret.
Restringeix la superfície mínima necessària
- Rate-limit o bloqueja només els mètodes no utilitzats o abusats.
- Si no hi ha cap dependència, desactiva l’endpoint a la capa edge o servidor.
- Si hi ha hagut autenticació correcta, rota credencials i invalida sessions.
- Monitoritza PHP, trànsit sortint i logs després del canvi.
Relaciona XML-RPC amb la resta de l’incident
Si el patró és principalment pressió de credencials, compara’l amb l’atac de força bruta amb CPU alta. Si algun compte ha entrat o coincideixen canvis al core, afegeix una comprovació de checksums de WordPress.
No desactivis integracions a cegues
Un bloqueig d’emergència pot ser correcte, però documenta’l i prova els serveis que depenen de XML-RPC. Si una integració és necessària, limita el mètode o patró abusat.
Com verificar la restricció
El trànsit hostil ja no ha d’esgotar PHP ni provocar connexions sortints indesitjades, les integracions aprovades han de continuar funcionant i no ha de quedar cap compte o sessió compromesos.
CRITERI D’INCIDENT WP REPAIR
Com acotar l’error sense endevinar
Un bloc de manta és segur només quan res depèn del punt final. L’accés a registres i la inspecció a nivell de mètode mostren l’impacte operatiu.
Mesura la taxa de sol·licituds XML-RC, les xarxes d’origen i el temps de resposta.
Inspecciona els organismes de sol·licitud o l’aplicació registres per a noms de mètodes abusats quan sigui legalment apropiat.
Inventari d'aplicacions mòbils, Jetpack, edició remota i integracions.
Comprova si els efectes d’autenticació i pingback sortints han tingut èxit.
Què ha de quedar verificat
- El tràfic d'atac ja no esgota PHP o descadena l’abús de sortida.
- Les integracions requerides encara funcionen o tenen un substitut aprovat.
- No queda cap compte compromès ni sessió no autoritzada.
Fonts tècniques oficials
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
Sempre és segur bloquejar xmlrpc.php completament?+
Només quan res depèn del punt final. Els serveis a l’estil Jetpack, les aplicacions mòbils i les eines de publicació remota solen confiar en XML-RPC, per la qual cosa un bloc d’emergència s'ha de documentar, provar i basar en un inventari real d’integracions en comptes de suposar que és inofensiu.
Quina és la diferència entre abús system.multical i abús de pingback.ping?+
System.multicall abús empaqueta molts intents d'inici de sessió en una sola sol·licitud per accelerar les conjectures de credencial, mentre que l'abús de pingback.ping utilitza el seu lloc per enviar sol·licituds de sortida a tercers, convertint-la efectivament en una eina d'atac contra altres objectius.
Si restrinjo XML-RC, necessito fer alguna cosa més després?+
Sí. Si alguna autenticació ha tingut èxit durant l'atac, afegeix MFA i rotar credencials, i continua monitoritzant la càrrega PHP, el trànsit de sortida i registres després de la restricció per confirmar que l'abús realment s’ha aturat en lloc de canviar de forma.
Pot l'abús XML-RC afectar a altres llocs web, no només als meus?+
Sí, específicament a través de l'abús de pingback.ping, on el seu lloc s'utilitza per enviar peticions a tercers. Comprovar els efectes de pingback sortints és part del pas recomanat de recol·lecció de proves, ja que el seu servidor pot convertir-se en un participant involuntari a atacar el lloc d’una altra persona.