db
database
MariaDB 10.6 database service for WordPress, configured with root password, database, and user credentials via environment variables. Data persisted in a named volume.
docker-compose.yml:2-12khaifunglee/reproducing-CVE-2025-1489
PoC files
6 filesFile viewing is interactive and short-lived. Downloads are password-protected ZIP archives using password eip.
Analysis
Technical assessment
The artifact sets up a Docker environment to reproduce CVE-2025-1489, a stored XSS vulnerability in the WP-Appbox WordPress plugin. It includes an attacker-controlled HTTP server (server.py) designed to log inbound GET requests, which serves as a detection mechanism to confirm the vulnerability by observing callbacks triggered by the injected payload. The README describes the steps to create a malicious shortcode, but the actual exploit payload is not provided in the supplied text files.
Backdoor review
No backdoor observed in reviewed code
The reviewed text files (README.md and attacker/server.py) describe a legitimate proof-of-concept for CVE-2025-1489, a stored XSS vulnerability in the WP-Appbox WordPress plugin. The server.py script is a simple HTTP server designed to log incoming requests, which is standard behavior for demonstrating an out-of-band XSS callback. No concealed, deceptive, or operator-directed harmful behavior is present in the supplied text.
ClassificationScanner
Model confidence90%
AuthenticationRequired
Languages
Target software
Attack types
Evidence & reasoningClassification basis · observed behavior · safety review
Classification basis and observed behavior
Classification basis
The artifact is classified as a scanner because its primary operation, as evidenced by the provided code, is to set up a detection environment. The attacker server (server.py) is designed to log HTTP requests, which would serve as a callback to confirm the presence of the vulnerability. The README describes the vulnerability and the steps to trigger it, but the actual exploit payload is not present in the supplied text files. The code does not autonomously exploit the vulnerability; it provides a mechanism to observe whether a manually crafted payload succeeds.
attacker/server.py:1-41README.md:1-55Requirements
- An authenticated WordPress user with at least Author role privileges is required to create a post containing the malicious shortcode.
README.md:53-55 - The WP-Appbox plugin version 4.5.4 must be installed and activated on the target WordPress instance.
README.md:33README.md:52
Observed behavior
- The attacker server (server.py) listens on port 8000 and logs the client IP, request line, Referer, and User-Agent for every incoming GET or HEAD request to a log file.
attacker/server.py:18-28 - The README instructs the user to craft a malicious shortcode payload to trigger the XSS, but the specific payload is not included in the provided text files.
README.md:55
Behaviors behind the backdoor verdict
Observables
- Http Server
- HTTPServer on 0.0.0.0:8000The server is configured to log all incoming GET and HEAD requests, including Referer and User-Agent headers, to a file. This is consistent with capturing XSS callbacks for a proof-of-concept.
attacker/server.py:18-28attacker/server.py:38-41 - File Logging
- /srv/requests.logLogged data is written to a local file, which is standard for recording proof-of-concept results. No exfiltration or persistence mechanism is implemented.
attacker/server.py:6attacker/server.py:12-14
What the analysis did not establish
- The full_report.pdf binary file is flagged as uninspected and may contain the actual exploit payload or further details.
- The text file attacker/test.py is listed as unavailable as text and its content is unknown.
- The README.md file ends abruptly at line 55, and the subsequent steps for crafting the malicious payload are not included in the provided text.
- The file full_report.pdf (912023 bytes) is a binary document and was not analyzed. Its content is unknown.
- The file attacker/test.py is listed in the inventory but its content was not supplied and is unavailable as text.
- Three additional text files are present in the repository but were not included in the evidence packet.
Model interpretation
This review is limited to the supplied PoC code and context. It does not assert that the code works or is safe to execute.
Docker lab environments
1GitHubdocker-compose.yml
Created Vuln labCVE-2025-1489Compose · images
Analysis
Environment assessment
A Docker Compose environment with three services: a MariaDB database, a WordPress instance with a vulnerable WP-Appbox plugin, and an attacker Python HTTP server for logging callbacks. The environment is designed to reproduce CVE-2025-1489, a stored XSS vulnerability in WP-Appbox 4.5.4.
docker-compose.yml:1-48README.md:1-55Lab assessment
Vulnerability labThe README explicitly states the repository simulates reproduction of CVE-2025-1489, a stored XSS in WP-Appbox 4.5.4. The Compose file sets up a WordPress target with the vulnerable plugin mounted and an attacker service to log callbacks, consistent with a vulnerability research exercise.
README.md:1-3docker-compose.yml:1-48Lab shapeCompose · images
Services3
Compose manifests1
Dockerfiles0
Evidence & reasoningComponents · CVE assessment · exercise context · review boundaries
Services and files described by the evidence
wordpress
vulnerable target
WordPress 6.4 with PHP 8.1 and Apache, connected to the db service. The vulnerable WP-Appbox 4.5.4 plugin is bind-mounted from the host into the plugins directory. Exposes port 8000 on the host.
docker-compose.yml:14-28README.md:5-7attacker
callback listenerHTTP server
Python 3.11 slim container running a custom HTTP server (server.py) that logs incoming requests, including Referer and User-Agent headers, to a file. Serves files from /srv and listens on port 8000, mapped to host port 8001.
docker-compose.yml:30-38attacker/server.py:1-41How the supplied evidence relates each vulnerability
CVE-2025-1489
Supported by supplied evidence
The README describes the vulnerability as stored XSS in WP-Appbox 4.5.4 due to insufficient sanitization, and the Compose file mounts that exact plugin version into WordPress. The attacker service is set up to log callbacks, consistent with demonstrating the XSS.
README.md:5-7docker-compose.yml:24Requirements and sequence described by the evidence
Prerequisites
- Docker Desktop installed on host
README.md:33 - svn installed on host to checkout WP-Appbox 4.5.4
README.md:33 - WP-Appbox 4.5.4 plugin source placed in ./source/wp-appbox-4.5.4
README.md:36-38docker-compose.yml:24
Evidence-described exercise path
- Checkout WP-Appbox 4.5.4 plugin using svn into ./source/wp-appbox-4.5.4
README.md:36-38 - Start Docker lab with docker-compose up -d
README.md:40-42 - Access WordPress at localhost:8000, create admin user, activate WP-Appbox plugin, create attacker user with Author role
README.md:44-48 - Login as attacker user, create a post with a malicious shortcode to trigger stored XSS, observe callback logged by attacker service
README.md:50
Behaviors behind the stored safety assessment
No harmful behavior observed
All visible behavior is directed at the lab's own target (WordPress with vulnerable plugin) and the attacker service only logs incoming HTTP requests. No host escape, external connections, persistence, credential theft, or destructive actions are observed. Port mappings and bind mounts are necessary for the exercise.
docker-compose.yml:1-48attacker/server.py:1-41What the analysis did not establish
- full_report.pdf is a binary file and was not inspected
- attacker/test.py is empty and provides no additional evidence
- attacker/requests.log is empty and provides no additional evidence
- The actual exploit payload is not included in the supplied evidence
Model interpretation
This review is limited to the supplied lab evidence packet. It does not assert that the environment runs, reproduces a vulnerability, or is safe to execute. Contract: eip-docker-lab-analysis-v1.