servd

Summary

On September 18th 2026, we remediated a critical security vulnerability in the Servd plugin. The vulnerability allowed an attacker to submit specially crafted data to a public-facing endpoint used for rendering dynamic content, which the plugin then deserialized without adequate validation. Under certain conditions, this could be used to achieve remote code execution.

From September 18th to September 20th, we deployed protections across our ingress infrastructure to prevent exploitation. We have released a patch for the Servd plugin (included in versions v4.2.7, v3.7.6, v2.11.7) that closes this vulnerability at the source. We are not aware of any ongoing exploitation as of writing.

Timeline

- September 18th - Vulnerability privately disclosed to us.
- September 18th - 20th - Infrastructure-level mitigation deployed across affected environments. Mitigation iteratively hardened against several bypass techniques prior to public disclosure.
- September 20th - Permanent fix release in v4.2.7, v3.7.6 and v2.11.7 of the Servd plugin.
- September 21st - Vulnerability was publicly disclosed.
 

What Was The Issue?

GET and POST requests to /actions/servd-asset-storage/dynamic-content/get-content or /index.php/actions/servd-asset-storage/dynamic-content/get-content plugin endpoint accepted a compressed, encoded data blob as a parameter and reconstructed it using PHP's native deserialization functionality. If an application deserializes attacker-controlled input without restricting which classes may be instantiated, an attacker can potentially trigger unintended code execution by chaining together classes already present in the application's dependencies.

We became aware of this issue through a private disclosure, and found evidence that it had been actively probed and, in for at least one customer, exploited in the wild.

What Did We Do?

Immediate mitigation: We deployed a patch at the infrastructure level across all affected hosting environments. This blocked the specific pattern of malicious requests at the network edge, ahead of any application code, without requiring individual customer action.

During this process we identified and closed several additional ways the initial mitigation could potentially be circumvented, through iterative testing against a range of encoding and obfuscation techniques.

Permanent fix: On 20th September 2026, we released v4.2.7, v3.7.6, and v2.11.7 of the Servd plugin, which restricts deserialization at the affected endpoint to plain data only, preventing any class instantiation regardless of the input supplied. This is the standard, recommended mitigation for this class of vulnerability and removes the risk entirely, independent of the infrastructure-level protections.

As part of the plugin patch, we also added additional constraints to the vulnerable plugin endpoint to disable it unless a project had specific settings enabled, thus reducing the attack surface of the Servd plugin going forward.

What Should You Do?

Upgrade to Servd plugin v4.2.7, v3.7.6, v2.11.7 or later as soon as possible. This is the definitive fix and we strongly recommend all customers running this plugin update immediately.

The infrastructure-level protections we deployed remain in place as a defence-in-depth measure, but should not be relied upon as a substitute for upgrading. If you have reason to believe your project may have been specifically targeted, or would like assistance reviewing your environment, please contact Servd support.

Was My Project Exploited?

From our investigations, only one customer was explicitly targeted in the wild. As of writing, there is no evidence to suggest any other projects have been exploited.

A project's Traffic Metrics page is a useful resource for determining whether it was targeted. These are the relevant views to pay attention to:

• /actions/servd-asset-storage/dynamic-content/get-content
• /index.php/actions/servd-asset-storage/dynamic-content/get-content

I can see GET requests

If your project has received GET requests to the above endpoints, and your site doesn't have ESI enabled (a non-public Servd static caching feature) then there is a strong chance you have been targeted.

At this point, we'd recommend downloading the logs for the last 30 days from your project's Logs page and find all requests to the above endpoints in the nginx log files. From there, you can inspect the blocks= query parameter value by passing it through the following PHP snippet:

zlib_decode(base64_decode(urldecode('<blocks query param value here>')));

I can see POST requests

If your project does not make use of the Servd plugin's {% dynamicInclude %} twig tags, but you see POST requests to the above endpoints then it's an indicator you have been targeted, but are not vulnerable. Only projects which use {% dynamicInclude %} tags are vulnerable to POST requests.

If your project does make use of the Servd plugin's {% dynamicInclude %} twig tags, we can't use traffic metrics to confirm an attack because the POST data that contains the malicious payload isn't logged by our systems. However, any large spikes in requests to the vulnerable endpoint outside of a corresponding increase in legitimate traffic could indicate an attack. If you believe your project may have been attacked, please contact Servd support.