XSS2Shell in WordPress Core

The repository contains one large standalone Python 3 program, XSS2Shell-PoC.py, plus a short README and MIT license. It is not a Metasploit, Nuclei, or other established-framework module. The script includes a scanner and an optional exploit workflow for the claimed CVE-2026-64638 affecting WordPress 7.0-7.0.2. Scanner functionality fingerprints WordPress, evaluates wp-login.php behavior, tests the alleged strip_tags/KSES parser differential and reflected login-error conditions, inspects REST/JSONP exposure, and reviews security headers. Exploitation supports telemetry, alert-based XSS proof, and RCE modes. The documented chain uses injected DOM elements and DOM clobbering of ajaxurl to obtain pre-authentication JSONP-based script execution, then abuses WordPress Application Password authorization and REST operations to publish script, upload/activate a malicious plugin ZIP, and obtain a web shell. It has configurable callback host/port, wait time, TLS-verification behavior, throttling, force, proof, RCE, and no-pivot options. Local JSONL capture files are used as fallback evidence stores for callback captures.

This repository is a small single-purpose exploit PoC for CVE-2026-64638 affecting WordPress login handling. It contains three files: a LICENSE, a README with vulnerability explanation and usage examples, and one executable Python script, banner_poc.py. The Python script is the sole code file and the clear entry point. The exploit is not a scanner or detector; it is a generator that creates a malicious trigger HTML file. When a victim opens that generated file in a browser, embedded JavaScript first loads the target login URL in a hidden iframe to seed wordpress_test_cookie, then silently submits a POST request to the target login endpoint. The POST body places a crafted payload into the log parameter, abusing a strip_tags()/KSES parsing differential described in the README. The payload closes existing markup, injects a styled div banner or overlay, optionally adds a subtitle, and appends a hidden div intended to absorb trailing template text. Core exploit capabilities: - Accepts an arbitrary target login URL, including subdirectory installs and hidden/custom login paths. - Builds a reusable reflected HTML/CSS injection payload tailored for WordPress login error rendering. - Produces a self-submitting HTML lure page for browser-based delivery. - Supports operator-controlled banner text and optional subtitle. - Adapts visually across versions: full-page fixed overlay on newer vulnerable versions and degraded in-flow banner on older conditional versions. The repository targets WordPress versions 6.4.0–7.0.2 directly, with conditional support for 5.8–6.3 when plugins/themes pass login_errors through wp_kses() with style allowed. The README states 4.7–5.7 are not exploitable and lists patched versions including 7.0.3+ and several maintenance releases. Overall, this is an operational PoC generator for reflected HTML injection/social engineering on WordPress login pages rather than code execution.

Single-file Python exploit targeting WordPress, implementing a dual-mode attack chain for CVE-2026-64638. The repository contains one executable script, CVEEX2SHEL.py, which fingerprints WordPress versions, tests whether the target appears vulnerable to a pre-auth XSS condition, and then either performs an XSS-driven credential theft chain or falls back to direct authenticated exploitation using supplied credentials. The script includes a built-in HTTP callback server that listens on 0.0.0.0 and exposes /collect to receive stolen application passwords, tokens, usernames, or arbitrary POST data from the browser-based XSS payload. It fingerprints WordPress using /readme.html, the homepage generator meta tag, and /wp-json/. Based on the visible code and comments, the exploit’s end goal is plugin upload and activation to obtain RCE, with optional reverse-shell behavior using attacker-controlled LHOST/LPORT. The structure is straightforward: helper functions for user-agent randomization and banner output, a callback server class, WordPress version detection helpers, XSS detection logic, and a main routine that selects auto/xss/direct mode and launches either the XSS chain or direct RCE path. This is exploit code rather than a detector, and it is operational because it contains both credential theft/callback handling and an RCE delivery mechanism via malicious plugin upload.

This repository is a small, purpose-built Node.js exploit kit consisting of a README and a single JavaScript file, evil_ngrok.js. The script starts a local HTTP server on 127.0.0.1:8000, discovers a public ngrok tunnel via the local ngrok API, and presents an attacker console page for generating a crafted WordPress login URL. The console builds a malicious payload into the target /wp-login.php URL and points the injected markup at attacker-hosted /x.js. When a logged-in WordPress administrator clicks the crafted link, the victim browser loads /x.js from the attacker server and executes the embedded stage-2 JavaScript in the target origin. That stage-2 code requests /wp-admin/user-new.php, extracts the create-user nonce, and submits a POST request to create a new administrator account with hardcoded credentials. The repository also supports optional shortening through Bitly or Cuttly, or a self-hosted redirect endpoint /l. Overall, this is an operational web/browser exploit for reflected XSS-to-account-takeover against WordPress, with social-engineering delivery and persistence via admin account creation.

