Francisco Torres

Hi, removing wp-polyfill dependencies is actually something that is happening, as for example this ticket related to the next version of WordPress.

In any case, this has to do with performance and dropping support for old browsers, not security issues like that one.

Polyfill is a general term and there are different “polyfill” libraries, the one that WordPress loads comes from @babel/polyfill which to my knowledge is not related to the mentioned library.

Besides, that security issue is related to the loading of a library using an external resource (their servers), which WordPress core does not do.

All included libraries in WordPress core are loaded from files included in your WordPress installation, not from external resources. In this case, this library is included in wp-includes/js/dist/vendor/wp-polyfill.js so a third party cannot modify it.

I had the same issue.

The error pops-up at /wp-admin/update-core.php

I downloaded the source code version from their github, executed composer, replaced the rest of files with ones from the original compilation (looks like there is something that is not done by composer) and now it’s working fine for me.

This is a bit tricky so I hope they publish a new version soon.

• This reply was modified 2 years, 9 months ago by Francisco Torres. Reason: Found errors

Muy buenas @alandres ,

He estado revisando esto junto a @jconti y desgraciadamente hemos descubierto que, efectivamente se trata de un hackeo, que además debo decir que parece bastante sofisticado.

Si bien no hemos trazado todo el proceso, te informo de lo que hemos visto que sucede hasta el momento.

1. El origen del virus parece ser un JS, que carga desde la URL https://cdn.crowstatic.com/mod/map.js que podría ser, a su vez, un sitio que se encuentre hackeado. Este script, cuando lo cargas directamente desde el navegador aparece un script que parece normal, pero cuando la llamada se hace desde el sitio web lo que envía realmente es el virus que hace todo esto.
2. La web hace la llamada a este script directamente en la cabecera, así que en principio podría estar en cualquier parte del código del sitio web. He visto que carga justo debajo de Google Tag Manager y el script de Google Tag Manager es distinto cuando carga el virus y cuando no carga, así que empezaría mirando por ahí.
3. Esto no carga siempre he probado varias configuraciones y lo ha hecho usando este User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1
4. El virus imita hasta cierto punto la estructura el pago Redsys InSite, de hecho carga los iconos oficiales directamente desde Redsys. Es decir, quién ha hecho esto ni es un novato ni lo ha hecho de casualidad, se ha enfocado específicamente en esto
5. Cuando escribes todos los datos de la tarjeta envía una petición POST a https://cdn.crowstatic.com/u/ que contiene información encriptada en tres variables: main, uniqueId, storedId. La variable main es bastante larga, así que se puede asumir que además de los datos de la tarjeta envía otros datos que quizás pueda usar para seguir con esto. El sitio responde con un número de 9 cifras, supongo que es un identificador.

Algo que puedes hacer a modo “urgente” para que la web siga funcionando, al menos parcialmente mientras solucionas esto es declarar lo siguiente en el htaccess

<IfModule mod_headers.c>
Header set Content-Security-Policy "default-src 'self'; form-action 'self'; base-uri 'self'; frame-ancestors 'self';"
</IfModule>

Esto básicamente le dice al navegador que no cargue ningún script externo al sitio web ni haga acciones de formulario contra direcciones de fuera del sitio web. Si bien ten en cuenta que esto afecta a todo: No funcionarán las estadísticas de Google Analytics ni otros scripts externos que puedas incluir.

Saludos.

• This reply was modified 3 years, 5 months ago by Francisco Torres.

Thanks Jeremy,

Next time i will check the github repository, i didn’t know about it ??

Regards!

This is a problem related with WPML Multilingual CMS i reproduced in version 3.0.1 over a Nginx server.

His filter for the WordPress SEO by Yoast sitemaps (plugins/sitepress-multilingual-cms/inc/wpseo-sitemaps-filter.php) takes a global variable (WPSEO_FRONT_URL) that doesn’t seems to work.

Because of this you can’t see the sitemap XML but it generates well.

Looks like a known problem in WPML https://wpml.org/forums/topic/yoast-wordpress-seo-sitemap-xsl-error/

Hi!

A fast-way to make the plugin compatible with WPML is adding a wpml-config.xml file in the plugin root directory containing:

<wpml-config>
	<admin-texts>
	        <key name="CookieLawInfo-0.9">
                        <key name="notify_message" />
                        <key name="button_1_text" />
                        <key name="button_1_url" />
                        <key name="button_2_text" />
                        <key name="button_2_url" />
                        <key name="showagain_text" />
                </key>
	</admin-texts>
</wpml-config>

That just tell what arrays that this plugin store in the database should be translated, after that you can just edit those arrays via “WPML String Translation” plugin ??

Happily solved by the author in less than an hour ??

Big thanks to Aurelien for his fast response ??