Learn more about WordPress core software security in this free white paper. You can also download it in PDF format.


This document is an analysis and explanation of the WordPress core software development and its related security processes, as well as an examination of the inherent security built directly into the software. Decision makers evaluating WordPress as a content management system or web application framework should use this document in their analysis and decision-making, and for developers to refer to it to familiarize themselves with the security components and best practices of the software.

The information in this document is up-to-date for the latest stable release of the software, WordPress 4.7 at time of publication, but should be considered relevant also to the most recent versions of the software as backwards compatibility is a strong focus for the WordPress development team. Specific security measures and changes will be noted as they have been added to the core software in specific releases. It is strongly encouraged to always be running the latest stable version of WordPress to ensure the most secure experience possible.

Përmbledhje Ekzekutive

WordPress is a dynamic open-source content management system which is used to power millions of websites, web applications, and blogs. It currently powers more than 33% of the top 10 million websites on the Internet. WordPress’ usability, extensibility, and mature development community make it a popular and secure choice for websites of all sizes.

Since its inception in 2003, WordPress has undergone continual hardening so its core software can address and mitigate common security threats, including the Top 10 list identified by The Open Web Application Security Project (OWASP) as common security vulnerabilities, which are discussed in this document.

The WordPress Security Team, in collaboration with the WordPress Core Leadership Team and backed by the WordPress global community, works to identify and resolve security issues in the core software available for distribution and installation at, as well as recommending and documenting security best practices for third-party plugin and theme authors.

Site developers and administrators should pay particular attention to the correct use of core APIs and underlying server configuration which have been the source of common vulnerabilities, as well as ensuring all users employ strong passwords to access WordPress.

Një Përmbledhjeje WordPress-i

WordPress is a free and open source content management system (CMS). It is the most widely-used CMS software in the world and it powers more than 33% of the top 10 million websites1, giving it an estimated 60% market share of all sites using a CMS.

WordPress-i licencohet sipas licencës General Public License (GPLv2 ose të mëvonshëm) e cila jep katër liri themelore, dhe mund të shihet si “deklarata e të drejtave” në WordPress:

  1. Liria për ta xhiruar programin, për çfarëdo qëllimi.
  2. Liria për të studiuar se si funksionon programi dhe për ta ndryshohet që ta bëni të kryejë ç’të doni.
  3. Liria për të rishpërndarë kopje.
  4. Liria për t’u shpërndarë të tjerëve kopje të versioneve tuaja të modifikuara.

Ekipi Drejtues i Bazës së WordPress-it

The WordPress project is a meritocracy, run by a core leadership team, and led by its co-creator and lead developer, Matt Mullenweg. The team governs all aspects of the project, including core development,, and community initiatives.

The Core Leadership Team consists of Matt Mullenweg, five lead developers, and more than a dozen core developers with permanent commit access. These developers have final authority on technical decisions, and lead architecture discussions and implementation efforts.

WordPress has a number of contributing developers. Some of these are former or current committers, and some are likely future committers. These contributing developers are trusted and veteran contributors to WordPress who have earned a great deal of respect among their peers. As needed, WordPress also has guest committers, individuals who are granted commit access, sometimes for a specific component, on a temporary or trial basis.

The core and contributing developers primarily guide WordPress development. Every version, hundreds of developers contribute code to WordPress. These core contributors are volunteers who contribute to the core codebase in some way.

Cikël Hedhjesh Në Qarkullim të WordPress-it

Each WordPress release cycle is led by one or more of the core WordPress developers. A release cycle usually lasts around 4 months from the initial scoping meeting to launch of the version.

