Scripting — CraftedSignal Threat Feed

XWiki Remote Code Execution via Unprotected Velocity Scripting API

hello@craftedsignal.io — Wed, 08 Apr 2026 15:00:17 +0000

XWiki versions before 17.4.8 and 17.10.1 are susceptible to remote code execution (RCE) due to an improperly protected Velocity scripting API. This vulnerability, identified as CVE-2026-33229, allows users with existing script rights to bypass the intended sandboxing mechanisms of the Velocity scripting API. By exploiting this flaw, attackers can execute arbitrary code, including potentially malicious Python scripts, on the XWiki instance. This vulnerability allows an attacker to gain complete control over the XWiki instance, compromising the confidentiality, integrity, and availability of the system and its data. The issue has been addressed in XWiki versions 17.4.8 and 17.10.1 by enforcing a requirement for programming rights to access the vulnerable API.

Attack Chain

An attacker gains script rights within the XWiki instance, either through compromised credentials or misconfigured permissions.
The attacker crafts a malicious request leveraging the unprotected Velocity scripting API.
This request bypasses the intended sandboxing of the Velocity scripting engine.
The attacker injects arbitrary code, such as a Python script, into the Velocity template.
The Velocity engine executes the injected code on the XWiki server.
The attacker gains arbitrary code execution privileges on the server.
The attacker leverages the code execution to install a web shell.
Using the web shell, the attacker gains complete control over the XWiki instance, enabling data theft, modification, or denial of service.

Impact

Successful exploitation of this vulnerability grants attackers complete control over the XWiki instance. This can lead to the theft of sensitive data stored within the XWiki, unauthorized modification of existing data, or a complete denial of service. While the exact number of potential victims is unknown, any XWiki instance running a vulnerable version is at risk, particularly those where script rights are broadly assigned. This vulnerability has the potential to severely impact organizations relying on XWiki for critical business functions.

Recommendation

Upgrade XWiki instances to version 17.4.8 or 17.10.1 or later to patch CVE-2026-33229.
Implement the Sigma rule “Detect Suspicious XWiki Velocity Scripting API Usage” to identify potential exploitation attempts.
Review and restrict script rights assignments within XWiki to minimize the attack surface, as mentioned in the overview.

Windows Script Execution from Archive File

hello@craftedsignal.io — Wed, 24 Jan 2024 12:00:00 +0000

Attackers commonly use archive files (ZIP, RAR, 7z) to deliver malicious scripts, such as JScript and VBScript, to Windows systems. This technique allows them to bypass some initial security checks and deliver payloads that can execute arbitrary code. The “Windows Script Execution from Archive” detection identifies instances where Windows Script Host (wscript.exe) is launched from temporary directories containing extracted archive contents. This activity can indicate a user has opened a malicious archive, leading to potential malware execution. This detection focuses on the parent-child process relationship, where explorer.exe, winrar.exe, or 7zFM.exe spawns wscript.exe to execute scripts from the temp directory.

Attack Chain

A user receives a malicious archive file (e.g., ZIP, RAR, 7z) via email or downloads it from a website.
The user opens the archive file using a file archiver tool like Explorer, WinRAR, or 7-Zip.
The archiver extracts the contents, including a malicious JScript (.js) or VBScript (.vbs) file, to a temporary directory, such as \Users\*\AppData\Local\Temp\7z*\.
The user (or the archiver tool) inadvertently executes the extracted script using Windows Script Host (wscript.exe).
Wscript.exe executes the malicious script, which may perform a variety of actions, such as downloading and executing additional payloads.
The script establishes persistence via registry modification, adding a run key to execute upon system startup.
The script connects to a command-and-control server to receive further instructions.
The attacker gains control of the compromised system and begins lateral movement.

Impact

A successful attack of this nature can lead to arbitrary code execution on the victim’s machine, potentially resulting in data theft, malware installation, or complete system compromise. While the number of affected organizations is not specified, the technique is broadly applicable to any Windows environment where users handle archive files, potentially affecting numerous individuals and organizations across various sectors.

Recommendation

Enable process creation logging with command line arguments to capture the execution of wscript.exe and its arguments.
Deploy the Sigma rule “Detect Script Execution from Archive” to your SIEM to identify suspicious script execution patterns.
Monitor process activity for wscript.exe and other scripting engines executing from temporary directories.
Configure endpoint security solutions to block execution of scripts from common temporary directories.

Execution of a Downloaded Windows Script

hello@craftedsignal.io — Wed, 03 Jan 2024 12:00:00 +0000

This detection rule identifies a common attack vector where adversaries download and execute malicious scripts on Windows systems. The rule focuses on detecting scripts (e.g., .js, .vbs, .ps1, .msi) that originate from internet sources (identified by the presence of file.origin_url or file.origin_referrer_url ) and are subsequently executed using scripting utilities. The rule specifically looks for file creations by web browsers and archive utilities (chrome.exe, msedge.exe, winrar.exe, 7zFM.exe, etc.) followed by execution of script interpreters (wscript.exe, cscript.exe, powershell.exe, mshta.exe, msiexec.exe) with command-line arguments referencing the downloaded script. This activity is often indicative of malicious intent, as legitimate scripts are typically sourced from trusted internal repositories or local file systems, and not directly downloaded and executed. The rule aims to detect suspicious parent-child process relationships (e.g., browser spawning a script interpreter) and identify potential initial access or execution attempts. The rule requires Elastic Defend and a minimum Elastic Stack version of 9.2.0.

Attack Chain

A user browses to a malicious website or opens a compromised email containing a link.
The user clicks the link, which initiates a download of a malicious script file (e.g., .js, .vbs, .ps1, .msi) via a web browser (chrome.exe, msedge.exe).
The browser saves the downloaded script file to the user’s Downloads folder.
The user, either intentionally or through social engineering, executes the downloaded script.
Windows executes the script using a scripting utility like wscript.exe, cscript.exe, powershell.exe, mshta.exe, or msiexec.exe.
The scripting utility executes the malicious code within the script, potentially establishing persistence, downloading additional payloads, or performing reconnaissance.
The script may attempt to elevate privileges or bypass security controls to gain further access to the system.
The attacker achieves their objective, such as deploying ransomware, stealing sensitive data, or establishing a remote access backdoor.

Impact

A successful attack can lead to a variety of negative outcomes, including malware infection, data theft, and system compromise. If the downloaded script is malicious, it can allow attackers to gain a foothold on the system, escalate privileges, and move laterally within the network. This can result in significant financial losses, reputational damage, and disruption of business operations. The number of victims and affected sectors can vary depending on the scale and scope of the attack.

Recommendation

Deploy the Elastic Defend integration to collect necessary event data, as described in the setup instructions.
Deploy the Sigma rule “Execution of a Downloaded Windows Script” to your SIEM and tune for your environment to detect the execution of downloaded scripts.
Enable Sysmon process creation logging and file creation events to provide the necessary data for the Sigma rules to function correctly.
Implement application whitelisting to restrict the execution of unauthorized scripts and scripting utilities to reduce the risk of similar threats in the future, as mentioned in the “Response and remediation” section.
Block known malicious domains and URLs identified in related threat intelligence feeds to prevent users from downloading malicious scripts in the first place.
Educate users about the dangers of downloading and executing untrusted scripts from the internet, as this is a common initial access vector.