raytha-cms-functions-rce-cve-2025-15540

Raytha CMS “functions” feature leads to authenticated RCE (CVE-2025-15540) — privileged users could spawn .NET components

What happened

The security report, published 1 hour ago, says Raytha CMS contains an authenticated remote code execution vulnerability tracked as CVE-2025-15540.

Specifically, the bug lives in Raytha’s “functions” module where privileged users can write custom JavaScript, and because the feature lacks sandboxing or proper access restrictions, that JavaScript can instantiate .NET components and perform arbitrary operations in the host environment. The advisory rates the issue Severity 8.6, HIGH, and the vendor fixed it in version 1.4.6.

Who was affected has not been disclosed beyond users running Raytha versions prior to 1.4.6, and there are no confirmed public reports of active exploitation in the wild at the time of the advisory. How organisations discovered the flaw is not detailed in the notice.

Why this matters to businesses

Since Raytha CMS is a content management system, any organisation running it, or using hosted services built on it, could face severe consequences if attackers or rogue insiders abused the functions module.

Following an RCE, businesses can expect downtime while systems are isolated and forensic work is done, potential data theft, legal exposure if personal data is involved and expensive recovery costs. Boards will want answers fast, and regulators may ask why privileged code execution paths were left open.

Also, given how many teams treat admin features like optional safety nets, here’s the blunt point, patch later thinking will bite you, especially when privileged users can upload code.

If you’ve got the same weakness, here’s what happens next

If an attacker can run code via the functions module, they can drop backdoors, move laterally, or tamper with stored data, all while looking like a privileged user. That quiet persistence is the worst part, because it turns small holes into long-term footholds.

Alternatively, a malicious insider with access to functions could export sensitive records or change application behaviour, creating integrity risks that are hard to unwind. Recovery can spiral into expensive rebuilds, legal reviews and lost customer trust, even if no obvious dump appears.

What to do on Monday morning

• Apply the vendor fix, upgrade Raytha to version 1.4.6 immediately where possible, or isolate the WebUI that exposes the functions feature until you can patch.

• Review who has privileged access to the functions module and revoke any unnecessary accounts, enforce least privilege and remove shared admin accounts.

• Temporarily disable or restrict the functions feature if you can’t patch right away, and require code to be vetted off-system before it runs in production.

• Check logs and EDR telemetry for unusual use of .NET component creation or unexpected process spawning, and preserve forensic copies before doing intrusive clean-up.

• Force rotation of any secrets or credentials that may have been reachable from the CMS, and review backup integrity so restorations are trustworthy.

• Notify downstream teams, suppliers and any customers who rely on your web publishing systems, and prepare a short incident statement that says what you know and what you are doing.

• Schedule a post-incident configuration review and a privileged account audit, then test restores and reissue credentials as part of the recovery plan.

Where ISO standards fit, without the sales pitch

An ISO-aligned information security management system would make this less likely and cut the blast radius. For example, an ISO 27001 approach concentrates on access control and supplier and change management, so privileged features like Raytha’s functions would be governed and reviewed rather than left open, see ISO 27001 guidance for practical controls and governance integration.

When continuity and recovery matter, having a tested business continuity plan means you can isolate affected services and recover with confidence, not guesswork. If that sounds dry, the real value is fewer emergency meetings and faster, cleaner recoveries, see ISO 22301 business continuity options.

Baseline technical controls also matter here, like patch management, code execution hardening, and configuration auditing. If you want third-party certification or a practical baseline, look at IASME certification material that maps controls to measurable actions.

Finally, this incident is a reminder that code-running features require process controls as much as technical controls, so policy, review and evidence of testing should sit alongside the tech.

Patch, restrict and verify, in that order.

Organisations running Raytha CMS should treat this as high priority, apply the vendor fix or mitigation and assume privileged code paths are sensitive until proved otherwise.