Një cikël hedhjeje në qarkullim ndjek rregullsinë vijuese2:

  • Phase 1: Planning and securing team leads. This is done in the #core chat room on Slack. The release lead discusses features for the next release of WordPress. WordPress contributors get involved with that discussion. The release lead will identify team leads for each of the features.
  • Phase 2: Development work begins. Team leads assemble teams and work on their assigned features. Regular chats are scheduled to ensure the development keeps moving forward.
  • Phase 3: Beta. Betas are released, and beta-testers are asked to start reporting bugs. No more commits for new enhancements or feature requests are carried out from this phase on. Third-party plugin and theme authors are encouraged to test their code against the upcoming changes.
  • Phase 4: Release Candidate. There is a string freeze for translatable strings from this point on. Work is targeted on regressions and blockers only.
  • Phase 5: Launch. WordPress version is launched and made available in the WordPress Admin for updates.

Numra Versionesh dhe Hedhje Në Qarkullim Versionesh Sigurie

A major WordPress version is dictated by the first two sequences. For example, 3.5 is a major release, as is 3.6, 3.7, or 4.0. There isn’t a “WordPress 3” or “WordPress 4” and each major release is referred to by its numbering, e.g., “WordPress 3.9.”

Major releases may add new user features and developer APIs. Though typically in the software world, a “major” version means you can break backwards compatibility, WordPress strives to never break backwards compatibility. Backwards compatibility is one of the project’s most important philosophies, with the aim of making updates much easier on users and developers alike.

A minor WordPress version is dictated by the third sequence. Version 3.5.1 is a minor release, as is 3.4.23. A minor release is reserved for fixing security vulnerabilities and addressing critical bugs only. Since new versions of WordPress are released so frequently — the aim is every 4-5 months for a major release, and minor releases happen as needed — there is only a need for major and minor releases.

Përputhshmëri Me Versione të Mëparshëm

The WordPress project has a strong commitment to backwards compatibility. This commitment means that themes, plugins, and custom code continues to function when WordPress core software is updated, encouraging site owners to keep their WordPress version updated to the latest secure release.

WordPress-i dhe Siguria

Ekipi i Sigurisë i WordPress-it

The WordPress Security Team is made up of approximately 50 experts including lead developers and security researchers — about half are employees of Automattic (makers of, the earliest and largest WordPress hosting platform on the web), and a number work in the web security field. The team consults with well-known and trusted security researchers and hosting companies3.

The WordPress Security Team often collaborates with other security teams to address issues in common dependencies, such as resolving the vulnerability in the PHP XML parser, used by the XML-RPC API that ships with WordPress, in WordPress 3.9.24. This vulnerability resolution was a result of a joint effort by both WordPress and Drupal security teams.

WordPress Security Risks, Process, and History

The WordPress Security Team believes in Responsible Disclosure by alerting the security team immediately of any potential vulnerabilities. Potential security vulnerabilities can be signaled to the Security Team via the WordPress HackerOne5. The Security Team communicates amongst itself via a private Slack channel, and works on a walled-off, private Trac for tracking, testing, and fixing bugs and security problems.

Each security report is acknowledged upon receipt, and the team works to verify the vulnerability and determine its severity. If confirmed, the security team then plans for a patch to fix the problem which can be committed to an upcoming release of the WordPress software or it can be pushed as an immediate security release, depending on the severity of the issue.

For an immediate security release, an advisory is published by the Security Team to the News site6 announcing the release and detailing the changes. Credit for the responsible disclosure of a vulnerability is given in the advisory to encourage and reinforce continued responsible reporting in the future.

Administrators of the WordPress software see a notification on their site dashboard to upgrade when a new release is available, and following the manual upgrade users are redirected to the About WordPress screen which details the changes. If administrators have automatic background updates enabled, they will receive an email after an upgrade has been completed.

Automatic Background Updates for Security Releases

Starting with version 3.7, WordPress introduced automated background updates for all minor releases7, such as 3.7.1 and 3.7.2. The WordPress Security Team can identify, fix, and push out automated security enhancements for WordPress without the site owner needing to do anything on their end, and the security update will install automatically.

When a security update is pushed for the current stable release of WordPress, the core team will also push security updates for all the releases that are capable of background updates (since WordPress 3.7), so these older but still recent versions of WordPress will receive security enhancements.