This repository is not a standalone exploit against a remote target; it is an intentionally vulnerable lab builder for researching CVE-2026-64638 / 'XSS2Shell' attack chains. The repository is very small: 4 files total, with one primary code file, xss2shell-setup.sh, plus README and license files. The Bash script is the main entry point and orchestrates installation/startup of a rootless lab environment, creates log directories, manages MariaDB lifecycle, and deploys vulnerable web content. The key offensive capability is embedded in the generated PHP application content. The custom Nexus Security Portal reflects user-controlled search input directly into HTML without sanitization, explicitly marked as vulnerable to XSS. The script also writes an exec.php endpoint that accepts POST parameter cmd and passes it directly to shell_exec(), returning the output as JSON. Together, these components model an XSS-to-RCE chain: browser-executed JavaScript from the XSS condition could issue requests to the backend execution endpoint and achieve command execution on the lab host context. Primary exposed targets described by the repository are WordPress 7.0.2 on port 8080 and the Nexus Security Portal on port 8081, defaulting to localhost (127.0.0.1) but optionally bindable to 0.0.0.0 for controlled LAN testing. MariaDB runs rootlessly on port 3307 with a Unix socket under $HOME/mariadb. Logging is a notable feature: logs are stored under the project logs/ directory, including wp_server.log, nexus_server.log, and mariadb.log. Overall, this is a functional vulnerable lab environment rather than a detection script or fake exploit. It is best classified as OPERATIONAL because it includes a working hardcoded command-execution payload path, but it is not packaged as a reusable exploitation framework.

Repository contains a standalone Python exploit (poc.py), a README with operator instructions, and a sample HTML trigger page. The exploit is presented as 'XSS2Shell ULTIMATE v3.0' targeting WordPress via an alleged pre-auth XSS to RCE chain for CVE-2026-64638. Based on the visible code and documentation, the main script supports three modes (auto, xss, direct), starts or expects a callback server, generates XSS payloads, and attempts to leverage WordPress authentication/application-password workflows to gain privileged access. It then deploys a malicious plugin/webshell under wp-content/plugins/<slug>/ and exposes command execution, file upload, reverse shell, and encrypted backdoor functionality. The README also claims persistence features such as hidden admin creation and stealth/hiding from plugin lists. The auxiliary HTML file is a concrete lure/trigger that targets WordPress endpoints /wp-login.php and /wp-admin/authorize-application.php on a sample host (192.168.0.87:8080) and exfiltrates captured data to an attacker callback at 192.168.0.47:9091/collect. Overall, this is an operational offensive exploit repository rather than a detector: its purpose is post-compromise code execution and persistence on WordPress sites.

Repository contains a small but functional exploit toolkit for the alleged WordPress Core vulnerability CVE-2026-64638, plus a Nuclei detection template. There are 4 files total: a README, one Python script, one Nuclei YAML template, and .gitignore. The main operational logic is in xss2shell.py, which is the primary entry point; the YAML file is a separate detection artifact. The exploit chain described by the repository is: unauthenticated reflected XSS on /wp-login.php via a parser differential payload (`< area ...>`), DOM injection to influence WordPress client-side behavior, abuse of same-origin requests to WordPress endpoints, then escalation to administrative actions culminating in plugin upload and a PHP webshell. The Python script exposes this as several subcommands: `check` performs a non-destructive POST to /wp-login.php and looks for reflected payload markers; `audit` is a defensive scanner for versioning, reflection, exposed files, headers, and enumeration surfaces; `exploit` generates an HTML form that submits the XSS payload to the login page; `shell` performs the RCE stage using an administrator application password; and `zip` emits a plugin archive containing the PHP payload. The embedded payloads are explicit and actionable. The XSS payload injects an `ajaxurl` element with href `/?rest_route=/&_method=GET&_jsonp=alert&_envelope=1`, plus supporting DOM elements/classes intended to trigger WordPress password/UI handlers. The PHP payload is a simple webshell-like proof that sets an `X-XSS2Shell: true` header and returns JSON containing the result of `system('id')`. This makes the repository more than a detector: it includes exploitation and post-exploitation-enabling code, though the demonstrated command execution is basic and hardcoded, so OPERATIONAL is the best fit. Because the repository includes a Nuclei template, it does belong to a framework artifact, but the repository is not only a framework template; it also contains standalone exploit code. The Nuclei template itself targets POST /wp-login.php with two payload variants and matches reflected `<area` content and HTML response headers to identify vulnerable WordPress instances. Overall, the repository’s purpose is dual-use: defensive validation and auditing of WordPress exposure, plus proof-of-concept exploitation up to plugin-based code execution.

