Stored Blind XSS in Froxlor Failed Login Attempts Logging

This repository is a standalone Python PoC for CVE-2024-34070 affecting Froxlor before 2.1.9. It is not tied to a major exploit framework. The codebase is small and organized into reusable modules: `client.py` implements HTTP/session handling with cookies and optional insecure TLS; `detector.py` fingerprints Froxlor, optionally authenticates with supplied admin credentials, extracts version information, and determines whether the version is vulnerable; `payloads.py` builds the stored XSS JavaScript payload; `exploit.py` injects the payload through the login form and optionally verifies success by attempting login with the newly created admin account; `cli.py` exposes check and exploit modes; `main.py` is the executable entry point. The exploit capability is clear and actionable: it submits a malicious `loginname` value to the Froxlor login page so the payload is written to logs during a failed login attempt. When an administrator or automation bot later views those logs, the JavaScript executes in the admin context, extracts the CSRF token from the page, and POSTs to `/admin_admins.php` to create a new administrator account with extensive privileges. The tool can then poll by attempting to log in as that new admin. This makes the repository more than a detector; it is an operational exploit with a hardcoded but user-configurable account-creation payload. Fingerprintable targets and behaviors include requests to `/`, `/admin_index.php`, and `/admin_admins.php`, Froxlor-specific HTML markers such as `templates/froxlor/`, parsing of `docs.froxlor.org` version references, and a custom User-Agent string `CVE-2024-34070-PoC/1.0`. The exploit is web-based and depends on a vulnerable Froxlor deployment plus an admin log-viewing event for stored XSS execution.

This repository is a small standalone Python exploit for CVE-2024-34070 affecting Froxlor. It contains one executable script (CVE.py) and a brief README. The Python script uses requests, urllib parsing helpers, time, BeautifulSoup import (unused), and colorized console output. Its main workflow is: prompt for target URL, desired username, and password; check whether those credentials already work; submit a crafted POST request to the target login endpoint; and optionally poll the login endpoint every 10 seconds to see whether the new account becomes active. The core exploit is a malicious value placed in the loginname POST parameter. That value contains a URL-encoded JavaScript payload using template/injection syntax intended to trigger XSS in Froxlor. When rendered/executed in an authenticated admin browser session, the payload reads the CSRF token from a meta tag and issues an XMLHttpRequest POST to /admin_admins.php with a large set of form parameters that create a new administrator account and grant broad privileges. The attacker-controlled username and password are embedded into that request. This makes the exploit an account-creation/privilege-establishment exploit rather than a shell-dropping or code-execution exploit. Notable logic: send_payload() performs the POST and returns status code plus Location header; check_account_exist() tests whether the supplied credentials already authenticate; exploit() builds and sends the XSS payload and interprets a 302 redirect to index.php?showmessage=2 as successful submission; looping_log() repeatedly attempts login until it sees a redirect to admin_index.php, indicating the account was created successfully. There is no generalized payload customization framework, no detection-only behavior, and no destructive fake behavior. The exploit is operational but basic, with hardcoded assumptions about Froxlor paths, redirect behavior, and form fields.

Single-file Python exploit targeting CVE-2024-34070 in Froxlor. The repository contains one script, CVE.py, which uses requests for HTTP interaction, BeautifulSoup is imported but unused, and colorama is used only for console output formatting. The script is interactive: it prompts for a target URL, desired username, and password. It first checks whether the supplied credentials already work against the target login endpoint. If not, it submits a crafted POST request where the loginname field contains a URL-encoded JavaScript stored-XSS payload. That payload, when later executed in an authenticated administrator's browser, extracts the CSRF token from a meta tag and issues a POST request to the Froxlor admin management endpoint admin_admins.php to create a new administrator account with broad privileges. After submission, the script can optionally poll the login endpoint every 10 seconds until the new credentials redirect to admin_index.php, indicating success. Overall, this is a real exploit rather than a detector: it weaponizes a stored XSS into admin account creation on a vulnerable web application.