Individual site owners can opt to remove automatic background updates through a simple change in their configuration file, but keeping the functionality is strongly recommended by the core team, as well as running the latest stable release of WordPress.

10 Kryesuesit në 2013 OWASP

The Open Web Application Security Project (OWASP) is an online community dedicated to web application security. The OWASP Top 10 list8 focuses on identifying the most serious application security risks for a broad array of organizations. The Top 10 items are selected and prioritized in combination with consensus estimates of exploitability, detectability, and impact estimates.

The following sections discuss the APIs, resources, and policies that WordPress uses to strengthen the core software and 3rd party plugins and themes against these potential risks.

A1 - Injektime

There is a set of functions and APIs available in WordPress to assist developers in making sure unauthorized code cannot be injected, and help them validate and sanitize data. Best practices and documentation are available9 on how to use these APIs to protect, validate, or sanitize input and output data in HTML, URLs, HTTP headers, and when interacting with the database and filesystem. Administrators can also further restrict the types of file which can be uploaded via filters.

A2 - Broken Authentication and Session Management

WordPress core software manages user accounts and authentication and details such as the user ID, name, and password are managed on the server-side, as well as the authentication cookies. Passwords are protected in the database using standard salting and stretching techniques. Existing sessions are destroyed upon logout for versions of WordPress after 4.0.

A3 - <em>Cross Site Scripting</em> (XSS)

WordPress-i ofron një gamë funksionesh të cilët mund të ndihmojnë që të dhënat e furnizuara nga përdoruesit të jenë të parrezik10. Përdoruesit e besuar, që në një instalim WordPress njësh janë përgjegjësi dhe redaktorët, dhe në një instalim WordPress Shumësajtësh janë përgjegjësit e rrjetit, mund të postojnë HTML ose JavaScript të pafiltruar, kur u duhet, bie fjala, brenda një postimi apo faqeje. Lënda e përdoruesve jo të besuar dhe ajo e parashtruar nga përdoruesit, si parazgjedhje, filtrohet për të hequr njësi të rrezikshme, duke përdorur librarinë KSES përmes funksionit wp_kses.

As an example, the WordPress core team noticed before the release of WordPress 2.3 that the function the_search_query() was being misused by most theme authors, who were not escaping the function’s output for use in HTML. In a very rare case of slightly breaking backward compatibility, the function’s output was changed in WordPress 2.3 to be pre-escaped.

A4 - Referencë e Pasiguruar Objekti të Drejtpërdrejtë

WordPress-i shpesh furnizon referenca të drejtpërdrejta objekti, të tilla si identifikues numerikë unikë llogarish përdoruesish ose lëndë që është pjesë te fusha URL-sh apo formularësh. Ndërkohë që këta identifikues përmbajnë informacion të drejtpërdrejtë mbi sistemin, lejet e shumta dhe sistemi i kontrollit të hyrjeve në WordPress i pengojnë kërkesat e paautorizuara.

A5 - Keqfomërsim Sigurie

Shumica e veprimeve për formësim të sigurisë së WordPress-it janë të kufizuara për një përgjegjës të vetëm të autorizuar. Rregullimet parazgjedhje për WordPress-in merren vazhdimisht në shqyrtim nga ekipi bazë, dhe ky ekip i WordPress-it furnizon dokumentimin dhe praktikat më të mira për forcimin e sigurisë për formësim shërbyesi për xhirimin e një sajti WordPress11.

Ekspozim të Dhënash të Rezervuara

Fjalëkalimet e llogarive të përdoruesve të WordPress-it trajtohen sipas platformës Portable PHP Password Hashing12. Sistemi i lejeve në WordPress përdoret për të kontrolluar hyrjen në të dhëna private, të tilla si PII e një përdoruesi të regjistruar, adresa email të komentuesve, lëndë e botuar privatisht, etj. Pas WordPress 3.7-s, te programi bazë qe përfshirë një matës fortësie fjalëkalimi, që jep për përdoruesit të dhëna shtesë gjatë caktimit të fjalëkalimit dhe këshilla për rritjen e fortësisë. WordPress-i ka gjithashtu një rregullim opsional formësimi për kërkim përdorimi të HTTPS-ës.