Repository contains a small PoC project for CVE-2026-64638 with 8 files total: documentation, one Python script, one Nuclei template, and a requirements file. The main exploit logic is in xss2shell_poc.py, while nuclei-CVE-2026-64638.yaml provides a scanner-style detection template. Because the repository includes a Nuclei template, it can be considered framework-associated, but the repo also includes standalone exploit code. The exploit targets WordPress Core wp-login.php and attempts to validate a pre-authentication reflected XSS condition by submitting crafted username values that exploit parser differentials using whitespace after '<'. The Python script fingerprints WordPress versions using the site root, /readme.html, /wp-includes/version.php, and wp-login.php asset version parameters. It then posts a crafted payload to /wp-login.php and checks whether attacker-controlled DOM elements such as id="ajaxurl" and id="color-picker" survive in the response. The payload variants point ajaxurl-like elements at REST endpoints using JSONP parameters, indicating the intended chain is reflected XSS leading to JavaScript execution in the login page context. The Nuclei template is a detection-oriented exploit artifact: it sends a single POST request to /wp-login.php with payloads like '< area id=ajaxurl href=/?rest_route=/>' and matches on reflected markers including id="ajaxurl", '<area', and 'Error:' in an HTML response. The Python PoC is more operational: it supports variants (standard, envelope, waf), check-only mode, output file selection, and artifact generation. Based on the README and visible code, the repository does not directly deliver a shell; instead it validates and demonstrates the XSS2Shell primitive and documents how it could be chained toward RCE in the presence of additional conditions such as an authenticated administrator session. Overall, this is a real exploit/validation repository with both scanner and PoC components, focused on web attack vectors against WordPress login and REST endpoints.

This repository contains a standalone exploit PoC for CVE-2026-64638 targeting WordPress. The repo is small and purpose-built: README.md documents the attack chain and usage, poc.py is the main exploit implementation, and trigger_192.168.0.87.html is an example lure/trigger page for the browser-based XSS path. The exploit is not part of a major framework. The main capability is chaining a claimed pre-auth reflected XSS in /wp-login.php into full remote code execution. In xss mode, the script fingerprints WordPress versions using /readme.html, the site homepage meta generator tag, and /wp-json/. It then tests whether /wp-login.php reflects HTML in the username error flow. If vulnerable, the attacker hosts a callback HTTP server (binding on 0.0.0.0) with a /collect endpoint and serves a trigger HTML page to a logged-in administrator. The trigger submits a crafted username containing a DOM-clobbering <area id=ajaxurl> payload to wp-login.php, then drives the victim to /wp-admin/authorize-application.php with a success_url pointing to the attacker callback. The callback handler captures parameters such as password, c, app_password, token, and user_login. After credential capture, the documented post-exploitation path uses WordPress Application Passwords for Basic Auth against REST API endpoints under /wp-json/wp/v2/, specifically plugin-related endpoints, to activate a malicious plugin. The final payload is a PHP webshell placed at /wp-content/plugins/xss2shell/xss2shell.php. The README indicates it supports arbitrary command execution via ?cmd=COMMAND and reverse shell execution via ?rev=IP:PORT, with example listener port 4444. The script also supports direct mode, which skips the XSS chain and instead uses supplied administrator credentials to achieve plugin upload/activation and RCE. Auto mode chooses xss if the target appears vulnerable, otherwise falls back to direct mode when credentials are provided. Overall, this is an operational exploit PoC with both browser-assisted and credentialed attack paths, attacker-controlled callback infrastructure, WordPress fingerprinting logic, and post-exploitation webshell/reverse-shell functionality.

