<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Velocity — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/tags/velocity/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata — refreshed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Wed, 08 Apr 2026 15:00:17 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/tags/velocity/feed.xml" rel="self" type="application/rss+xml"/><item><title>XWiki Remote Code Execution via Unprotected Velocity Scripting API</title><link>https://feed.craftedsignal.io/briefs/2026-04-xwiki-rce/</link><pubDate>Wed, 08 Apr 2026 15:00:17 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-04-xwiki-rce/</guid><description>XWiki is vulnerable to remote code execution due to an improperly protected scripting API, allowing users with script rights to bypass the Velocity scripting API sandbox and execute arbitrary code, leading to full instance compromise.</description><content:encoded><![CDATA[<p>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.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains script rights within the XWiki instance, either through compromised credentials or misconfigured permissions.</li>
<li>The attacker crafts a malicious request leveraging the unprotected Velocity scripting API.</li>
<li>This request bypasses the intended sandboxing of the Velocity scripting engine.</li>
<li>The attacker injects arbitrary code, such as a Python script, into the Velocity template.</li>
<li>The Velocity engine executes the injected code on the XWiki server.</li>
<li>The attacker gains arbitrary code execution privileges on the server.</li>
<li>The attacker leverages the code execution to install a web shell.</li>
<li>Using the web shell, the attacker gains complete control over the XWiki instance, enabling data theft, modification, or denial of service.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>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.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade XWiki instances to version 17.4.8 or 17.10.1 or later to patch CVE-2026-33229.</li>
<li>Implement the Sigma rule &ldquo;Detect Suspicious XWiki Velocity Scripting API Usage&rdquo; to identify potential exploitation attempts.</li>
<li>Review and restrict script rights assignments within XWiki to minimize the attack surface, as mentioned in the overview.</li>
</ul>
]]></content:encoded><category domain="severity">high</category><category domain="type">advisory</category><category>xwiki</category><category>rce</category><category>velocity</category><category>scripting</category><category>CVE-2026-33229</category></item><item><title>OpenMRS Stored Velocity SSTI to RCE via ConceptReferenceRange</title><link>https://feed.craftedsignal.io/briefs/2024-01-openmrs-ssti/</link><pubDate>Wed, 03 Jan 2024 12:00:00 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2024-01-openmrs-ssti/</guid><description>OpenMRS is vulnerable to a Stored Velocity SSTI to RCE via ConceptReferenceRange, where the `ConceptReferenceRangeUtility.evaluateCriteria()` method evaluates database-stored criteria strings as Apache Velocity templates without a sandbox, allowing unrestricted Java reflection through template expressions, leading to persistent remote code execution and privilege escalation when a user with the `Manage Concepts` privilege stores a malicious Velocity template expression in a concept's reference range criteria field.</description><content:encoded><![CDATA[<p>OpenMRS is vulnerable to a critical security flaw stemming from the unsafe use of Apache Velocity templates. Specifically, the <code>ConceptReferenceRangeUtility.evaluateCriteria()</code> method processes database-stored criteria strings as Velocity templates without any sandbox restrictions. This allows for unrestricted Java reflection through template expressions. A user possessing the <code>Manage Concepts</code> privilege can inject a malicious Velocity template expression into a concept&rsquo;s reference range criteria field. This payload will then execute automatically whenever a user or an API call validates an observation against the compromised concept. This issue impacts OpenMRS versions 2.7.0 through 2.7.8, and 2.8.0 through 2.8.5. Successful exploitation allows an attacker to escalate privileges from content management to arbitrary code execution as the Tomcat application server process, with the potential for exfiltration of protected health information (PHI). The vulnerability is identified as CVE-2026-41258.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>An attacker gains access to an OpenMRS account with the <code>Manage Concepts</code> privilege.</li>
<li>The attacker navigates to the concept dictionary management interface.</li>
<li>The attacker locates a commonly used concept, such as one for a standard clinical measurement.</li>
<li>The attacker modifies the concept and injects a malicious Velocity template expression into the concept&rsquo;s reference range criteria field. The expression leverages Java reflection to execute arbitrary code.</li>
<li>The malicious template is saved and stored in the <code>concept_reference_range</code> database table.</li>
<li>A user or API call validates an observation against the affected concept, triggering the execution of the stored Velocity template.</li>
<li>The attacker achieves arbitrary code execution within the context of the Tomcat application server process.</li>
<li>The attacker can then perform actions such as installing a web shell for persistent access or exfiltrating patient data.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of this vulnerability allows for persistent remote code execution on the OpenMRS server. The injected payload persists within the <code>concept_reference_range</code> database table (VARCHAR 65535). A single compromised concept, especially one used for common clinical measurements, can lead to the execution of the malicious payload on every subsequent observation validation across all users, API clients, and integrations. This affects all facilities using the compromised OpenMRS instance. The attacker can escalate privileges from content dictionary management to arbitrary code execution and potentially exfiltrate PHI data.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Upgrade OpenMRS to version 2.8.6 or 2.7.9 or later to patch CVE-2026-41258.</li>
<li>Restrict the <code>Manage Concepts</code> privilege to only authorized users, as mentioned in the advisory&rsquo;s workarounds.</li>
<li>Deploy the provided Sigma rule detecting Velocity template injection attempts to your SIEM and tune for your environment.</li>
<li>Implement database monitoring to detect unauthorized modifications to the <code>concept_reference_range</code> table to identify potential exploitation attempts.</li>
</ul>
]]></content:encoded><category domain="severity">critical</category><category domain="type">advisory</category><category>ssti</category><category>rce</category><category>velocity</category><category>openmrs</category></item></channel></rss>