SURIQ
If you run Apache Roller and you think switching off XML-RPC keeps you safe from CVE-2026-82384, it does not. This is a critical, pre-authentication remote code execution (RCE) flaw, scored 9.8 out of 10, in Roller's XML-RPC endpoint, and that endpoint keeps answering even when the feature is turned off in configuration. The only change that removes the risk is upgrading to Roller 6.1.6. Apache published the advisory on September 28, 2026, and named version 6.1.5 as affected. No public exploit exists yet, which makes this a rare quiet window to patch before one shows up.
What CVE-2026-82384 actually is
Roller exposes an XML-RPC endpoint at /roller-services/xmlrpc for older blog-client tools. That servlet parses each incoming request before it checks who is asking. Per the CVE record, it accepts vendor-specific value types and rebuilds their bytes into live objects during that parse. A remote attacker with no account can send a request that triggers the object rebuild, and with the right classes present on the server's classpath, that rebuild becomes code execution. The bug class is deserialization of untrusted data, CWE-502, the same family behind years of Java server compromises. Apache rates it 9.8.
Why "just disable XML-RPC" is the wrong answer
The instinct on any XML-RPC bug is to switch the feature off. WordPress admins have done it for years. On Roller 6.1.5 that instinct fails, and this is the detail most coverage will skip past. The servlet is wired into the application on a fixed path whether or not the XML-RPC feature flag is set. Flip webservices.enableXmlRpc to false and the endpoint still receives and parses the request, so the vulnerable path runs regardless. The fix in 6.1.6 does two separate things: it stops the servlet from accepting the risky extension types, and it adds a filter that turns away calls once the feature flag is off. Configuration on 6.1.5 cannot reproduce either change.
The upgrade trap: 6.1.5 was the safe version five months ago
Here is the uncomfortable part. Version 6.1.5 shipped in April 2025 to fix a separate maximum-severity bug, CVE-2025-24859, where a session stayed valid after a password change. Administrators who did the responsible thing and upgraded then are sitting on exactly the release this new flaw names. Closing one hole put them in front of the next. It is a good argument for treating 6.1.6 as urgent rather than routine: the people most exposed today are the ones who patched last time.
Who is exposed, and is it being exploited
Apache Roller is a Java blogging server used for standalone and multi-user blogs, including some run by large organizations and by Apache projects themselves. It is not WordPress-scale, but every internet-facing instance on 6.1.5 with that endpoint reachable is a candidate. As of September 28, 2026, we found no public proof-of-concept exploit and no report of exploitation in the wild, and the flaw is not in CISA's Known Exploited Vulnerabilities catalog. That state rarely lasts: a pre-auth deserialization bug with a public fix commit tends to attract exploit developers quickly, and this commit is already public. Remote code execution is not a fringe risk here either. Command injection and remote code execution together are the second-heaviest bug class in our own triage ledger over the past 90 days, 2,198 of them, behind only cross-site scripting. It is the same failure mode we have covered in a fastjson flaw that fired in the default configuration and a Jackson library issue, and it is why a pre-auth trigger on a server-side app always earns a fast response, as it did with the WHMCS RCE earlier this quarter.
Detect probes against the endpoint
Until you have upgraded, watch for requests to the XML-RPC path. On 6.1.5 any POST to /roller-services/xmlrpc reaches the parser before authentication, so unexpected POSTs there, especially from unfamiliar addresses, are worth pulling apart. If Roller sits behind Apache httpd, LiteSpeed, or nginx, the request shows in that server's access log; behind a control panel the log path follows the panel's per-site convention.
grep -E '"POST /roller-services/xmlrpc' /var/log/apache2/access.log grep -E '"POST /roller-services/xmlrpc' /usr/local/lsws/logs/access.log
Upgrade to 6.1.6, and do not trust the config switch
Three steps, in order:
- Move to Apache Roller 6.1.6 or newer. This is the only change that removes the vulnerable path. Apache's advisory points to the fixed release.
- Do not rely on disabling XML-RPC. On 6.1.5 the flag does not unmap the servlet, so it is not a mitigation, only a reduction of intended functionality.
- If you cannot upgrade at once, block the path at the edge. A reverse proxy or web-server rule that denies requests to
/roller-services/xmlrpckeeps the parser from ever seeing them. Treat it as a stopgap, not a fix, and upgrade as soon as you can.
The clean part of this story is the timing. There is a patch, and there is no exploit yet. That order rarely holds for long on a pre-auth deserialization bug, so the window to move calmly is right now.