Repository contains a single Python exploit script, xss2shell.py, plus a README. The script is a standalone WordPress exploit/scan utility, not tied to a major framework. Its core purpose is dual-mode operation: (1) multi-target scan-only fingerprinting of WordPress instances and reflected-XSS behavior, and (2) single-target exploitation that can escalate from reflected XSS or direct credentials to plugin upload and RCE. The code includes a local HTTP callback server implemented with http.server/socketserver, listening on 0.0.0.0 and exposing /collect to receive stolen application passwords, tokens, usernames, or other callback data. It fingerprints WordPress versions using public endpoints such as /readme.html and likely additional metadata/JSON methods referenced in the truncated code. The main exploit flow supports auto, xss, and direct modes: auto chooses XSS chain if reflection is detected, otherwise falls back to credential-based exploitation if credentials are supplied. The README explicitly states the multi-target mode does not invoke RCE functions, but the single-target logic clearly includes direct_rce() and xss_chain() paths. Overall, this is an operational exploit/POC for WordPress targeting claimed CVE-2026-64638, with scanning, credential capture, plugin upload, and optional reverse-shell/callback capabilities.

Repository contains a standalone proof-of-concept exploit and a local lab for a claimed WordPress Core vulnerability chain, CVE-2026-64638. The main exploit logic is in wp-src/exploit.py, a Python HTTP server that exposes two attacker-controlled resources: /phish.html and /evil.js. The phishing page submits a crafted POST request to the target /wp-login.php with a malicious username field containing a fake element id="wp-emoji-settings". This is intended to exploit reflected XSS on the login page and then abuse the bundled emoji loader's use of document.getElementById('wp-emoji-settings') so the browser loads attacker JavaScript from source.concatemoji. The second stage JavaScript, generated by generate_evil_js(), runs in the victim browser with credentials included. It requests /wp-admin/user-new.php, extracts the _wpnonce_create-user token from the returned HTML, and submits a POST back to the same endpoint to create a hardcoded administrator account named backdoor_xss2shell with password Pwn3d!XSS2Shell. On apparent success it triggers a callback marker (?pwned=admin_created), which the Python server logs. Repository structure supports both explanation and reproduction. README.md is extensive and documents the vulnerability chain, root cause, exploitation flow, and remediation. docker-compose.yml provisions a WordPress 7.0.2 plus MySQL lab on localhost:8282. setup.ps1 automates lab initialization, installs WP-CLI, creates a WordPress site, and then deliberately patches core files inside the container to simulate the vulnerable conditions by weakening sanitization/output filtering. Two copies of wp-emoji-loader.js are included to illustrate the DOM clobbering primitive, and wp-login.php is included as reference WordPress source. Overall purpose: demonstrate a pre-auth reflected XSS to admin-account-creation chain against WordPress login flow, with a reproducible local environment. This is an exploit PoC rather than a scanner or detector. It is operational because it includes a concrete payload and end-to-end delivery flow, but it is not highly modular or framework-integrated.

Repository contains a standalone Python PoC, xss2shell_poc.py, plus a lab/ directory with Docker-based WordPress test infrastructure and verification helpers. The exploit claims to target CVE-2026-64638, a pre-auth WordPress XSS that is chained into RCE. The main capability is a multi-stage web attack: inject HTML into wp-login.php, use DOM clobbering to control ajaxurl, trigger a REST API JSONP callback for Same-Origin Method Execution, socially engineer an admin into approving an application password, then use those credentials to upload a malicious plugin and execute a PHP webshell. The Python script supports recon/check mode, attacker-page generation, credential collection workflow, authenticated RCE, command execution, interactive shell, and cleanup. The embedded payload is a minimal PHP webshell that runs shell_exec on a cmd parameter and can self-delete. Supporting files include PHP and browser tests validating sanitization and DOM behavior, a Bash script that automates curl-based verification against /wp-login.php, and docker-compose.yml that provisions a local WordPress 6.0.3 + MySQL lab. Notably, one lab analysis file (lab/test_sanitize.php) argues the XSS vector does not work on WordPress 6.0.3, while the README and verification report claim successful verification; despite that inconsistency, the repository clearly intends to provide an exploit PoC rather than mere detection.

Repository contains two Python tools: a large offensive script (exploit.py, ~67 KB) and a defensive checker (safecheck.py, ~14 KB), plus README, requirements, and metadata files. The main exploit is a standalone Python toolkit rather than a Metasploit/Nuclei module. Based on the visible code and README, exploit.py is designed as a full-chain WordPress attack utility targeting the claimed CVE-2026-64638. It includes CLI options for single-target or list-based scanning, proxy/Tor support, SSL verification control, stealth options, reverse-shell listener parameters, optional ngrok integration, optional C2 modes (http/dns/telegram), session hijacking, database dumping, SSH key extraction, privilege-escalation helpers, memory forensics, and cleanup control. The code defines XSS payload templates intended to hit the WordPress login page and a C2Manager class that performs periodic beaconing to an operator-supplied server. README documents the intended chain as reflected XSS on /wp-login.php leading to Application Password abuse, plugin upload via /wp-admin/update.php?action=upload-plugin, and execution from /wp-content/plugins/{slug}/{slug}.php. safecheck.py is a separate non-intrusive scanner that performs HTTP requests against a target WordPress site, supports mass scanning, proxy/Tor routing, and JSON reporting, and appears intended for version/reflection/security-posture checks rather than exploitation. Overall, this is an operational exploit suite with both offensive and defensive components; the offensive script goes beyond simple PoC behavior by bundling post-exploitation and operator infrastructure features.

