Dilaz Panel WP Registry grade D+. High-severity findings · 2 findingsWP RegistryHigh-severity findings · 2 findingsOpen the reportD+

High-severity findings.

Audited release

2.8.43

Findings

2

Worst severity

high

Content hash

da61b66bb55a9035f5ad7593… Copy

Findings

• high CSRF on save/reset/import/export because nonce checks are isset() || wp_verify_nonce()

  csrf

  saveOptions, resetOptions, exportOptions, and importOptions all treat a present nonce field as success: `if (isset($form_data['security']) || wp_verify_nonce(...))` (and the same OR for dilaz_export_nonce / dilaz_import_nonce). PHP short-circuits, so wp_verify_nonce is never consulted when the attacker includes security=1 (or any value). saveOptions is the handler that still has an options_save_cap loop, so a Subscriber is normally denied, but any user who does have that cap (typically an Administrator) can be CSRF'd from a third-party page: parse_str($_POST['form_data']) then update_option($this->optionName, $merged_options). code and editor fields keep raw HTML for current_user_can('unfiltered_html') (true for admins), so the CSRF writes script into options the consuming theme echoes on the frontend. Export/import nonces are additionally minted with basename(includes/fields.php) and verified with basename(dilaz-panel.php), so a legitimate nonce would not verify even with &&. Observable consequence: cross-site change of the Dilaz option (and, via the same pattern, the reset/import option writes already rated critical).

  dilaz-panel.php:1326,1375,1804,1840

  Recommendation

  Use check_ajax_referer() or `if (!wp_verify_nonce(...)) wp_die()`. Never combine isset() with || against a verify call. Mint and verify the same nonce action in one file. Pair every state-changing AJAX handler with current_user_can(options_save_cap).

• high PHP object injection and unauthenticated-as-subscriber data queries in querySelect

  object_injection

  DilazPanelFunctions (loaded from DilazPanel::init) registers wp_ajax_dilaz_panel_query_select and wp_ajax_dilaz_panel_get_post_titles with no nonce and no current_user_can. querySelect takes $_POST['query_args'], base64-decodes it, and unserialize()s the result with no allowed_classes restriction, then wp_parse_args's that into get_posts / get_users / get_terms. Any logged-in user, including Subscriber, can POST a crafted serialized object (object injection / POP if a gadget exists in WordPress or another plugin) or a serialized array that lists all users (query_type=user, returns ID+nickname) or private/draft posts. getPostTitles accepts selected[] post IDs and returns titles for publish/draft/pending/future/private posts of type 'any' with posts_per_page=-1. Observable consequence: user enumeration, private-content title disclosure, and unserialize of attacker-controlled bytes on every Subscriber session. The LIKE concatenation of esc_like($_POST['q']) into posts_where is additionally unsafe construction (magic-quotes still apply; not rated as SQLi).

  includes/functions.php:24-175

  Recommendation

  Add check_ajax_referer and current_user_can(options_view_cap or edit_posts) to both handlers. Replace unserialize(base64_decode($query_args)) with json_decode or unserialize(..., ['allowed_classes' => false]) of a server-side allowlisted argument set — do not accept arbitrary WP_Query/get_users args from the client. Restrict getPostTitles to posts the user can read. Use $wpdb->prepare for the LIKE clause.

WP Registry hashes the installable build and reports on that exact bytes-for-bytes copy. Embargoed findings are withheld until they are disclosed, so a clean verdict means nothing public is outstanding. WP Manifest does not audit code itself.