A7 - Missing Function Level Access Control

WordPress-i kontrollon për autorizim dhe leje të duhura për çfarëdo kërkese aksesi në nivel funksioni, përpara se veprimi të kryhet. Përdorimi apo shfaqja e URL-ve, menuve dhe faqeve administrative, pa mirëfilltësimin e duhur, është e integruar fort me sistemin e mirëfilltësimeve, për të parandaluar hyrje nga përdorues të paautorizuar.

A8 - Cross Site Request Forgery (CSRF)

Për të vlerësuar synimin e kërkesave për veprim nga përdorues të autorizuar, në mbrojtje kundër kërcënimesh CSRF potenciale, WordPress-i përdor token-ë kriptografikë, të quajtur nonces13. WordPress-i furnizon një API për prodhimin e këtyre token-ëve, që të krijohen dhe verifikohen token-ë unikë dhe të përkohshëm, dhe token-i është i kufizuar ndaj një përdoruesi specifik, një veprimi specifik, një objekti specifik, dhe një periudhe kohore specifike, që mund të shtohet në formularë dhe URL, në u dashtë. Për më tepër, krejt <em>nonces</em> zhvleftësohen gjatë daljes nga llogaria.

A9 - Përdorim Përbërësish me Cenueshmëri të Njohura

Ekipi bazë i WordPress-it mbikëqyr ato pak librari dhe platforma që WordPress-i integron me pjesën bazë. Në të kaluarën, ekipi bazë ka dhënë kontribut në disa përbërës nga palë të treta, për t’i bërë më të sigurt, si, për shembull, përditësimi që ndreqte një cenueshmëri <em>cross-site</em> të TinyMCE-së në WordPress 3.5.214.

Në qoftë e nevojshme, ekipi bazë mund të vendosë të përfshijë ose zëvendësojë përbërës të jashtëm të rëndësishëm, si në rastin kur libraria SWFUpload u zëvendësua nga libraria Plupload në versionin 3.5.2, apo kur një degëzim (fork) i sigurt i SWFUpload-it u dha nga ekipi i sigurisë<15 për ato shtojca që vazhdonin të përdornin SWFUpload edhe për pak.

A10 - Ridrejtime dhe Përcjellje të Pavleftësuara

Sistemi i brendshëm i WordPress-it për kontrollim hyrjesh dhe mirëfilltimet do të ofrojnë mbrojtje përballë përpjekjesh për t’i drejtuar përdoruesit në destinacione të padëshiruara apo ridrejtime automatike. Kjo veçori u ofrohet edhe zhvilluesve të shtojcave, përmes një API, wp_safe_redirect()16.

Rreziqe dhe Shqetësime të Mëtejshme Sigurie

Sulme përpunimi XXE (XML eXternal Entity - Njësi XML e Jashtme)

Kur përpunon XML, WordPress-in çaktivizon ngarkimin e njësive XML të përshtatura, për të parandaluar sulme Njësi e Jashtme dhe Zgjerim Njësie. WordPress-i nuk furnizon API përpunimi ekstra XML-je të sigurt për autorë shtojcash, tej funksionit bazë të vetë PHP-së.

Sulme SSRF (Server Side Request Forgery - Sajesë Kërkesë Më Anë të Shërbyesit)

Kërkesat HTTP të emetuara nga WordPress filtrohen për të parandaluar hyrje te <em>loopback</em> dhe adresa IP private. Veç kësaj, lejohet hyrje vetëm për disa porta standarde HTTP.

Siguri Shtojcash dhe Temash në WordPress

Tema Parazgjedhje