This repository is a minimal proof-of-concept for CVE-2026-64638, described as a pre-auth reflected XSS in WordPress Core. The repository contains only two files: a single exploit file, POC.html, and a README. The exploit is not part of a larger framework and has no auxiliary tooling, build system, or automation beyond browser-based form submission. POC.html is the sole executable artifact. It defines an HTML form that POSTs directly to the target WordPress login endpoint at /wp-login.php. The hidden log parameter contains a crafted HTML payload using spaced tag openings such as '< area', '< div', and '< button'. According to the README, this abuses a parser differential involving WordPress sanitization behavior and results in DOM clobbering plus JavaScript execution in the WordPress origin. The form auto-submits immediately via JavaScript, making the file a one-click browser PoC. The exploit capability demonstrated is limited to reflected XSS execution, evidenced by use of a JSONP callback value of confirm in the injected href path /?rest_route=/&_method=GET&_jsonp=confirm. While the README claims the bug can be chained toward RCE through additional steps such as application password abuse and plugin upload, none of that chain is implemented in this repository. Therefore the code should be classified as a PoC rather than an operational or weaponized exploit. Fingerprintable targets and indicators are straightforward: the primary target is the WordPress login endpoint /wp-login.php on a user-supplied host, and the injected payload references the REST route with _jsonp=confirm. The README states affected versions are WordPress 6.4 through 7.0.2 and fixed in 7.0.3. Overall, this repository’s purpose is to demonstrate unauthenticated XSS against vulnerable WordPress instances, not to provide persistence, shell access, or automated post-exploitation.

Repository is a small standalone Python PoC for CVE-2026-64638 against WordPress. Structure is minimal: README with vulnerability description and usage, MIT license, and one substantive code file xss2shell_poc.py. The script is not a scanner; it is an operational exploit that automates a full chain from pre-auth reflected XSS on wp-login.php to server-side command execution. The exploit logic, as visible from the code and README, works by hosting an attacker-controlled local HTTP server and serving browser-side JavaScript to a victim administrator. The JavaScript crafts a malicious login request to /wp-login.php using a specially formed username payload containing HTML such as <area>, <div>, and <button> to exploit the parsing discrepancy described in the README. The chain then abuses DOM clobbering of ajaxurl, leverages a REST/JSONP endpoint with _jsonp=window.opener.approve.click, and drives privileged actions in the admin’s browser. The script tracks progress with beacon callbacks to its own /beacon endpoint. Once browser-side access is achieved, the PoC captures/stores an Application Password in xss2shell_creds.json, uses authenticated WordPress API actions to publish attacker-controlled content, uploads a malicious plugin ZIP, and expects a PHP shell at /wp-content/plugins/xss2shell/shell.php. It verifies code execution by calling the shell with cmd=id and then executes the operator-provided command. Cleanup support deletes the published page but intentionally preserves the Application Password, plugin shell, and saved credentials unless the operator removes them manually. Notable capabilities: credential capture/storage, authenticated REST abuse, plugin upload, persistent web shell deployment, command execution, and partial cleanup. Fingerprintable target artifacts include wp-login.php, WordPress REST page endpoints, the plugin shell path, and the local credential file. Overall maturity is OPERATIONAL because the exploit contains a concrete payload chain and automated post-exploitation steps, but it is still a standalone PoC rather than a reusable framework module.

