Editando WordPress (sección)

== Vulnerabilidades ==
{{Desactualizado|t=20230215172142}}
* La página web ''BlogSecurity'' mantuvo en línea (diciembre 2012) una lista de vulnerabilidades descubiertas hasta el año 2007.<ref>{{cite web|url=http://blogsecurity.net/wordpress/blogwatch/blogwatch|title=WordPress BlogWatch|date=28 octubre 2012|website=web.archive.org|fechaacceso=15 de abril de 2019|fechaarchivo=28 de octubre de 2012|urlarchivo=https://web.archive.org/web/20121028012659/http://blogsecurity.net/wordpress/blogwatch/blogwatch|deadurl=}}</ref>
* En enero de 2007, muchos sitios reconocidos de blogs relacionados con optimización de búsquedas ([[Search engine optimization]], SEO), así como muchos blogs comerciales de menor importancia y que utilizaban [[AdSense]] fueron objetivo de ataques con un [[exploit]] (pieza de código que explota una vulnerabilidad).<ref>{{cite web|url=http://www.threadwatch.org/node/11333|title=Wordpress Exploit Nails Big Name Seo Bloggers - Threadwatch.org|date=6 octubre 2018|website=web.archive.org|fechaacceso=15 de abril de 2019|fechaarchivo=6 de octubre de 2018|urlarchivo=https://web.archive.org/web/20181006064601/http://www.threadwatch.org/node/11333|deadurl=}}</ref>
*Una vulnerabilidad en uno de los servidores web del proyecto WordPress permitió a un atacante introducir código con vulnerabilidades en forma de una [[puerta trasera]] ({{lang-en|backdoor}}) para algunas descargas de WordPress 2.1.1. El lanzamiento de la versión 2.1.2 superó este incidente; una advertencia enviada a tiempo aconsejó a todos los usuarios actualizar inmediatamente.<ref> {{Cita web |url= http://wordpress.org/development/2007/03/upgrade-212/ |título= WordPress 2.1.1 dangerous, Upgrade to 2.1.2 |editorial= WordPress.org |fechaacceso=4 de marzo de 2007 |fecha=2 de marzo de 2007| | urlarchivo = https://web.archive.org/web/20070303002644/http://wordpress.org/development/2007/03/upgrade-212/ | fechaarchivo = 3 de marzo de 2007}}</ref>
* En mayo de 2007, un estudio aplicado en 50 blogs reveló que el 98&nbsp;% eran vulnerables a ataques.<ref>{{cite web|url=http://blogsecurity.net/wordpress/articles/article-230507|title=WordPress Community Vulnerable|date=11 junio 2010|website=web.archive.org|fechaacceso=26 de diciembre de 2017|fechaarchivo=11 de junio de 2010|urlarchivo=https://web.archive.org/web/20100611212652/http://blogsecurity.net/wordpress/articles/article-230507|deadurl=}}</ref>
* En una entrevista en junio de 2007, Stefen Esser, el fundador del PHP Security Response Team, criticó el registro de seguridad de WordPress, citando problemas con la arquitectura de la aplicación que hacían innecesariamente difícil escribir código que sea seguro frente a vulnerabilidades de inyección SQL, así como otros problemas.<ref>{{cite web|url=http://blogsecurity.net/wordpress/interview-280607|title=Interview with Stefan Esser|date=11 junio 2010|website=web.archive.org|fechaacceso=26 de diciembre de 2017|fechaarchivo=11 de junio de 2010|urlarchivo=https://web.archive.org/web/20100611214746/http://blogsecurity.net/wordpress/interview-280607|deadurl=}}</ref>
* En junio de 2013, se descubrió que algunos de los 50 plugins de WordPress más descargados eran vulnerables a ataques web comunes como la inyección SQL y XSS. Una inspección separada de los 10 principales plugins de comercio electrónico mostró que siete de ellos eran vulnerables.<ref>{{Cita web|url=https://www.crn.com/news/security/240156883/popular-wordpress-e-commerce-plugins-riddled-with-security-flaws.htm|título=Popular WordPress E-Commerce Plugins Riddled With Security Flaws|fechaacceso=2023-02-15|apellido=Westervelt|nombre=Robert|fecha=2013-06-18|sitioweb=CRN|idioma=en}}</ref> En un esfuerzo por promover una mayor seguridad y agilizar la experiencia de actualización en general, se introdujeron actualizaciones automáticas en segundo plano en WordPress 3.7.<ref>{{Cita web|url=https://codex.wordpress.org/Configuring_Automatic_Background_Updates|título=Configuring Automatic Background Updates « WordPress Codex|fechaacceso=2023-02-15|idioma=en}}</ref>
*En enero de 2017, los auditores de seguridad de Sucuri identificaron una vulnerabilidad en la API REST de WordPress que permitiría a cualquier usuario no autenticado modificar cualquier entrada o página dentro de un sitio que ejecute WordPress 4.7 o superior. Los auditores notificaron discretamente a los desarrolladores de WordPress, y en seis días WordPress publicó un parche de alta prioridad para la versión 4.7.2, que solucionaba el problema.<ref>{{Cita web|url=https://make.wordpress.org/core/2017/02/01/disclosure-of-additional-security-fix-in-wordpress-4-7-2/|título=Disclosure of Additional Security Fix in WordPress 4.7.2|fechaacceso=2023-02-15|fecha=2017-02-01|sitioweb=Make WordPress Core|idioma=en-US}}</ref><ref>{{Cita web|url=https://blog.sucuri.net/2017/02/content-injection-vulnerability-wordpress-rest-api.html|título=Content Injection Vulnerability in WordPress|fechaacceso=2023-02-15|apellido=Montpas|nombre=Marc-Alexandre|fecha=2017-02-01|sitioweb=Sucuri Blog|idioma=en-US}}</ref>

Algunas de estas vulnerabilidades pueden ser solucionadas con una correcta configuración del fichero [[.htaccess]] para instalaciones Apache o en el fichero web config para instalaciones con [[Internet Information Services|IIS]]; Configuraciones más complejas, incluyendo el uso de [[autenticación de múltiples factores]] con herramientas de terceros, seguidas de una constante rutina estructurada, garantizan un funcionamiento satisfactorio a nivel de seguridad en WordPress.{{Cita requerida}}