Unpatched Kaltura Deserialization Flaws Expose Multi-Tenant Video Platforms to RCE

As reported by The Hacker News, CERT/CC has disclosed two critical unpatched vulnerabilities in Kaltura's HTML5 video player library that chain unsafe PHP deserialization into arbitrary file read and remote code execution — all without authentication. What makes this disclosure particularly concerning is not just the technical severity, but the coordination failure: CERT/CC explicitly stated it was unable to reach Kaltura to coordinate remediation, leaving customers to defend themselves with no vendor patch on the horizon.

Vulnerability Summary

Affected components: Kaltura mwEmbed player library (also distributed as html5lib), specifically the mwEmbedLoader.php endpoint. Both customer self-hosted installations and Kaltura's shared multi-tenant CDN infrastructure are exposed.

Active exploitation: None reported at time of disclosure. Neither CVE appears in CISA's KEV catalog as of August 25, 2026.

Why This Matters Beyond the CVEs

The root cause here is a textbook PHP deserialization anti-pattern: unserialize() called on content fetched from a user-controllable URL with no validation of source, scheme, or data integrity. This class of vulnerability has been well-documented for over a decade, yet it persists in production media platforms serving educational institutions, enterprises, and government organizations worldwide.

The fact that an attacker can point the ServiceUrl parameter at a file:// URI, retrieve sensitive configuration files like local.ini containing plaintext database credentials and admin passwords, and have those bytes reflected back in error messages represents a cascading failure across input validation, scheme allow-listing, and error handling.

The second vulnerability escalates dramatically by combining the same deserialization sink with an unsanitized uiconf_id parameter that enables path traversal during cache file writes. An attacker can host a crafted serialized payload on an external server, point ServiceUrl at it, and achieve remote code execution on the Kaltura host — potentially the shared CDN infrastructure itself.

The Multi-Tenant Risk Is the Real Story

Individual Kaltura customers can patch their own servers when a fix arrives. But Kaltura's shared, multi-tenant CDN means a single vulnerable host could serve hundreds of tenants. Compromise of shared infrastructure creates blast radius that no single customer can control — and no customer-side mitigation fully addresses. This is the architectural risk that CERT/CC's note elevates from a standard CVE disclosure to an infrastructure-level concern.

Who Is Most Exposed

Immediate Actions

• Restrict access to mwEmbedLoader.php: At the WAF, reverse proxy, or web server level, block external access to this endpoint immediately. If the player functionality is required, restrict to authenticated internal networks or VPN.
• Enforce strict ServiceUrl allow-listing: If the endpoint must remain accessible, implement a server-side allow-list permitting only known legitimate Kaltura backend API URLs. Reject any file://, dict://, gopher://, or non-HTTPS schemes. This should be implemented at the application or WAF layer since no vendor patch exists.
• Sanitize uiconf_id: Ensure the uiconf_id parameter accepts only numeric values. Reject any input containing path separators, dots, or non-integer characters.
• Audit for compromise indicators: Check web server access logs for requests to mwEmbedLoader.php containing ServiceUrl=file:// or unusual uiconf_id values. Review for unexpected file reads of local.ini or other configuration files.
• Rotate credentials if exposed: If logs show suspicious access to mwEmbedLoader.php, assume database credentials, admin passwords, and API keys in local.ini have been compromised. Rotate all credentials immediately.
• Network segmentation: For self-hosted deployments, ensure the Kaltura application server cannot initiate outbound connections to arbitrary internet hosts unless explicitly required. Egress filtering limits the effectiveness of external payload hosting for RCE chains.

Shield53 Recommendations

Beyond the immediate mitigations, organizations should take the following steps:

1. Inventory Kaltura deployments: Identify all instances — self-hosted, SaaS, and CDN-served — across your environment. Many organizations lose track of media platform deployments spun up by individual departments.
2. Engage Kaltura support directly: Given CERT/CC's coordination failure, customers should escalate through their Kaltura account channels demanding a patch timeline and interim guidance.
3. Implement PHP deserialization hardening: If you operate PHP applications generally, audit for unserialize() usage on untrusted input. Consider deploying runtime protections or migrating to json_decode() where possible.
4. Review shared infrastructure risk: For organizations on Kaltura's SaaS/CDN, document this as a third-party risk. You cannot patch it yourself — press Kaltura for remediation commitments and consider contingency plans for video delivery.
5. Deploy WAF virtual patches: If using a WAF with custom rule capability, create signatures matching ServiceUrl parameters containing non-HTTP schemes and uiconf_id values with path traversal characters.
6. Monitor for public exploit development: Given the detailed technical writeup already published by the AndDone researcher, proof-of-concept code is likely forthcoming. Threat actors frequently weaponize disclosed deserialization chains within days of public writeups.

This disclosure underscores a persistent industry problem: critical deserialization vulnerabilities in widely deployed platforms, combined with vendor coordination failures that leave customers exposed indefinitely. Until Kaltura releases a patch — or confirms these endpoints are secured on their shared infrastructure — organizations should treat internet-exposed Kaltura deployments as actively vulnerable to unauthenticated compromise.