Që të mund të shfaqë lëndën te pjesa e dukshme e sajtit, WordPress-i lyp një temë grafike. Tema parazgjedhje, e cila vjen me paketën bazë të WordPress-it (aktualisht "Twenty Nineteen") është shqyrtuar dhe testuar fuqimisht për arsye sigurie, si nga ekipi i zhvilluesve të temave, ashtu edhe nga ekipi bazë i zhvillimit.

Tema parazgjedhje mund të shërbejë si një pikënisje për zhvillim temash të përshtatura, dhe zhvilluesit e sajteve mund të krijojnë një temë pjellë që përmban disa përshtatje, por që përdor gjëra të temës parazgjedhje për shumicën e punës dhe për siguri. Tema parazgjedhje mund të hiqet lehtazi nga një përgjegjës, nëse nuk hyn në punë.

Depo Temash dhe Shtojcash

Te sajti, ka afërsisht 50 000+ shtojca dhe 5 000+ tema. Këto tema dhe shtojca janë parashtruar për përfshirje dhe janë shqyrtuar dorazi nga vullnetarët, përpara se të bëhen pjesë e listës.

Përfshirja e temave dhe shtojcave te depoja nuk është garanci që ato janë pa cenueshmëri sigurie. Për autorët e shtojcave, te sajti jepen udhëzime për t’i parë para parashtrimesh për përfshirje te depoja17, dhe dokumentim i thelluar se si të zhvillohen tema për WordPress18.

Çdo shtojcë dhe temë ka aftësinë të zhvillohet vazhdimisht nga i zoti, dhe çfarëdo ndreqjesh të mëpasshme apo shtim veçorish mund të ngarkohet te depoja për t’ua dhënë përdoruesve që kanë instaluar atë temë apo shtojcë, me një përshkrim të atij ndryshimi. Përmes pultit të administrimit, përgjegjësit e sajtit njoftohen rreth shtojcash që lypin përditësim.

Kur zbulohet një cenueshmëri shtojce nga Ekipi i Sigurisë së WordPress-it, ata lidhen me autorin e shtojcës dhe punojnë tok për ta ndrequr dhe për të hedhur në qarkullim një version të sigurt të shtojcës. Nëse nga autori i shtojcës nuk vjen reagim, ose nëse cenueshmëria është e rëndë, shtojca/tema hiqet nga drejtoria publike, dhe në disa raste, ndreqet dhe përditësohet nga Ekipi i Sigurisë.

Ekipi i Shqyrtimit të Temave

Ekipi i Shqyrtimit të Temave është një grup vullnetarësh, të drejtuar nga anëtarë kyç dhe të njohur të bashkësisë WordPress, që shqyrton dhe miraton temat e parashtruara për t’u përfshirë në listën zyrtare të Temave për WordPress. Ekipi i Shqyrtimit të Temave mirëmban Udhëzimet zyrtare mbi Shqyrtimin e Temave19, Të dhënat për Testim Temash20, dhe Shtojcat për Kontroll Temash21, dhe përpiqet të tërheqë dhe mësojë bashkësinë e zhvilluesve të Temave për WordPress lidhur me praktikat më të mira. Përfshirja në grup administrohet nga depozituesit kryesorë të ekipit të zhvillimit të WordPress-it.

Roli i Furnizuesit të Strehimit në Sigurinë e WordPress-it

WordPress-i mund të instalohet në një larmi platformash. Edhe pse software-i bazë WordPress plotëson mjaft kërkesa për përdorimin e një aplikacioni web të sigurt, të cilat janë mbuluar në këtë dokument, formësimi i sistemit operativ dhe i software-it të strehimit të shërbyesit është po aq i rëndësishëm për ta mbajtur të pacenuar aplikacionin WordPress.

Një Shënim rreth sigurisë në dhe WordPress është instalimi më i madh i WordPress-it në botë, dhe është pronë dhe administrohet nga Automattic, Inc., e cila qe themeluar nga Matt Mullenweg, bashkë-krijues i projektit WordPress. xhiron mbi software-in bazë WordPress, dhe ka proceset e veta të sigurisë, rreziqet dhe zgjidhjet e veta22. Ky dokument i referohet sigurisë lidhur me software WordPress me burim të hapur, që e strehoni ju vetë, i shkarkueshëm që prej dhe i instalueshën në çfarëdo shërbyesi në botë.