Repository contains a single Python exploit/scanner script and a README. The main file, poc_fixed_v2_multitarget_concurrent.py, is a dual-purpose WordPress tool targeting CVE-2026-64638. It supports: (1) single-target exploitation workflows and (2) concurrent multi-target scan-only assessment. The script fingerprints WordPress versions, checks XSS reflection behavior, and in single-target modes can run either an XSS-to-RCE chain or a direct credential-based plugin upload path. The XSS chain includes a built-in HTTP callback server that listens on 0.0.0.0 and exposes /collect to receive exfiltrated app passwords/tokens/usernames. Script comments and README indicate the end goal is plugin upload/activation leading to command execution and optional reverse shell, with default ports 9090 for callback capture and 4444 for reverse-shell handling. The multi-target mode uses ThreadPoolExecutor to read URLs from an input file, deduplicate them, scan concurrently, and save ordered results to scan_results.txt. Based on the provided content, this is a real exploit repository rather than a pure detector, though the multi-target functionality is intentionally limited to fingerprinting and XSS reflection detection.

Small standalone Python exploit repository centered on a single script, `cve-2026-64638.py`, plus documentation and a sample target list. The repository is not part of a major exploit framework. The Python script implements two primary modes: `scan` and `exploit`. In scan mode, it loads one or more targets, fingerprints WordPress by requesting common paths (`/wp-login.php`, `/wp-admin/`, `/wp-json/`, `/xmlrpc.php`), attempts version discovery via `/readme.html`, homepage generator tags, and `/wp-json/`, then performs an XSS-oriented login test by POSTing a crafted username payload to `/wp-login.php`. It also checks the application-password authorization endpoint at `/wp-admin/authorize-application.php`. In exploit mode, it generates per-target HTML files named like `xss2shell_<domain>.html`, intended to be hosted at an attacker-controlled URL and sent to an administrator, indicating a browser-mediated exploitation chain rather than direct remote code execution from the scanner itself. The included payload snippet uses malformed/obfuscated HTML (`< area id="ajaxurl" href="javascript:alert(1)">`) and injected DOM elements (`color-picker`, `wp-generate-pw`) to test whether sanitization can be bypassed. Repository structure is minimal: one executable Python file, one README, one sample targets file, and license/gitignore. Overall, this is an operational proof-of-concept for a WordPress web/browser attack chain associated with CVE-2026-64638, combining vulnerability detection with exploit-page generation.

Repository is a multi-file Python/Bash/HTML proof-of-concept lab for CVE-2026-64638, a claimed WordPress Core pre-auth reflected XSS that can be chained into administrator-assisted RCE. It is not just a detector: the repo includes a scanner (xss2shell_scanner.py), a safe checker (xss2shell_checker.py), a callback/beacon server (exploit_server.py), an interactive browser PoC page (xss_payload.html), and the main orchestration script (xss2shell_chain.py) that implements the attack workflow. The included Docker lab (docker-compose.yml, Makefile, test.sh) provisions WordPress 7.0.2 with MySQL and automates setup and testing. Main exploit capability: xss2shell_chain.py is the core entry point. Based on its CLI and surrounding documentation, it supports subcommands for scanning a target, generating an XSS URL, serving a callback page, creating an Application Password, uploading a malicious plugin, executing commands through that plugin, and running the full chain end-to-end. The chain’s intended flow is: identify vulnerable WordPress, trigger reflected XSS on /wp-login.php via the log parameter, leverage same-origin/admin context to obtain an Application Password, use WordPress REST API endpoints under /wp-json to install or upload a plugin, then invoke the uploaded PHP component for arbitrary command execution. The scanner/checker components are straightforward network/web probes: they fingerprint WordPress versions from /feed/, /readme.html, /wp-includes/wlwmanifest.xml, and /wp-login.php, then test whether a failed login reflects the submitted username. The callback server exposes /callback and /exploit, logs inbound beacons to callback.log, and serves a simple stage-2 HTML page that issues a fetch() beacon. The browser PoC page builds a malicious wp-login.php URL using a benign SVG/onload test vector to demonstrate reflection/XSS behavior. Overall purpose: provide an educational/lab environment demonstrating a web-to-browser-to-RCE chain against WordPress, with both reconnaissance and exploitation stages. The repository structure is coherent and operational, with automation for local testing and enough code to support plugin-upload and command-execution stages, even though the exact XSS bypass payload is described as not fully public in the documentation.

