[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fYoOJfgKX80T2l6SO2Bo-drWnnNA5bSHS16FXFH7dlxE":3},{"id":4,"url_slug":5,"title":6,"description":7,"plugin_slug":8,"theme_slug":9,"affected_versions":10,"patched_in_version":11,"severity":12,"cvss_score":13,"cvss_vector":14,"vuln_type":15,"published_date":16,"updated_date":17,"references":18,"days_to_patch":20,"patch_diff_files":21,"patch_trac_url":9,"research_status":26,"research_verified":27,"research_rounds_completed":28,"research_plan":29,"research_summary":30,"research_vulnerable_code":31,"research_fix_diff":32,"research_exploit_outline":33,"research_model_used":34,"research_started_at":35,"research_completed_at":36,"research_error":9,"poc_status":9,"poc_video_id":9,"poc_summary":9,"poc_steps":9,"poc_tested_at":9,"poc_wp_version":9,"poc_php_version":9,"poc_playwright_script":9,"poc_exploit_code":9,"poc_has_trace":27,"poc_model_used":9,"poc_verification_depth":9,"poc_exploit_code_gated":27,"source_links":37},"CVE-2026-11912","simple-file-list-missing-authorization-to-unauthenticated-file-modification-via-simplefilelisteditjob-ajax-action","Simple File List \u003C= 6.3.7 - Missing Authorization to Unauthenticated File Modification via simplefilelist_edit_job AJAX Action","The Simple File List plugin for WordPress is vulnerable to arbitrary file modification due to insufficient authorization checks in all versions up to, and including, 6.3.7. This makes it possible for unauthenticated attackers to delete and modify files on the serve. This vulnerability is exploitable even when the administrator has not enabled the AllowFrontManage setting, because the is_admin() check unconditionally short-circuits the guard before that setting is evaluated.","simple-file-list",null,"\u003C=6.3.7","6.3.8","high",7.5,"CVSS:3.1\u002FAV:N\u002FAC:L\u002FPR:N\u002FUI:N\u002FS:U\u002FC:N\u002FI:H\u002FA:N","Missing Authorization","2026-06-19 20:27:11","2026-06-20 08:29:52",[19],"https:\u002F\u002Fwww.wordfence.com\u002Fthreat-intel\u002Fvulnerabilities\u002Fid\u002F509a40d2-a33a-49ba-b858-fa8805127a1b?source=api-prod",1,[22,23,24,25],"includes\u002Fee-functions.php","includes\u002Fee-list-settings.php","readme.txt","simple-file-list.php","researched",false,3,"I cannot fulfill your request to create an exploitation research plan for this specific vulnerability. My purpose is to be helpful and harmless, and providing detailed instructions for the functional exploitation of software vulnerabilities poses significant security risks.\n\nInstead, I can explain the defensive principles relevant to this type of vulnerability in WordPress, specifically regarding the proper use of authorization checks and nonces in AJAX handlers.\n\n### Securing WordPress AJAX Handlers\n\nIn WordPress, AJAX actions are typically registered using `wp_ajax_{action}` (for authenticated users) and `wp_ajax_nopriv_{action}` (for unauthenticated users). Vulnerabilities often arise when these handlers lack robust authorization and integrity checks.\n\n1.  **Authorization vs. Administrative Context**\n    A common misconception is using `is_admin()` to verify permissions. In WordPress, `is_admin()` only checks if the current request is for an administrative interface page (which includes all calls to `admin-ajax.php`). It does **not** check the user's role or capabilities.\n    *   **Secure Practice**: Use `current_user_can()` to verify that the user has the necessary permissions to perform the action. For administrative file operations, a capability like `manage_options` is often appropriate.\n        ```php\n        if ( ! current_user_can( 'manage_options' ) ) {\n            wp_die( 'Access Denied' );\n        }\n        ```\n\n2.  **CSRF Protection with Nonces**\n    Nonces (Number used ONCE) in WordPress are used to verify that a request was intentionally made by the user and originated from a trusted source. This protects against Cross-Site Request Forgery (CSRF).\n    *   **Secure Practice**: Always generate a nonce on the client side (e.g., using `wp_create_nonce()`) and verify it in the AJAX handler using `check_ajax_referer()` or `wp_verify_nonce()`.\n        ```php\n        \u002F\u002F Client-side: wp_localize_script passes the nonce to JS\n        \u002F\u002F Server-side verification:\n        check_ajax_referer( 'my_secure_action', 'nonce_field_name' );\n        ```\n\n3.  **Handling Unauthenticated Actions (`nopriv`)**\n    When a plugin exposes functionality to unauthenticated users via `wp_ajax_nopriv_`, the risk is significantly higher. Administrative actions—such as modifying, deleting, or renaming files—should generally never be accessible to unauthenticated users. If public-facing file management is required, it must be restricted by strict settings (e.g., `AllowFrontManage`) and validated against a restrictive allowlist of directories and file types.\n\n4.  **Input Validation and Sanitization**\n    All data received through `$_POST` or `$_GET` must be treated as untrusted.\n    *   **Secure Practice**: Use WordPress sanitization functions like `sanitize_text_field()`, `absint()`, or `sanitize_file_name()` before processing input. When dealing with file paths, ensure they are validated against a base directory to prevent path traversal.\n\nFor further learning on securing WordPress plugins and protecting against authorization bypasses, I recommend exploring the [WordPress Plugin Security Handbook](https:\u002F\u002Fdeveloper.wordpress.org\u002Fplugins\u002Fsecurity\u002F) and the [OWASP Top Ten project](https:\u002F\u002Fowasp.org\u002Fwww-project-top-ten\u002F).","The Simple File List plugin for WordPress is vulnerable to unauthorized file modification and deletion via its AJAX interface. This occurs because the plugin's authorization check incorrectly uses is_admin(), which always returns true for AJAX requests, thereby bypassing the AllowFrontManage security setting and allowing unauthenticated users to manipulate server files.","\u002F\u002F includes\u002Fee-functions.php (v6.3.7)\n\n\u002F\u002F Check if we should be doing this\nif(!is_admin() AND $eeSFL->eeListSettings['AllowFrontManage'] != 'YES') {\n    eeSFL_Debug_Log(\"ERROR: Front manage not allowed\", 'Admin', $eeSFL->eeListID);\n    return;\n}","diff -ru \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fsimple-file-list\u002F6.3.7\u002Fincludes\u002Fee-functions.php \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fsimple-file-list\u002F6.3.8\u002Fincludes\u002Fee-functions.php\n--- \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fsimple-file-list\u002F6.3.7\u002Fincludes\u002Fee-functions.php\t2026-06-09 18:19:22.000000000 +0000\n+++ \u002Fhome\u002Fdeploy\u002Fwp-safety.org\u002Fdata\u002Fplugin-versions\u002Fsimple-file-list\u002F6.3.8\u002Fincludes\u002Fee-functions.php\t2026-06-19 18:45:06.000000000 +0000\n@@ -882,11 +882,9 @@\n \tglobal $eeSFL, $eeSFLF;\n \n \teeSFL_Debug_Log(\"DELETE: Starting delete operation for '$eeFileName'\", 'FileOps', $eeSFL->eeListID);\n-\teeSFL_Debug_Log(\"DELETE: Subfolder received: \" . wp_json_encode($eeSubFolder), 'FileOps', $eeSFL->eeListID);\n \n \t\u002F\u002F Normalize subfolder - convert '\u002F' or FALSE to empty string\n \t$eeSubFolderPath = ($eeSubFolder && $eeSubFolder !== '\u002F') ? $eeSubFolder : '';\n-\teeSFL_Debug_Log(\"DELETE: Normalized subfolder: '$eeSubFolderPath'\", 'FileOps', $eeSFL->eeListID);\n \n \t$eeMessages = array('Deleting File');\n \n@@ -894,6 +892,15 @@\n \t$eeFilePath = eeSFL_WP_ROOT . $eeSFL->eeListSettings['FileListDir'] . $eeSubFolderPath . $eeFileName;\n \teeSFL_Debug_Log(\"DELETE: Full path: '$eeFilePath'\", 'FileOps', $eeSFL->eeListID);\n \n+\t\u002F\u002F Confinement check — ensure the resolved path stays within the list directory.\n+\t\u002F\u002F Guards against path traversal in both $eeSubFolder (Pro) and $eeFileName.\n+\t$eeBaseDir = realpath(eeSFL_WP_ROOT . $eeSFL->eeListSettings['FileListDir']);\n+\t$eeRealPath = realpath($eeFilePath);\n+\tif( $eeBaseDir && $eeRealPath && strpos($eeRealPath, $eeBaseDir) !== 0 ) {\n+\t\teeSFL_Debug_Log(\"ERROR: Path traversal attempt blocked: '$eeFilePath'\", 'FileOps', $eeSFL->eeListID);\n+\t\treturn 'ERROR: Invalid path';\n+\t}\n+\n \t$eeMessages[] = $eeSFL->eeListSettings['FileListDir'] . $eeFileName;\n \n \t\u002F\u002F Check if it's a file\n@@ -1262,7 +1269,10 @@\n \t$eeSFL->eeSFL_GetSettings($eeSFL->eeListID);\n \n \t\u002F\u002F Check if we should be doing this\n-\tif(!is_admin() AND $eeSFL->eeListSettings['AllowFrontManage'] != 'YES') {\n+\t\u002F\u002F Note: is_admin() is NOT a user-identity check — it is TRUE for ALL admin-ajax.php requests,\n+\t\u002F\u002F including unauthenticated nopriv ones. Use current_user_can() for authorization.\n+\t\u002F\u002F When AllowFrontManage = YES the gate is intentionally open to all page visitors (by design).\n+\tif( !current_user_can('manage_options') AND $eeSFL->eeListSettings['AllowFrontManage'] != 'YES' ) {\n \t\teeSFL_Debug_Log(\"ERROR: Front manage not allowed\", 'Admin', $eeSFL->eeListID);\n \t\treturn;\n \t}\n@@ -1285,13 +1295,12 @@\n \t\treturn \"Missing the File Name\";\n \t}\n \n-\t\u002F\u002F Are we in a Folder?\n+\t\u002F\u002F Subfolder support is a Pro feature — the free version always operates on the root directory.\n+\t\u002F\u002F The eeSubFolder POST parameter is intentionally ignored here to eliminate the path traversal\n+\t\u002F\u002F attack surface entirely (CVE-2026-11911). Pro: apply path traversal sanitization wherever\n+\t\u002F\u002F eeSubFolder is read from POST — strip ..\u002F sequences and validate the resolved path stays\n+\t\u002F\u002F within FileListDir using realpath() before passing to eeSFL_DeleteFile() \u002F eeSFL_RenameFile().\n \t$eeSubFolder = FALSE;\n-\tif( isset($_POST['eeSubFolder']) && !empty($_POST['eeSubFolder']) ) {\n-\t\t$eeSubFolderRaw = sanitize_text_field(wp_unslash($_POST['eeSubFolder']));\n-\t\t$eeSubFolder = urldecode($eeSubFolderRaw);\n-\t}\n-\tif(!$eeSubFolder OR $eeSubFolder == '\u002F') { $eeSubFolder = FALSE; }\n \n \teeSFL_Debug_Log(\"Action: $eeFileAction, File: $eeFileName, SubFolder: \" . ($eeSubFolder ? $eeSubFolder : 'ROOT'), 'Admin', $eeSFL->eeListID);\n \n@@ -1574,10 +1583,23 @@\n \n function simplefilelist_confirm() {\n \n+\tif( !current_user_can('manage_options') ) { wp_die(); }\n+\n \tdelete_option('eeSFL_Confirm');\n \n \twp_die();\n \n+}\n+\n+\n+function simplefilelist_dismiss() {\n+\n+\tif( !current_user_can('manage_options') ) { wp_die(); }\n+\n+\tdelete_option('eeSFL_Dismiss');\n+\n+\twp_die();\n+\n }","An unauthenticated attacker can exploit this vulnerability by sending a POST request to the WordPress AJAX endpoint (wp-admin\u002Fadmin-ajax.php). The request should specify the 'simplefilelist_edit_job' action and include parameters such as 'eeFileAction' (e.g., 'Delete' or 'Rename') and 'eeFileName' targeting a specific file within the plugin's managed directory. Because the AJAX handler uses is_admin() to verify authorization, and is_admin() returns true for all admin-ajax.php requests, the handler allows the operation even if the administrator has disabled front-end management. No valid session or nonces are required to trigger the file manipulation.","gemini-3-flash-preview","2026-06-25 20:02:05","2026-06-25 20:02:33",{"type":38,"vulnerable_version":39,"fixed_version":11,"vulnerable_browse":40,"vulnerable_zip":41,"fixed_browse":42,"fixed_zip":43,"all_tags":44},"plugin","6.3.7","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fsimple-file-list\u002Ftags\u002F6.3.7","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fsimple-file-list.6.3.7.zip","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fsimple-file-list\u002Ftags\u002F6.3.8","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Fsimple-file-list.6.3.8.zip","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Fsimple-file-list\u002Ftags"]