API Funksionesh Bazë WordPress

API Bazë e WordPress-it përbëhet nga një sërë API-sh individuale23, secila mbulon funksionet në të cilat përfshihet, dhe përdor një grup të dhënë funksionesh. Të tëra tok, këto formojnë ndërfaqen e projektit, e cila u lejon shtojcave dhe temave të bashkëveprojnë, ndryshojnë dhe zgjerojnë funksionet bazë të WordPress-it, pa rreziqe dhe në mënyrë të sigurt.

Teksa çdo API WordPress furnizon praktikat më të mira dhe rrugë të standardizuara për ndërveprim dhe zgjerim të software-it bazë WordPress, API-t WordPress vijuese janë ato që kanë më shumë lidhje me zbatimin dhe përshkallëzimin e sigurisë në WordPress:

API Baze të dhënash

API për Bazë të Dhënash24, shtuar me WordPress 0.71, furnizon metodën e saktë për t’i përdorur të dhënat si vlera të emërtuara të cilat janë depozituar te shtresa e bazës së të dhënave.

API Sistemi kartelash

API për Sisteme Kartelash25, shtuar me WordPress 2.626, qe krijuar fillimisht për mekanizmin e përditësimeve të vetë WordPress-it. API për Sisteme Kartelash ofron një shtresë abstrakte për lexim dhe shkrim kartelash vendore te sistemi i kartelave, bërë në mënyrë të sigurt, në një larmi llojesh strehuesish.

Këtë e kryen përmes klasës WP_Filesystem_Base, dhe disa nënklasash të tjera që sendërtojnë rrugë të ndryshme lidhjeje me sisteme kartelash vendore, në varësi të mbulimit nga strehë individuale të këtyre aftësive. Çfarëdo teme apo shtojcë që ka nevojë të shkruajë kartela lokalisht do të duhej ta bënte këtë duke përdorur familjen e klasave WP_Filesystem.


API HTTP27, shtuar me WordPress 2.728 dhe zgjeruar më tej me WordPress 2.8, standardizon kërkesat HTTP përr WordPress-in. API trajton <em>cookies</em>, kodime dhe shkodime gzip, shkodim copash (nëse versioni është HTTP 1.1), dhe të tjera sendërtime të ndryshme HTTP. API standardizon kërkesat, teston paraprakisht çdo metodë para dërgimi, dhe, bazuar në formësimin e shërbyesit tuaj, përdor metodën e duhur për të bërë kërkesën.

Leje dhe API e tanishme e përdoruesit

Lejet dhe API i tanishëm i përdoruesit është një grup funksionesh që do të ndihmojnë të verifikohen lejet e tanishme të përdoruesit dhe autoritetin për të kryer çfarëdo akti apo veprimi që kërkohet, dhe mund të mbrojë më tej kundër përdoruesish të paautorizuar që hyjnë ose kryejnë veprime tej aftësive që u janë lejuar.

Licencë lënde artikulli

Teksti në këtë dokument (pa përfshirë stemën apo shenjën tregtare të WordPress-it) licencohet sipas CC0 1.0 Universal (CC0 1.0) Public Domain Dedication. Mund ta kopjoni, ndryshoni, shpërndani dhe ekzekutoni veprën, madje edhe për qëllime komerciale, pa kërkuar leje.

Një falënderim të posaçëm për dokumentin mbi sigurinë nga Drupal-i, që na dha ca frymëzim.

Lexime Shtesë

Shkruar nga Sara Rosso

Ndihmesë nga Barry Abrahamson, Michael Adams, Jon Cave, Helen Hou-Sandí, Dion Hulse, Mo Jangda, Paul Maiorana

Version 1.0 Mars 2015