Single-file Python exploit PoC targeting CVE-2026-64638 against WordPress. The repository contains one executable script, poc.py, which implements a dual-mode attack chain named 'XSS2Shell'. Its purpose is to achieve authenticated plugin upload and remote code execution either by exploiting a pre-auth reflected XSS on the WordPress login page to steal an administrator application password, or by skipping the XSS stage and using operator-supplied credentials directly. Repository structure is minimal: one Python script with CLI handling, target fingerprinting, callback server logic, XSS detection, and exploitation routines. The script fingerprints WordPress versions using /readme.html, the homepage generator meta tag, and /wp-json/. It tests XSS behavior on /wp-login.php, then selects one of three modes: auto, xss, or direct. In auto mode it attempts XSS first and falls back to direct credential mode if the target appears patched and credentials were supplied. The exploit’s main capabilities are: (1) detect likely vulnerable WordPress instances, (2) host a local HTTP listener on 0.0.0.0 to receive exfiltrated application passwords or tokens at /collect, (3) leverage stolen or provided admin authentication material, (4) upload a malicious WordPress plugin ZIP, (5) activate the plugin, and (6) execute code on the server, including optional reverse-shell behavior. The callback handler explicitly looks for query/body parameters such as password, c, app_password, token, and user_login. This is not merely a detector; it is an operational exploit with an embedded exploitation workflow and payload staging. It is not part of a major framework like Metasploit or Nuclei. Based on the visible code and documentation, the exploit is best classified as OPERATIONAL: it contains a working attack chain and payload delivery logic, but not a highly modular framework-grade payload system.

This repository is a small PoC/lab package for CVE-2026-64638 targeting WordPress 7.0.2 login handling. The main exploit is poc.py, a standalone Python script that generates a local HTML PoC, starts a loopback-only HTTP proxy on 127.0.0.1:9100, and auto-submits a crafted POST request to wp-login.php. The injected username payload is malformed HTML designed to create an element with id=ajaxurl pointing to /__xss2shell_external.js and to mimic UI elements involved in the vulnerable flow. When the browser processes the vulnerable page, it requests attacker-controlled JavaScript from the local proxy, which serves a simple proof payload: alert('pwn by syuan!!!'). Exploit capability: browser-based XSS/code execution in the context of the WordPress login page, demonstrated by loading external JavaScript. The script also proxies upstream traffic to the real WordPress instance so the victim browser interacts with the target through the attacker-controlled local listener. Safety restrictions are built in: only http:// loopback targets are accepted. Repository structure: README.md contains a minimal raw requests-based reproduction example. poc.py is the primary exploit implementation. The wp-7.0.2-docker directory provides a disposable local lab environment using Docker Compose with MariaDB and WordPress 7.0.2, plus setup/test/fullchain/cleanup service definitions. Although some referenced helper scripts are not included in the provided file list, the compose files clearly show the intended purpose: reproducible local validation of the vulnerability and a browser-level full-chain demonstration. Overall, this is a real exploit PoC rather than a detector. It is operational but not heavily weaponized: the payload is fixed and demonstrates JavaScript execution rather than delivering a customizable post-exploitation framework.

Single-file Python exploit PoC targeting WordPress and labeled for CVE-2026-64638. The repository contains one executable script, poc.py, which implements a dual-mode attack chain: (1) XSS mode, where it fingerprints WordPress, checks whether the login flow appears vulnerable to a pre-auth XSS issue, starts a local HTTP callback server, and attempts to steal an admin application password/token via a reflected XSS payload; and (2) direct mode, where supplied administrator credentials are used immediately. In both cases the end goal is authenticated plugin upload leading to remote code execution on the WordPress server. The script includes WordPress fingerprinting helpers using /readme.html, the homepage generator meta tag, and /wp-json/. It binds a callback listener on 0.0.0.0 and exposes /collect to receive exfiltrated credentials. CLI logic supports auto mode that prefers the XSS chain when the target appears vulnerable and otherwise falls back to direct credential-based exploitation. Overall, this is an operational exploit rather than a detector: it performs target fingerprinting, credential theft/capture, authenticated abuse of the WordPress admin/plugin mechanism, and RCE delivery.

Repository is a small standalone Python PoC with 3 files: LICENSE, README.md, and the main exploit script xss2shell_poc.py. The README documents an educational exploit chain for CVE-2026-64638 against WordPress. The Python script implements the full workflow: validates the target by requesting /wp-login.php, starts a local HTTP server/listener, serves attacker-controlled browser content, tracks browser-side progress with beacon callbacks, abuses a pre-auth XSS/JSONP-style flow to obtain an administrator Application Password, stores captured credentials in xss2shell_creds.json, publishes a temporary page through the WordPress REST API, uploads a plugin containing a PHP shell under /wp-content/plugins/xss2shell/shell.php, verifies shell availability with a test command, then runs an operator-provided command and prints the output. Cleanup only removes the temporary page; the Application Password, plugin shell, and local credential file are intentionally preserved unless manually removed. This is a real exploit PoC rather than a detector, and it delivers practical post-exploitation capability via a basic uploaded web shell.

