CVE-2025-58365

Executive Summary

CVE-2025-58365 is a critical remote code execution (RCE) vulnerability in the XWiki Blog Application, affecting versions prior to 9.14. The flaw allows any authenticated user with edit rights on any page (typically all logged-in users, as they can edit their own user profile) to execute arbitrary code on the server. The vulnerability resides in the blog application's handling of Blog.BlogPostClass objects, where the "Content" field is processed without proper authorization checks, enabling the injection of script macros. This can lead to full server compromise, data exfiltration, and lateral movement within the XWiki environment. The patch, introduced in version 9.14, mitigates the issue by executing blog post content with the rights of the appropriate author, preventing privilege escalation.

Supply Chain & Package Security

This vulnerability is specific to the XWiki Blog Application, an extension for the XWiki platform. It is not a direct supply chain issue with XWiki core, but it affects users who have installed the blog application. Organizations should verify their XWiki instance's blog application version and ensure it is updated to 9.14 or later. No known malicious packages or compromised dependencies are associated with this CVE.

CVSS Breakdown & Threat Level

• CVSS Score: 9.9 (Critical)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (authenticated user with edit rights)
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: High
• Availability Impact: High

Threat Level: Critical. The low attack complexity and low privileges required make this vulnerability highly exploitable. Any authenticated user can achieve full RCE, leading to complete compromise of the XWiki instance.

Deep Dive & Mechanics

The vulnerability is a classic case of improper input validation and authorization in a web application. The XWiki Blog Application allows users to create blog posts by adding an object of type Blog.BlogPostClass to any page. The "Content" field of this object is intended to hold the blog post's content, but it is processed by the XWiki rendering engine, which supports script macros (e.g., {{velocity}}, {{groovy}}). Prior to version 9.14, the blog application did not enforce proper authorization checks when rendering the content of blog posts. This means that any user with edit rights on a page (which includes all logged-in users, as they can edit their own user profile) could create a blog post object containing malicious script macros. When the blog post is rendered (viewed by any user, including administrators), the malicious code executes with the privileges of the rendering user, leading to RCE.

The root cause is the lack of a security check to ensure that the content of a blog post is executed with the rights of the author, not the viewer. The patch in version 9.14 addresses this by executing the content with the rights of the appropriate author, preventing privilege escalation.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-9.14): The blog application likely used a generic rendering call without specifying the author context. For example, in a Velocity template:

{{velocity}}
#set ($blogPost = $doc.getObject("Blog.BlogPostClass"))
$blogPost.getValue("content")
{{/velocity}}

This renders the content with the current user's rights.

Patched Code (9.14): The patched version explicitly sets the author context to the blog post's author before rendering:

{{velocity}}
#set ($blogPost = $doc.getObject("Blog.BlogPostClass"))
#set ($author = $blogPost.getValue("author"))
$services.rendering.render($blogPost.getValue("content"), "xwiki/2.1", $author)
{{/velocity}}

This ensures the content is executed with the author's rights, preventing privilege escalation.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an XWiki instance with the blog application installed (version < 9.14).
• A valid user account with edit rights on any page (e.g., the user's own profile).

Exploit Steps:

1. Log in to XWiki.
2. Navigate to a page you can edit (e.g., your user profile page).
3. Add an object of type Blog.BlogPostClass to the page.
4. In the "Content" field, inject a malicious script macro. For example, to execute a system command:

   {{velocity}}
   #set ($cmd = "id")
   #set ($result = $services.scripting.eval("java.lang.Runtime.getRuntime().exec('$cmd')"))
   {{/velocity}}
   

5. Save the page.
6. View the page (or have an administrator view it) to trigger the RCE.

Alternative Payload (Groovy):

{{groovy}}
println "pwned"
{{/groovy}}

Blue Team

Detection:

• Monitor for unusual script macro usage in blog post content.
• Look for Blog.BlogPostClass objects being added to pages that are not typically used for blogging (e.g., user profiles).
• Audit user activity for creation of blog posts by non-blog users.

Hunting:

• Search XWiki logs for rendering errors or script execution events.
• Use the following XWiki query to find potentially malicious blog posts:

  SELECT doc.fullName, obj.content FROM XWikiDocument doc, BaseObject obj WHERE obj.className = 'Blog.BlogPostClass' AND obj.content LIKE '%{{velocity%' OR obj.content LIKE '%{{groovy%'
  

Lab Setup:

• Deploy a vulnerable XWiki instance (e.g., version 8.x) with the blog application.
• Create a test user with edit rights.
• Follow the Red Team steps to confirm the vulnerability.
• Apply the patch (upgrade to 9.14) and verify the fix.

Indicators of Compromise (IOCs)

• Network: Outbound connections from the XWiki server to unknown IPs (e.g., for data exfiltration).
• File System: Unexpected files in the XWiki data directory (e.g., /var/lib/xwiki/data/).
• Logs: XWiki logs showing script execution errors or unusual rendering activity.
• Process: Unusual child processes spawned by the Java process (e.g., id, whoami, curl).
• User Accounts: Creation of new admin accounts or modification of existing ones.
• Database: Unauthorized changes to XWiki database tables (e.g., XWikiDocument, XWikiUser).

Detection Engineering

YARA Rule

rule CVE_2025_58365_XWiki_Blog_RCE {
    meta:
        description = "Detects malicious blog post content exploiting CVE-2025-58365"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-58365"
    strings:
        $s1 = "Blog.BlogPostClass" ascii wide nocase
        $s2 = "{{velocity" ascii wide nocase
        $s3 = "{{groovy" ascii wide nocase
        $s4 = "Runtime.getRuntime()" ascii wide nocase
        $s5 = "exec(" ascii wide nocase
    condition:
        $s1 and ($s2 or $s3) and ($s4 or $s5)
}

Sigma Rule

title: XWiki Blog Application RCE via Script Macro
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects exploitation of CVE-2025-58365 in XWiki Blog Application
author: Valters IT
date: 2025-04-10
logsource:
    category: application
    product: xwiki
detection:
    selection:
        EventID: "RENDERING_ERROR"
        Message|contains:
            - "Blog.BlogPostClass"
            - "{{velocity"
            - "{{groovy"
    condition: selection
falsepositives:
    - Legitimate use of script macros in blog posts by authorized users
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2025-58365 XWiki Blog RCE Exploit"; flow:to_server,established; content:"Blog.BlogPostClass"; http_client_body; nocase; content:"{{velocity"; http_client_body; nocase; content:"exec("; http_client_body; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Update the XWiki Blog Application to version 9.14 or later.
2. Restrict Edit Rights: Temporarily disable edit rights for non-admin users if upgrade is not immediately possible.
3. Audit: Review all existing blog posts for malicious content.

Long-term Mitigations:

• Implement strict input validation and output encoding for all user-generated content.
• Use the principle of least privilege for user roles.
• Enable XWiki's built-in security features, such as script macro restrictions.
• Regularly update all XWiki extensions.

Workarounds:

• No known workarounds are available. The only effective mitigation is to apply the patch.

Valters IT