Repository is a self-contained educational exploit chain for CVE-2026-64638, described as a pre-auth reflected XSS in WordPress login that is escalated to RCE. The repo is not tied to a major exploit framework; it includes a CLI helper, a browser-based attacker orchestrator, a lightweight attacker HTTP server, and a PHP payload packaged as a WordPress plugin ZIP. Structure and purpose: exploit.py is the main CLI entry point. It builds the malicious log parameter for /wp-login.php, can verify whether the XSS survives in the login error page, and prints manual instructions for the full chain. attacker/index.html is the browser orchestrator that opens the admin approval page and a child window containing the XSS payload, then polls the attacker server for captured credentials and later verifies the uploaded shell. attacker/server.py is a standalone Python HTTP server that serves the lure page, receives the redirected Application Password at /callback or /callback.php, exposes capture state at /status or /status.php, and serves /payload.zip. PHP equivalents callback.php and status.php provide the same functionality if PHP hosting is preferred. payload/build_payload.py creates payload/payload.zip from payload.php and shell.php. Main exploit capability: the chain starts with a crafted username payload injected into wp-login.php via the log parameter. The payload uses DOM clobbering and a REST JSONP callback path (/?rest_route=/&_method=GET&_envelope=1&_jsonp=...) to achieve JavaScript execution in the WordPress origin. It then abuses SOME against /wp-admin/authorize-application.php to trigger approval of a new Application Password in an authenticated admin session. The attacker server captures the resulting site_url, user_login, and password. With that credential, the chain is intended to publish attacker-controlled content and upload a malicious plugin ZIP to WordPress. The final stage is direct invocation of /wp-content/plugins/payload/shell.php, which executes OS commands and returns JSON proving code execution. Payload behavior: shell.php sets header Hacked: true, runs whoami and id via system(), and returns JSON containing rce=true, user, id, host, PHP version, and timestamp. This is a basic hardcoded payload rather than a flexible framework module, so OPERATIONAL maturity is appropriate. Notable endpoints and artifacts: the exploit targets /wp-login.php, /wp-admin/authorize-application.php, /wp-admin/update.php?action=upload-plugin, /wp-json/wp/v2/pages, and /wp-content/plugins/payload/shell.php on the victim. On the attacker side it uses /, /callback(.php), /status(.php), and /payload.zip, and stores captured data in attacker/captured_credentials.txt and attacker/status.json. The docker-compose.yml provides a reproducible lab with WordPress 7.0.2 and MariaDB.

Repository is a small standalone Python PoC for a claimed WordPress Core vulnerability chain, CVE-2026-64638, consisting of 3 files: a .gitignore, a descriptive README, and one executable Python script (xss2shell.py). The script is the sole code artifact and acts as the CLI entry point. Purpose: demonstrate a pre-auth reflected XSS on wp-login.php that can be chained into higher-impact actions in an administrator’s browser and ultimately to server-side code execution by uploading a malicious plugin. The README describes a 5-stage chain: parser differential in login error reflection, DOM injection, autonomous click-handler abuse, same-origin POST/JSONP request, and final RCE via application-password abuse plus plugin upload. Capabilities implemented in the script: (1) check mode performs a non-destructive POST to /wp-login.php and inspects reflection behavior to determine likely vulnerability; (2) exploit mode generates an HTML form that submits a crafted log parameter to the target login page; (3) shell mode, per the visible code and README, uses an admin application password to interact with WordPress endpoints and upload/drop a plugin-based PHP webshell; (4) zip mode emits a plugin ZIP archive containing the PHP payload. The embedded PHP payload returns JSON and executes system('id'), indicating command execution capability, though the visible snippet shows only a basic hardcoded command rather than a fully interactive shell. Network/target focus: the exploit targets WordPress web endpoints, especially /wp-login.php, /wp-admin/authorize-application.php, /wp-json/wp/v2/pages, and plugin paths under /wp-content/plugins/. The XSS payload also references a same-origin REST route using /?rest_route=/&_method=GET&_jsonp=alert&_envelope=1. These are strong fingerprintable indicators for detection and hunting. Overall assessment: this is a real exploit PoC rather than a mere detector. It is not part of a larger exploitation framework. Maturity is operational: it includes working exploit stages and a concrete PHP payload, but the payload is basic and largely hardcoded rather than highly modular or framework-driven.